grub-devel.gnu.org archive mirror
 help / color / mirror / Atom feed
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 --]

      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).