https://bugzilla.suse.com/show_bug.cgi?id=1190261 https://bugzilla.suse.com/show_bug.cgi?id=1190261#c10 Martin Wilck <martin.wilck@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #10 from Martin Wilck <martin.wilck@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.