What's the use case?

I'm not sure I fully understand, do you want justification for this change?

Personally, I only care about the yubikey plugin, but it seems like there's demand for general plugin support (#102). There seemed to be no obvious way to get the yubikey plugin to work with upstream agenix, so I quickly implemented a fix. I've also looked at the PR's and noticed #46, which has been stale for over a year.

I figured a simple change could fix both issues without adding a forced dependency on the yubikey plugin.

You want to use a yubikey to decrypt the secrets at activation time? Like on boot? Or, is it necessary to have the plugin present even when the identity is not used for decryption?

Now I get what you mean. Indeed, boot time (i.e. activation time) secret support would just be disk encryption with extra steps, and that's not practical at all using a yubikey.

What I actually want is:

• Store secrets in the repository encrypted using a yubikey identity
• On build-time decrypt the secrets and immediately re-encrypt them using a key available to the host (currently the ssh host key is used)
• On activation time, agenix decrypts secrets as usual by using the host's ssh key.

For that no changes to agenix should be necessary. Sorry for the confusion, I might post a short update later when I have it working.

@ryantm In case you or anyone else is interested in the solution, I've published an extension on top of agenix which automates rekeying and removes the need to manually keep track of secrets. Works great with a Yubikey. And sorry for my rushed initial proposal.