One-way encryption, ad-hoc encryption for users, without private keys

[psionic-k]

The CLI instructions show an edit of an existing secret and having access to private keys necessary to do so. I may want to set up a situation where the ssh private key is unrecoverable by the user who needs to encrypt secrets. In such case, a one-way encryption workflow is necessary. The ad-hoc pathway to get encrypted secrets into the store, if there is one, is not documented on the README and needs to be pulled out of code. A user who can re-encrypt secrets can always control the contents of secrets without needing to access them, a blind edit.

I'm looking into the management of decryption keys still.

This issue is motivated by dotfiles use cases with multiple users, not the root user case.

[ryantm]

@psionic-k One-way encryption works fine, just don't include your public key in secrets.nix for that secret. What can we do to make this more clear?

[ryantm]

The way to accomplish a "blind edit" is to first rm the secret file.