Where to go from `boot.initrd.luks.gpgSupport`?

sveitser · April 28, 2026, 7:33pm

I have a few yubikeys configured to use the same gpg key and I currently use the following to unlock during boot

boot.initrd.luks.gpgSupport = true;
boot.initrd.luks.devices.“cryptroot”.device = “/dev/disk/by-uuid/…
boot.initrd.luks.devices.“cryptroot”.gpgCard.publicKey = ..;
boot.initrd.luks.devices.“cryptroot”.gpgCard.encryptedPass = ..;

IIUC correctly support for this will be removed with scripted initrd in 26.11.

github.com/NixOS/nixpkgs

nixos/modules/system/boot/luksroot.nix

00cd0bb84


      
            message = "boot.initrd.luks.reusePassphrases has no effect with systemd stage 1.";
          }
          {
            assertion =
              config.boot.initrd.systemd.enable
              -> all (dev: dev.preOpenCommands == "" && dev.postOpenCommands == "") (attrValues luks.devices);
            message = "boot.initrd.luks.devices.<name>.preOpenCommands and postOpenCommands is not supported by systemd stage 1. Please bind a service to cryptsetup.target or cryptsetup-pre.target instead.";
          }
          # TODO
          {
            assertion = config.boot.initrd.systemd.enable -> !luks.gpgSupport;
            message = systemdStage1HardwareKeyAssertionMessage "boot.initrd.luks.gpgSupport";
          }
          {
            assertion = config.boot.initrd.systemd.enable -> !luks.fido2Support;
            message = systemdStage1HardwareKeyAssertionMessage "boot.initrd.luks.fido2Support";
          }
          # TODO
          {
            assertion = config.boot.initrd.systemd.enable -> !luks.yubikeySupport;
            message = systemdStage1HardwareKeyAssertionMessage "boot.initrd.luks.yubikeySupport";

Wondering if anyone is in a similar position and what they ended up doing and why.

I think I have the option of using piv (which will work both with my yubikey 4 and 5) or FIDO2 which is only supported by the yubikey v5. At first glance FIDO2 seems easier to configure except for having to enroll each yubikey.

uosis · May 16, 2026, 7:41pm

Same position here. GPG support is a great feature that would be unfortunate to lose. There are no good alternatives as far as I can tell.

ElvishJerricco · May 16, 2026, 10:45pm

The supported options are those described in systemd-cryptenroll(1). Anything else is just out of scope and not reasonably maintainable in-tree in nixpkgs. cryptsetup does have a concept of plugins, and I think it would be a good idea for us to add more generic support for those, but AFAIK there aren’t plugins for the deprecated methods other than the fido2 / tpm2 / pkcs11 ones you get with systemd-cryptenroll.

If you want support for additional key acquisition methods, my recommendation is to file issues upstream with systemd about the method you’d like, or to create an out-of-tree cryptsetup plugin for it. In the latter case, NixOS still needs to implement a generic interface for integrating arbitrary cryptsetup plugins, but that would be a welcome change (unlike any specific in-tree implementations of key acquisition methods).