Add support for age plugins

[koenw]

First of all thanks for the software :)

When nixos-rebuild-ing my system flake with secrets encrypted to/with my Yubikey, (r)age gave the error that it was unable to find the plugin age-plugin-yubikey in it's $PATH even though I was able to run it myself. This is because any installed plugins would be unavailable in the build environment.

I have added an option to the agenix module to specify the age plugin packages that should be available in the build environment. This fixed the error for me and I am now able to successfully nixos-rebuild with secrets decrypted from my Yubikey.

I'm still finding my way with Nix so please let me know if you need any changes (or if this is totally not the right approach at all).

Thanks!

[koenw]

I was thinking perhaps it would be nicer to name this path, similar to systemd.services.<name>.path. On the other hand, the name pluginPackages communicates more intent and I believe is more discoverable. Thoughts? :)

[nbraud]

I think pluginPackages or just plugins are preferable: intent is clearer, as you said, and it is more discoverable by users who might not know age plugins are just executables in PATH.

[oddlama]

Have a look at this old PR #134 in which I tried the exact same thing just to arrive at the conclusion that this is probably not what I wanted.

[babeuh]

This is only related to using this with age-plugin-yubikey

Does this work when booting? When I tried to do this this way, PCSCD launched after activationScripts, which prevented age-plugin-yubikey from accessing my Yubikey.
I managed to make PCSCD launch before activationScripts using the new systemd initrd (there is probably a better way to do it), but then age-plugin-yubikey cannot get the Yubikey PIN (it has no tty to request it).

Also, when I added support for plugins (so I'm not sure if this applies to this PR), age-plugin-yubikey only supported the first Yubikey identity in the publickey list, which prevented me from using this with a backup Yubikey

I have managed to make it work for me but it's rather messy: this, this and this.

[koenw]

So, those efforts have died and this still seems a simple and viable approach. Perhaps time to re-open and reconsider?

[NovaViper]

@koenw This is the exact same way I implemented plugin support in my test config! Even works with ragenix (even though that one is actually suppose to have plugin support; it looks as if the plugins aren't being put in the path from what I saw). When I manually overwritten the ageBin and appended the plugins to the PATH, it made it function properly).

However, I do wish there was a similar way of implementing this for the HomeManager module; since there's no way to override the ageBin like you can in the NixOS module CORRECTION: there's actually an issue with Yubikey-generated age keys with a PIN on them can't be imported because the process is ran in systemd, resulting in the plugin being unable to run because there's no TTY to request the PIN input; same issue as @babeuh mentioned. This actually is the main reason why I'm not using either agenix or ragenix, as the ageBin option isn't available for the HomeManager module.

[nbraud]

Seems entirely sensible to me, and a badly-needed feature, especially in environments where SSH host keys might not be available early-enough during boot.

The case I ran into is simply because the secrets-containing ZFS dataset isn't yet mounted during the first activation (though I expect many other root-on-tmpfs setups would run into the same issue) but this also enables setups where the SSH host keys are either provided via agenix or sealed to the TPM.

[nbraud]

I think pluginPackages or just plugins are preferable: intent is clearer, as you said, and it is more discoverable by users who might not know age plugins are just executables in PATH.

[nbraud]

It seems to me rather reasonable to only support non-interactive plugins which can run on first activation. To support to plugins which require certain services to run, I believe the most reasonable solution would be to:

• require the use of systemd in the initrd ;
• let plugin packages provide a passthru.initrd attribute,¹ which gets slapped into boot.initrd.systemd when the plugin is used.

I believe that could reasonably wait until a follow-up PR though.

Footnotes

1. I'm not particularly attached to the attribute path being passthru.initrd, this is only about the general architecture question. ↩