Feature request: create-keys with --export

[nyawox]

Maybe #203 is related. I use NixOS with lanzaboote. This requires secureboot keys to be already generated to install first time.

    boot.lanzaboote = {
      enable = true;
      pkiBundle = "/persist/etc/secureboot";
    };

Therefore I have to generate the keys locally and deploy, or disable lanzaboote when installing. I don't think manually editing NixOS config when installing is elegant. I use nixos-anywhere to install remotely, disko does the partitioning automatically. I think secureboot key generation and deploy also should be able to do automatically. But seems like sbctl is hardcoded to generate keys to /etc/secureboot. That makes not possible unless using workaround with something like fakechroot, which I don't have the skill and knowledge currently.

Being able to do something like this solves my problem. sbctl create-keys --export $temp/persist/etc/secureboot/

[RaitoBezarius]

BTW, SecureBoot key generation should probably be done as part of a phase like https://github.com/nix-community/disko/pull/383 in disko, because it is a secret and should be treated as such.

Obviously, having a way to export keys in a precise location would be nice, but should not be required, IMHO. We have a special trick in nixpkgs that is to do pkgs.sbctl.override { databasePath = "$temp/persist/etc/secureboot"; } and this way you will have a sbctl that will write in that folder and expect things in that folder, it causes a rebuild but this is fairly simple Go program that is fast to rebuild locally.

[Foxboron]

@cosmastech there is an attempt at creating a more extensive test suite to test these things. But it's not really covering a lot.

Generally I just test stuff locally, but you could probably try and write tests cases for this.

[cosmastech]

@cosmastech there is an attempt at creating a more extensive test suite to test these things. But it's not really covering a lot.

Generally I just test stuff locally, but you could probably try and write tests cases for this.

If I am developing on a Mac silicon, can I still compile and run this? It seems like the go compiler was griping about it. Wasn't sure if I needed to employ docker here. (I'm newer to docker than I am to golang :-D )

[Foxboron]

@cosmastech This specific feature doesn't require any Linux specific things, but sbctl is very much a Linux-only thing.

[nyawox]

BTW, SecureBoot key generation should probably be done as part of a phase like nix-community/disko#383 in disko, because it is a secret and should be treated as such.

Are you refering to how it uses base64 for directory name like this?

cp --reflink=auto -r "$src" copy_after_disko/"$(echo "$dst" | base64)"

dst=/mnt/$(basename "$src" | base64 -d)

Obviously, having a way to export keys in a precise location would be nice, but should not be required, IMHO. We have a special trick in nixpkgs that is to do pkgs.sbctl.override { databasePath = "$temp/persist/etc/secureboot"; } and this way you will have a sbctl that will write in that folder and expect things in that folder, it causes a rebuild but this is fairly simple Go program that is fast to rebuild locally.

Didn't notice that there was such argument! thanks

nix develop --impure --expr '(with import (builtins.getFlake "github:nixos/nixpkgs/nixos-unstable") {}; mkShell { buildInputs = [ (pkgs.sbctl.override {databasePath = "'$temp'/persist/etc/secureboot";}) ];})' --command sbctl create-keys

Confirmed this command works for my use case. Installed and enrolled keys successfully using enrollKeys = true;

[RaitoBezarius]

BTW, SecureBoot key generation should probably be done as part of a phase like nix-community/disko#383 in disko, because it is a secret and should be treated as such.

Are you refering to how it uses base64 for directory name like this?

cp --reflink=auto -r "$src" copy_after_disko/"$(echo "$dst" | base64)"

dst=/mnt/$(basename "$src" | base64 -d)

I am referring to the fact that you can pass end to end a secret without compromising it in the Nix store via sops-nix + this post-format files feature, indeed.