FOFoxboron·Oct 20, 2023Submission
Show HN: sbctl – Secure Boot key manager
57 points · Open discussionFoxboron
sbctl
Go2020–2026
Foxboron / sbctl
sbctl
:computer: :lock: :key: Secure Boot key manager
11Distinct people
24Mentions
0Explicit recommenders
2.3KGitHub stars
What to know before exploring
What it is
:computer: :lock: :key: Secure Boot key manager
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 2:59:58 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year24 dated mentions
Observed mentions: 2020-05-15 08:27:37 UTC to 2026-05-12 23:07:08 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 4 | 2 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 3 | 0 | 3 |
What Hacker News says
5 sourcesNo, this isn't true nor correct.
Secure Boot and TPM do offer tangible security benefits and is security features you can take ownership of.
Secure Boot allows your own key hierarchy, and TPM allows you to take ownership.
The linked boot disk isn't really proof that Secure Boot is useless. If you don't set a MOKManager password (as you should), and you change the security state of the machine while present at the keyboard. Yes you can boot things.
This is intended to make sure people can actually decide to trust things. And having insecure defaults makes this less useful. Not very surprising.
EDIT: The bootdisk won't work with a recent shim nor a recent grub. The old shim it was using should be revoked if you have any remotely updated machine as well.
TPMs could also prevent attacks like this on your machine.
Incidentally I've invested qu
Read the rest
ite a bit of time in making user-friendly Secure Boot tooling as well. https://github.com/Foxboron/sbctl
The question is whether you have any mandatory UEFI drivers or not. If they're in the ESP you can just look there to check, but UEFI drivers can also be loaded from PCI cards or baked in the firmware itself.
If you're using a TPM for Secure Boot, you can use the commands in https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom to know for sure.
In Intel OEM Private Key Leak: A Blow to UEFI Secure Boot SecurityFor secureboot you may want to took a look at this project [0]. Don't think it has ever gotten easier to sign UKIs than that though systemd should have a new project (systemd-ukify) that aims to make it more integrated.
Hiberation is not supported in lockdown mode because I'm assuming the kernel (maintainers) expect most people to have an unencrypted swap partition. If you have secured your swap, you can patch [1] the kernel to allow hibernation.
[0] https://github.com/Foxboron/sbctl
[1] https://gist.github.com/kelvie/917d456cb572325aae8e3bd94a9c1...
In Arch Linux Btrfs with hibernation in a swapfile> And in a case of self fulfilling prophecy, because they decided that initializing and owning your own keys was not going to be a normal part of the user experience, it is now hard(almost impossible) to do.
This is false.
The issue is that nobody has written user-friendly tooling to manage keys and sign stuff. Not that actually implementing this is hard.
https://github.com/Foxboron/sbctl
In MSI's (in)Secure Boot