Suggestion: age should be able to act as an age plugin

[tejing1]

I've been thinking through what it would take to create a simple and useful "age-agent" via the plugin interface, and I hit upon a realization which I thought was worth sharing here.

Age can make the job of writing an "age-agent" markedly easier and the result much more flexible by doing something fairly simple. It just needs to implement its own plugin interface. This reduces the job of the "age-agent" to:

• Providing an age plugin which:
  • Discovers how to connect to the agent from environmental cues and/or information in the identity referencing the plugin
  • Initiates a connection to the agent
  • Communicates the --age-plugin= argument it was given to the running agent
  • Passively forwards stdin/stdout to/from the running agent until EOF is reached
• Providing an agent service which:
  • Stores identities securely
  • Listens for new connections, and for each one:
    • Receives the --age-plugin= argument
    • Calls age in this age-as-age-plugin mode, with the --age-plugin= argument, and with the identities stored by the agent
    • Passively forwards to/from stdin/stdout of the age process until EOF is reached

An agent like this could be written in a wonderfully small amount of code, and assuming that age still invokes plugins when used in this mode, an agent designed this way would work with arbitrary plugins, without needing to have explicit support for them. If the plugin would work if age was invoked directly in the environment the agent runs in, it will work through the agent in the same way. It wouldn't even need to be updated for a new version of the on-the-wire plugin protocol.

The main potential hiccup I see is supplying the identities to age when stdin is already being used for the plugin communication protocol. Using an unnamed pipe rather than a named pipe would be more secure (I think. I'm not an expert in this.), but the existing CLI for age doesn't have a mechanism for this other than stdin. Maybe have an option to use a specific file descriptor number for the identities file? Anyway, this issue isn't entirely specific to the agent usecase, and the CLI will probably develop some additional methods in time.

[tejing1]

I suppose I should clarify that it's only that easy for an agent oriented only toward decrypting, which is the normal usecase, since public keys can just be made available locally for encrypting. If you want to handle encrypting with the agent, you need to think harder, firstly about the use model itself.

[tejing1]

Just checking back in with this idea now that age has plugin support. At this point, I think the lack of an age-agent is the only thing really holding me back from dropping gpg from my life.

• I need to be able to decrypt things without bothering the user (though not when the user isn't present).
• I don't have full disk encryption, so storing secret keys on the filesystem unencrypted is a no-go.
• Even if I had full disk encryption, I would much rather my keys only be available when my session is actually active and unlocked, and have the secret be fundamentally inaccessible otherwise without my password.
• Even though the socket to an agent is just under filesystem access controls, same as the actual key would be, there's a notable difference between giving access to use a key temporarily and giving access to the key itself.

The only other viable alternative I can come up with is to mount an encrypted loopback device using my pam password when logging in/unlocking, and unmount it when locking or logging out. This still exposes the key itself, rather than just access to it, to any program on my computer when my session is active, but I could probably live with that. An agent is definitely the ideal method for me, though.

Is there any plan to implement the ability for age to act as an age plugin? It seems the obvious way to accomplish this given the modular, unix-philosophy-style approach age is taking. (Which I very much agree with. All the moreso because it's an encryption tool. We need to be able to ruthlessly remove parts of the ecosystem we don't need, unlike the monolith that is gpg.)