Use tpm or yubikey in install phase

Help
1

Is it possible to use the tpm or a yubikey during a package’s install phase? The following derivation was working before on nixos-26.05, but after updating the channel, it no longer seems to work, despite the age file still being decryptable outside of a build:

pkgs.stdenvNoCC.mkDerivation {
  pname = "cartograph-cf-demibolditalic-otf-nerdfont";
  version = "2.4";
  dontUnpack = true;
  nativeBuildInputs = with pkgs; [
    config.home-manager.users.root.age.package
    nerd-font-patcher
  ];
  installPhase =
    let
      identities = config.home-manager.tertiary.home.sessionVariables.PASSAGE_IDENTITIES_FILE;
    in
    ''
      mkdir -p $out/share/fonts/opentype/Cartograph_CF
      age \
        -d \
        -i ${identities} \
        -o $out/share/fonts/opentype/Cartograph_CF/cartographcf-demibolditalic.otf \
        ${config.home-manager.tertiary.age.secrets."font.otf".file}
      nerd-font-patcher \
        --complete \
        --outputdir $out/share/fonts/opentype/Cartograph_CF \
        $out/share/fonts/opentype/Cartograph_CF/cartographcf-demibolditalic.otf
    '';
}

Interestingly, keeping the old channel commit and changing the derivation, such as adding an age --version at the top of the installPhase, also fails.

This is the build log with age --version added to change the derivation a bit:

Running phase: patchPhase
@nix { "action": "setPhase", "phase": "patchPhase" }
Running phase: updateAutotoolsGnuConfigScriptsPhase
@nix { "action": "setPhase", "phase": "updateAutotoolsGnuConfigScriptsPhase" }
Running phase: configurePhase
@nix { "action": "setPhase", "phase": "configurePhase" }
no configure script, doing nothing
Running phase: buildPhase
@nix { "action": "setPhase", "phase": "buildPhase" }
no Makefile or custom buildPhase, doing nothing
Running phase: installPhase
@nix { "action": "setPhase", "phase": "installPhase" }
v1.3.1
age: error: tpm plugin: failed to read line: EOF
age: report unexpected or unhelpful errors at https://filippo.io/age/report
1 Like
2

If you know the hash of the font file and are willing to update it when/if there are any updates, why not just use requireFile? It’s basically built for this exact use-case:

Seems better than trying to expose impure TPM/Yubikey/age stuff to the Nix build environment.

Unless it’s fingerprinted every download or something. But if you’re storing it in age I think you could just rely on the hash of that decrypted.

3

Hmm… I’m a little confused. The font itself is licensed, so I don’t want to push it to a public repo, hence why I’m storing it as an age secret. I’d also like to be able to provision new systems without any user input, so I’d prefer to keep it with the rest of the repo instead of downloading it manually every single time.

1 Like
4

What you could do is manually decrypt it with age before the install and then do nix-store --add-fixed sha256 <decrypted-font-file>/nix-prefetch-url --type sha256 file:///<decrypted-font-file>.

5

Is there no way to do it in the install itself? If I were just bootstrapping the system, then that’d be fine, but otherwise, I will most likely forget.

I tried adding /dev/tpmrm0 to the extra sandbox paths, for example, but that didn’t work.

1 Like
6

If you want to try and punch holes into the sandbox you can try, but I would personally prefer requireFile as it is designed specifically for this use-case of using non-redistributable unfree files in a derivation.
If you decide to go that route, what is your current list of extra-sandbox-paths? I’m actually interested in why this worked before…

1 Like
7

Basically what happened is that my previous system didn’t use a tpm key, so it wasn’t really complaining. Then, something updated on my new system and the package has to rebuild. Weirdly enough, while both the tpm identity and yubikey identity fail on the new system, the yubikey identity works fine on the old system, it seems.

Currently, only my builder account’s identities are being passed into the sandbox, so --option extra-sandbox-paths /persist/home/unexpectedgimli/.age/identities. The font isn’t so secretive that I can’t let it get leaked, for example.

However, adding --option extra-sandbox-paths /dev/tpmrm0 didn’t seem to work along with the first option flag.

1 Like
8

Strange… The sandbox should have prevented that.

Unfortunately, I don’t know what extra sandbox paths to add to go about fixing this.

1 Like
9

Ah, well… I might just switch to a regular age identity for the builder account until we find a solution here. Fingers crossed, and thanks for the help so far!

1 Like
10

You might wish to change the title to “USB hardware key” to avoid endorsing a particular product—especially since open source/open hardware options exist so a more generic label would be more inclusive to the category.

11

Sure, but the age-plugin-yubikey only seems to work with yubikeys at the moment, not all fido2 keys…?

1 Like