This landed in :latest last night but is not in the weekly builds yet, but yeah, you need to enroll the new keys, we’re working on the announcement still.
We’re currently signing kernels with the new key and akmods with both keys. Eventually, we’ll drop the old key and provide instructions or automation to remove it from the list of enrolled MOKs.
Third:
I haven’t had a chance to dig deep on the different Fedora CA entries. But I don’t believe that is actually stored in the UEFI MOK list, rather it’s provided by the Fedora shim. Fedora did do their own key rotation not too long ago, so I suspect that you still have the older shim and grub in your boot partition.
hey @bsherman
thanks for asking for clarification, much appreciated.
Yes that’s exatly what I did:
turn laptop on and was greeted by that notification
ran ujust enroll-secure-boot-key
checked mokutil --list-enrolled and got that result
Before doing all of this I had only:
7e68651d52 Fedora Secure Boot CA
63fe4d8157 ublue akmods\
It’s weird for that 7e68651d52 Fedora Secure Boot CA line, I never messed with Fedora shim (I would have had to load a shim file in the BIOS to have that right? I’m not a specialist as you can see)
Also while we’re at it @bsherman I have 2 questions for you:
I’m planning on reinstalling Bluefin one of those days. Does all the keys (those 3 ones) are deleted and I re-enroll the correct ones?
I created a topic few weeks back regarding an error enrolling secure boot key on another computer Error enrolling secure boot key
Do you have any idea of what could cause this problem (HP pavillion desktop with Windows previously) ?
Maybe it’s not related but that same computer has trouble shutting down properly Error shutting down computer
turn laptop on and was greeted by that notification
ran ujust enroll-secure-boot-key
checked mokutil --list-enrolled and got that result
Great! Thank you for confirming! I wanted to make sure this wasn’t a bug report about the notification showing incorrectly.
This sounds like the behavior we expect, and the notification did its job! It was created to let users know this needs to be done, even though the old ublue akmods MOK may already have been enrolled.
It’s weird for that 7e68651d52 Fedora Secure Boot CA line, I never messed with Fedora shim (I would have had to load a shim file in the BIOS to have that right? I’m not a specialist as you can see)
You wouldn’t have messed with this, it’s would have been installed when you installed the system and not updated. It’s almost never a manual user operation.
I’m planning on reinstalling Bluefin one of those days. Does all the keys (those 3 ones) are deleted and I re-enroll the correct ones?
A MOK (Machine Owner Key) is actually enrolled into a database which is part of the UEFI on your motherboard. This is why it needs a reboot and that ugly UI with a password to enroll.
But, this also means you won’t need to do it again even after reinstall.
I created a topic few weeks back regarding an error enrolling secure boot key on another computer Error enrolling secure boot key
I’ll respond on those threads to keep this focused.
@bsherman Does the old key have an upcoming expiration date such that it will be universally recognized as invalid? The only reason I’ve seen for switching keys is “security”, so it seems kind of weird that the swap process doesn’t include removing the old key.
Different dates have been thrown around, but unless I missed it or forgot (which happens), we haven’t picked a hard date for the cutover.
In part, this particular rotation of the ublue MOK is a practice run, giving us a chance to walk through it while we are NOT in a crisis.
So for this there’s a couple ideas in play:
dual-signing assets (kernels and kmods) with both keys for some time gives slow adopters adequate notification and time to enroll the new key before. If it was insta-swapped, users would update and not have the required key, which could prevent booting on non-stock Fedora kernels (eg, fsync). The original post on this thread is an example of a) the notification accomplishing this goal and b) the need for uBlue team to better document and communicate some of the details (eg, that both keys would be left on the system).
though less important, leaving both keys in the MOK list allows the user to rollback their system to a point where kernel/kmods were only signed with the old key, also preventing booting issues, etc.
The finally step in the key-swap process will be to stop signing with the old key, and at the same time, we’ll provide some instructions, and probably a ujust recipe, to remove the old one. Users are free to remove the old key now, if they choose, if they understand the situation and want to do it themselves.
Welcome to Bluefin
bluefin-dx-nvidia:stable
Command │Description
─────────────────────────────────────┼────────────────────────────────────────
ujust --choose │Show available commands
ujust toggle-user-motd │Toggle this banner on/off
ujust bluefin-cli │Enable terminal bling
brew help │Manage command line packages
Need a container? ujust distrobox-assemble can help you assemble a new
container image.
• Issues https://issues.projectbluefin.io
• Documentation http://docs.projectbluefin.io/
• Discuss https://community.projectbluefin.io/
• Leave Feedback https://feedback.projectbluefin.io
WARNING: This machine has secure boot turned on, but you haven't enrolled
Universal Blue's keys. Failing to enroll these before rebooting may cause your
system to fail to boot. Follow this link
https://docs.projectbluefin.io/introduction#secure-boot
https://docs.projectbluefin.io/introduction#secure-boot
for instructions on how to enroll the keys.
malix@malix-pc ~>
now, on Bluefin stable, 40.20240930
However, I tried many times but it fails with “password doesn’t match” on the MOK screen
I set “universalblue” on both the terminal and the MOK util
I tested it 4 times, but the 1st time, I set the wrong password (my user password instead of “universalblue”)
This is what I get after using ujust enroll-secure-boot-key once (so now it doesn’t prompt for a password anymore)
malix@malix-pc ~> ujust enroll-secure-boot-key
echo 'Enter password "universalblue" if prompted after your user password.'
Enter password "universalblue" if prompted after your user password.
sudo mokutil --timeout -1
sudo mokutil --import /etc/pki/akmods/certs/akmods-ublue.der
SKIP: /etc/pki/akmods/certs/akmods-ublue.der is already in the enrollment request
echo 'When you reboot your computer, follow the instructions to start MOK util'
When you reboot your computer, follow the instructions to start MOK util
echo 'by pressing a key, then enroll the secure boot key and enter "universalblue" as the password'
by pressing a key, then enroll the secure boot key and enter "universalblue" as the password
malix@malix-pc ~> mokutil --list-enrolled
2bb010e24d fedoraca
63fe4d8157 ublue akmods\
malix@malix-pc ~ > sudo mokutil --timeout -1
malix@malix-pc ~> mokutil --list-new
malix@malix-pc ~ > sudo mokutil --timeout -1
malix@malix-pc ~ >
Notice that mokutil --list-new outputs nothing, butujust enroll-secure-boot-key outputs “SKIP: /etc/pki/akmods/certs/akmods-ublue.der is already in the enrollment request”
i have the sasme behaviour on Bluefin Stable
First i do the ujust command and set a password. (what is that for? or is it my login pw?)
and the on restart i try to enroll the key but the password doesnt match. UniversalBlue and also my login pw…
I wonder if it would be better to just change the recommended “universalblue” password to something idempotent, like “expedition”, “chocoholic”, or maybe just “ublue”.