Comment # 48 on bug 1175626 from Martin Wilck

(In reply to Gary Ching-Pang Lin from comment #45)

> I guess the update of kernel triggered the enrollment of new signkey and the
> deletion of the old signkey. But somehow MokNew was gone, so MokManager
> thought that there was a reset.

How would MokNew go away? The scriptlets in the kernel rpm are written so that
the keys won't be deleted as long as the system still has one kernel installed
that needs them.

Why do we have different signkeys for Leap 15.2, anyway? 

> ~ # rpm -qlp /var/cache/zypp/packages/repo-oss/x86_64/kernel-default-5.3.18-lp152.19.2.x86_64.rpm | grep crt
> /etc/uefi/certs/F1C08E27.crt
> ~ # rpm -qlp /var/cache/zypp/packages/repo-update/x86_64/kernel-default-5.3.18-lp152.33.1.x86_64.rpm | grep crt
> /etc/uefi/certs/F1C08E27.crt
> ~ # rpm -qlp /var/cache/zypp/packages/repo-update/x86_64/kernel-default-5.3.18-lp152.33.1.x86_64.rpm /var/cache/zypp/packages/repo-update/x86_64/kernel-default-5.3.18-lp152.36.1.x86_64.rpm | grep crt
> /etc/uefi/certs/F1C08E27.crt
> /etc/uefi/certs/33CEA71B.crt

We've got two signkeys here with the same subject and slightly different serial
number and validity. I guess it depends on the OBS project the kernel's built
in, but it's intransparent and confusing for users.

== /etc/uefi/certs/33CEA71B.crt ==
issuer=CN = openSUSE Secure Boot CA, C = DE, L = Nuremberg, O = openSUSE
Project, emailAddress = build@opensuse.org
serial=FABED8BF409A5E63
subject=CN = openSUSE Secure Boot Signkey, C = DE, L = Nuremberg, O = openSUSE
Project, emailAddress = build@opensuse.org
notBefore=Aug  3 12:35:39 2020 GMT
notAfter=Jun 12 12:35:39 2030 GMT
SHA1 Fingerprint=33:CE:A7:1B:A1:6A:67:BA:D8:6B:93:CB:DA:2E:19:A7:E9:DF:95:66
X509v3 Subject Key Identifier: 
    C8:BD:C7:AC:1A:1D:85:96:62:17:FD:93:EB:FC:14:F4:A2:00:B8:14

== /etc/uefi/certs/F1C08E27.crt ==
issuer=CN = openSUSE Secure Boot CA, C = DE, L = Nuremberg, O = openSUSE
Project, emailAddress = build@opensuse.org
serial=FABED8BF409A5E60
subject=CN = openSUSE Secure Boot Signkey, C = DE, L = Nuremberg, O = openSUSE
Project, emailAddress = build@opensuse.org
notBefore=Jan  8 16:25:54 2020 GMT
notAfter=Nov 16 16:25:54 2029 GMT
SHA1 Fingerprint=F1:C0:8E:27:F3:5F:3F:39:C5:5C:CB:F8:58:18:C6:27:DF:49:4E:34
X509v3 Subject Key Identifier: 
    03:32:FA:9C:BF:0D:88:BF:21:92:4B:0D:E8:2A:09:A5:4D:5D:EF:C8

> > I forced Yast to
> > reinstall them, rebooted, and its now working (not SecureBoot).

The forced reinstall may have caused harm. When you reinstall (and the version
number of the nvidia-gfxG05-kmp-default package is the same as before), the
installation procedure will generate a new key with the same file name,
overwriting the previous one. Because of rpm scriptlet ordering (%postun is
executed after %post), this might lead to the old key remaining present and the
new one not being enrolled. I'm not 100% certain about this, but I guess it
could happen. It's safer to delete the package and install it again.

I'm not saying this is the user's fault. It's rather a corner case that we may
have overlooked. It does not apply to the kernel packages.

> Reinstalling OS won't change MokList. The most reliable way is to reset the
> firmware to factory default. You'll need to restore the boot entries after
> that.

Isn't this is an overkill recommendation? It should be only a last resort
measure. Perhaps MokManager should have an option to reset the MokList only.