Comment # 10 on bug 1190261 from Martin Wilck

(In reply to Joey Lee from comment #9)

> Why you want to use MokManager to enroll DB?

I meant MOK, sorry.

> > If it isn't, we could skip the mokutil step in that case.
> > 
> > Or would it make sense to enroll the certs anyway, just in case SB is
> > enabled at a later time?
> 
> MokManager still works for enrolling MOK when secure boot is disabled. It's
> _NOT_ secure, but works. Enrolling kernel signkey is useful when the CA of
> the kernel signkey is different with the CA in shim. Shim can use MOK to
> verify kernel binary.

If that's the case, I think we should always try to enroll from the kernel rpm
scriptlet. The use case is:

 1. user has SB disabled
 2. kernel with new key is installed
 3. user enables SB some time later

If we didn't enroll and install in 2.), booting might fail after 3.).
Of course the user can still skip actually installing the key during boot, that
that's outside our responsibility, and it could happen even if SB was enabled.
(Did I ever mention that MokManager's UI is horrible?).

> On the other hand, there is a way to detect whether system boot from shim.
> Just check the existence of this file: 
> /sys/firmware/efi/efivars/MokListRT-605dab50-e046-4300-abb6-3dd810dd8b23
> 
> This file is created by shim when booting. If system doesn't boot from shim
> (e.g. direct boot from EFI stub), then this MokListRT variable will not
> exist.

Thanks for the info, but in view of what you wrote before, I think we'd better
try to enroll the key anyway.

I am going to close this bug now.