-
-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix:[#1651] Add MOTD message for SB keys #1656
Conversation
7e56b6b
to
e927eeb
Compare
These changes are untested. I'll try to get an environment set up to test them before marking the PR as ready. |
c527664
to
6b2d22d
Compare
The word wrapping is a little broken, but I believe this is an issue with glow and their handling of hyperlinks. Marking as ready since its out of my control and ugly warnings are better than no warnings at all. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I will let others weigh in though.
I did a workaround for this, you can use Good for another PR though, I don't want to hold this up over some formatting. LGTM. |
Is this warning something we would need in Bazzite? Only case I can think of is if someone were to install Bazzite without secure boot on and then turn it on? But then they wouldn't be able to see the message anyway? |
Missed this, seems there's a typo here? $ENROLL doesn't exist, $ENROLLED is created above. |
I'm not sure how I did that, but its fixed. Should be good after the CI clears. I rechecked it in my environment. |
- Add logic to check for SB enrollment and keys - Update motd template
Thanks for the tip. I implemented this to clean it up some. Its not perfect, but its better. |
Let's merge this tomorrow (after the :stable builds go out), that way we have a week of it in :latest if we need to tweak the text. |
if this merges first, i can refactor this PR to consolidate the logic |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct me if I'm wrong, but I believe this needs to be fixed.
# check for secure boot key | ||
KEY_WARN="" | ||
FINGERPRINT="2B:E9:91:E3:B1:B5:40:70:F4:3D:80:BB:13:EB:C6:57:E5:A3:78:0D" | ||
mokutil --list-enrolled | grep -q $FINGERPRINT |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this actually works.
Example:
$ FINGERPRINT="2B:E9:91:E3:B1:B5:40:70:F4:3D:80:BB:13:EB:C6:57:E5:A3:78:0D"
$ mokutil --list-enrolled |grep $FINGERPRINT
Notice there is no output because the grep match failed...
I think you want something like this:
$ mokutil --list-enrolled --verbose-listing|grep -i $FINGERPRINT
SHA1 Fingerprint: 2b:e9:91:e3:b1:b5:40:70:f4:3d:80:bb:13:eb:c6:57:e5:a3:78:0d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it does work, but not by comparing output. when grep fails to find a match, it gives an exit code of 1. so this just compares the exit code to see if it matches or not.
I've tested it in a VM and it works well. if there's a better option, I'm open to changing it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand the grep -q
usage, my point is it will always think the key is not enrolled because of the output from mokutil --list-enrolled
vs mokutil --list-enrolled --verbose-listing
$ mokutil --list-enrolled
2bb010e24d fedoraca
2be991e3b1 ublue kernel
The output above will never have the fingerprint contents.
Adding --verbose-listing
does add the fingerprint output to the listing, however, with a lowercased fingerprint, which won't match what you have here.
$ mokutil --list-enrolled --verbose-listing|grep -i sha1
SHA1 Fingerprint: 2b:b0:10:e2:4d:94:c6:32:24:58:89:ba:aa:9e:d0:f3:d5:ef:1f:68
SHA1 Fingerprint: 2b:e9:91:e3:b1:b5:40:70:f4:3d:80:bb:13:eb:c6:57:e5:a3:78:0d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thats not what the included mokutil command produces
mokutil --list-enrolled | grep Finger
SHA1 Fingerprint: 2b:b0:10:e2:4d:94:c6:32:24:58:89:ba:aa:9e:d0:f3:d5:ef:1f:68
SHA1 Fingerprint: 2b:e9:91:e3:b1:b5:40:70:f4:3d:80:bb:13:eb:c6:57:e5:a3:78:0d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
$ which mokutil
/usr/bin/mokutil
$ `which mokutil` --version
0.7.1
$ /usr/bin/mokutil --list-enrolled | grep Finger
Does Bluefin somehow modify mokutil default behavior?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even if there's a version of mokutil where --list-enrolled
does show fingerprint, does --verbose-listing
not work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jardon and I discovered in a side chat that the difference here is Fedora 39 has mokutil version 0.6.0 and Fedora 40 has version 0.7.1.
And the outputs differ.
|
||
# check for secure boot key | ||
KEY_WARN="" | ||
FINGERPRINT="2B:E9:91:E3:B1:B5:40:70:F4:3D:80:BB:13:EB:C6:57:E5:A3:78:0D" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if we want to hard code the fingerprint or read it from the cert on-image?
openssl x509 -fingerprint -noout -in /etc/pki/akmods/certs/akmods-ublue.der
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is a good suggestion. ive implemented this in the notify-send PR
closing in favor of #1661 |
Closes #1651