Re: RFC: should the 'trust' and 'verify_detached' commands respect 'check_signatures=enforce'?

[Jonathan McCune]

On Mon, Oct 21, 2013 at 10:33 AM, Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden> wrote:

On 18.10.2013 04:44, Andrey Borzenkov wrote:
> В Thu, 17 Oct 2013 23:44:05 +0200
> Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden> пишет:
>
>> 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.

Thanks,

-Jon