You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm working on building a Linux ISO. The goal is for the ISO to setup a system with secureboot public keys on first boot. A service will run and if it detects Audit mode it will run sbctl enroll-keys. Currently it seems the private key must be present otherwise enroll-keys fails. As a consequence I need to include the private key on the ISO, however this is undesirable as anyone who can get hold of the ISO can get their hands on the private key (I want to only use the private key when the ISO is generated).
Is it possible to drop the requirement for the private key being present when enroll-keys is run?
(As a workaround I'm replacing /var/lib/sbctl/keys/db/db.key with another db.key file generated separately by create-keys, this seems to keep sbctl happy.)
The text was updated successfully, but these errors were encountered:
So in theory this should be fine, if we are in "setup mode" we don't actually need to sign the updates. It's only needed if we are rotating the keys. The issue is that I'd need to refactor a bit more and have some detection on this.
It's not super trivial to implement properly, and I think it would be a good idea.
I'm working on building a Linux ISO. The goal is for the ISO to setup a system with secureboot public keys on first boot. A service will run and if it detects Audit mode it will run sbctl enroll-keys. Currently it seems the private key must be present otherwise enroll-keys fails. As a consequence I need to include the private key on the ISO, however this is undesirable as anyone who can get hold of the ISO can get their hands on the private key (I want to only use the private key when the ISO is generated).
Is it possible to drop the requirement for the private key being present when enroll-keys is run?
(As a workaround I'm replacing /var/lib/sbctl/keys/db/db.key with another db.key file generated separately by create-keys, this seems to keep sbctl happy.)
The text was updated successfully, but these errors were encountered: