Huh, as a Lanaboote user I’m surprised to see this on the front page. I use this in combination with sbctl for key generation. I’m mostly using it because I wanted to set up full disk encryption with TPM2 auth.
Lanzaboote is great, I've been using it for almost a year now in a dual boot with Windows 11 for full secure boot on my desktop. It is quite stable (notably was set and forget) and the initial setup was relatively easy.
Does it play well with bitkeeper full disk encryption?
Previous attempts at dual booting windows 11 on a laptop - I had issues when Linux updated boot alternatives - windows would demand bitkeeper recovery key input.
That looks like a really nice hackathon! That said, the fact that they probably had a majority of the best NixOS developers in the world under one roof and they weren't solely focused on NixOS error messages is borderline criminal...
Secure boot protects against evil maid attacks, but no one would ever need use an evil maid attack on a NixOS user because anyone can merge whatever they want to NixOS without signature or review, particularly given that any maintainer can merge their own commits from their own pseudonyms.
NixOS is always one compromised Github API token away from a backdoor into everything built with NixOS.
I cannot imagine a threat model that would need secure boot yet accept the risks of NixOS.
What are you on about now? I got _one_ of my projects accepted into NixPkgs a couple years ago and have never done it since due to the huge PITA it was to find someone with contributor rights to sign off on it. If I want to update it, same hassle. Now I prefer to just throw a flake in the root of the project and call it good, which actually works really well.
Wait until you find out that Arch has both secure boot and the AUR.
You have to be either a committer in general or a maintainer of a specific package to merge PRs into Nixpkgs. Contributors' PR approvals in Nixpkgs are just an informal signal for maintainers and committers to consider. And maintainers can only merge changes related to the packages they maintain, not other random changes.
But a maintainer could merge their own PR created by a pseudonym, and signing is not required, so in effect, they can ship any changes to their own packages they wish. This is a major supply chain security risk.
16 comments
[ 2.6 ms ] story [ 40.3 ms ] threadProbably integrating something like sbctl (https://github.com/Foxboron/sbctl#sbctl---secure-boot-manage...) would do the trick, it's making the whole signing and key management dance easy.
Seems to already work together with limine on NixOS too: https://search.nixos.org/options?channel=25.11&query=sbctl#s...
Previous attempts at dual booting windows 11 on a laptop - I had issues when Linux updated boot alternatives - windows would demand bitkeeper recovery key input.
However when I setup Windows it wiped my TPM keys for LUKS so maybe there is a potential conflict there.
you must not join it, refuse to lockdown your computer
NixOS is always one compromised Github API token away from a backdoor into everything built with NixOS.
I cannot imagine a threat model that would need secure boot yet accept the risks of NixOS.
What are you on about now? I got _one_ of my projects accepted into NixPkgs a couple years ago and have never done it since due to the huge PITA it was to find someone with contributor rights to sign off on it. If I want to update it, same hassle. Now I prefer to just throw a flake in the root of the project and call it good, which actually works really well.
Wait until you find out that Arch has both secure boot and the AUR.
Also, because there is no signing, git history can be rewritten easily or people can impersonate each other in git history easily.
This sort of posture is why I am totally serious when I say one compromised Github token can backdoor all nix users.