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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.