Control: tag -1 moreinfo
On Tue, 19 Sep 2023 13:37:01 +0200 Tobias Bossert
<tobias.boss...@fastpath.ch> wrote:
Package: dkms
Version: 3.0.11-3
Enrolled my own secureboot key chain (PK, KEK, db) and wanted dkms to sign
kernel modules automatically.
I tried to reproduce that in a sid chroot by setting
mok_signing_key=/etc/dkms/mok.key
mok_certificate=/etc/dkms/mok.pub
in framework.conf and created them with
openssl req -new -x509 -nodes -days 36500 \
-subj "/CN=DKMS module signing key" -newkey rsa:2048 \
-keyout /etc/dkms/mok.key -outform DER -out /etc/dkms/mok.pub
Then I installed linux-headers-amd64 and dkms-test-dkms.
That didn't modify my keys.
* What exactly did you do (or not do) that was effective (or ineffective)?
Set `mok_signing_key=` and `mok_certificate` in `/etc/dkms/framework.conf` to
my DB.key/DB.crt and then installed the `nvidia-driver` using apt.
Did both files exist?
* What was the outcome of this action?
My DB.key and DB.crt were overridden by some new keys.
This should only have happened if one of the files was missing.
And that I can reproduce in my chroot, if I rename one of the files, a
new pair gets generated.
* What outcome did you expect instead?
Even if my configuration is wrong, I would never expect that setting
`mok_signing_key=` overriddes anything.
dkms doesn't know where the mok_signing_key= and mok_certificate=
settings come from. The values could be
* builtin defaults
* distribution defaults set in framework.conf
* user customized values set in framework.conf
* empty, which causes a fallback to builtin defaults
If either the .key or the .crt file is missing, dkms will generate a new
.key and self-signed .crt in the locations pointed to by
mok_signing_key= and mok_certificate=
Andreas
