From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: grub-devel@gnu.org
Subject: Re: RFC: should the 'trust' and 'verify_detached' commands respect 'check_signatures=enforce'?
Date: Mon, 21 Oct 2013 23:42:46 +0200 [thread overview]
Message-ID: <52659FD6.9040107@gmail.com> (raw)
In-Reply-To: <CADtfRCX2ptTNphUA8_eAkKqj=eLXXjwXFydGaDum=Lv-MZ8Mpg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2656 bytes --]
On 21.10.2013 19:44, Jonathan McCune wrote:
> On Mon, Oct 21, 2013 at 10:33 AM, Vladimir 'φ-coder/phcoder' Serbinenko
> <phcoder@gmail.com <mailto:phcoder@gmail.com>> wrote:
>
> On 18.10.2013 04:44, Andrey Borzenkov wrote:
> > В Thu, 17 Oct 2013 23:44:05 +0200
> > Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com
> <mailto:phcoder@gmail.com>> пишет:
> >
> >> On 17.10.2013 20:28, Jonathan McCune wrote:
> >>> Presently the 'trust' and 'verify_detached' commands disable all
> filters
> >>> (e.g., verify.c:grub_cmd_trust() calls
> grub_file_filter_disable_all())
> >>> when opening a file containing a public key (note the
> distinction from
> >>> verify_detached implicitly using an already-loaded key).
> >>
> >> This is the intended behaviour. Usecase to manually add keys when
> >> needed. Your proposal is for other usecases which would probably
> require
> >> special arguments or separate functions.
> >>
> >
> > This has the same MITM problem we already discussed and that was fixed
> > if pubkey filter is used - you cannot actually know that key you trust
> > is the same as key you verified. So I think that at least by default
> > "trust" should not disable pubkey filter.
> >
> > verify_detached probably should, but may be only for file that is
> > verified itself, bit for pubkey.
> >
> I didn't oppose to a command or options having the described
> functionality. Thinking about it, I have to agree that default behaviour
> should be paranoid with options to relax it. Would you or Jonathan
> prepare a patch to change the behaviour with an option to restore
> current behaviour?
>
>
> How about addressing this by adding a --skip-sig option to both trust
> and verify_detached, that disables signature checking for the loaded
> public key? This would be similar in structure to the --skip-sig option
> to load_env, and the consistent use of --skip-sig would hopefully make
> things easier on the author of a .cfg file. It's mildly confusing to
> say verify_detached --skip-sig since the whole point of that command is
> to check a signature, but the documentation can make it clear.
>
> I can prepare a patch but it could be a week or more before I have time
> to do so.
>
Patch attached. Completely untested. Anyone to test it?
> Thanks,
> -Jon
>
>
>
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
[-- Attachment #1.2: pkcheck.diff --]
[-- Type: application/x-patch, Size: 3277 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]
prev parent reply other threads:[~2013-10-21 21:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-17 18:28 RFC: should the 'trust' and 'verify_detached' commands respect 'check_signatures=enforce'? Jonathan McCune
2013-10-17 21:44 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-10-18 2:44 ` Andrey Borzenkov
2013-10-21 17:33 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-10-21 17:44 ` Jonathan McCune
2013-10-21 21:42 ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52659FD6.9040107@gmail.com \
--to=phcoder@gmail.com \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).