cole-h / agenix-cli Goto Github PK

Hey,

I will shortly explain a use case: I have two systems, each of them has two secrets. If I change the key for system A, I want to run rekey and only update the secrets that are affected by the change of the key of system A. Currently, all four secrets will be updated.

├── system-a/
│   ├── secret-1
│   └── secret-2
└── system-b/
    ├── secret-1
    └── secret-2

1. Is it possible for agenix to recognize that only two of the four secrets should be updated?
2. If not, could you add a possibility that the CLI accepts multiple files instead of only one? (like agenix -r secrets/a secrets/b)

On a system where a user has a default passphrase protected rsa and/or ed25519 key, agenix throws errors, even if the identity is explicitly declared as an alternate key,:

# Specify a cwd non-passphrase protected ed25519 key:

❯ agenix -vvv -i ./id_ed25519 test-encrypted/test.age
DEBUG checking '/home/$USER' for .agenix.toml config
DEBUG found config at '/home/$USER/.agenix.toml'
TRACE validate_config? false
TRACE rekey? false
TRACE path.is_none()? false
TRACE got valid ssh identity 'ssh-ed25519 <snip> testkey'
DEBUG using ["./id_ed25519", "/home/$USER/.ssh/id_rsa"] as identity file(s)
Error: 
   0: Failed to decrypt file 'test-encrypted/test.age'
   1: Failed to get usable identity or identities
   2: /home/$USER/.ssh/id_rsa: EncryptedPem

Location:
   src/cli.rs:703

Now, let's remove the offending passphrase protected key which it is choking on to make it work:

❯ mv ~/.ssh/id_rsa ~/.ssh/id_rsa-tmp-rename
❯ agenix -vvv -i ./id_ed25519 test-encrypted/test.age
DEBUG checking '/home/$USER' for .agenix.toml config
DEBUG found config at '/home/$USER/.agenix.toml'
TRACE validate_config? false
TRACE rekey? false
TRACE path.is_none()? false
TRACE got valid ssh identity 'ssh-ed25519 <snip> testkey'
DEBUG using ["./id_ed25519"] as identity file(s)
TRACE rekey? false
TRACE encrypt_in_place? false
DEBUG editor: 'vim'
DEBUG args: 'None'
WARN  contents unchanged, not saving

The upstream age reference shows that if the default user rsa and ed25519 keys it checks are passphrase protected, it will prompt if needed, or silently ignore any passphrase errors.

Here it is blocking instead. It seems it would be better to adopt the upstream behavior so users aren't forced to move their default keys if password protected?

$ /home/ryantm/p/agenix-rs/result/bin/agenix p-vpn.age
Error:
   0: Failed to spawn editor 'emacsclient -t'
   1: No such file or directory (os error 2)

Location:
   src/cli.rs:245

Looks like it doesn't like that my EDITOR env var has commandline arguments.

For now, I've just commented out the offending stuff (see 73e0733).

That way you can agenix ~/some/path/to/a/secret from anywhere and it will pick up the correct configuration.

The main reason I used a HashSet instead of a Vec was to avoid rekeying a file multiple times in case it is matched by multiple patterns, but I just realized that this case isn't covered in the encryption/decrytion code either. How/if that should be handled is probably something for a later point in time. (Maybe a note about that could be added to the readme for the meantime.)

Originally posted by @LogicalOverflow in #7 (comment)

@cole-h I'm newly interested in this because I really want to fix ryantm/agenix#4 I tried it out some. It seems like it doesn't support rekeying all the paths at once. Is that right? If not, I'm up for trying to add that feature to learn more about the code.

Originally posted by @ryantm in ryantm/agenix#23 (comment)

Some things to consider:

• What if a path or paths can't be decrypted (private key is not present)? Should we just skip those paths (and report them at the end), or abort the entire operation? (That would probably require a temporary staging directory where we just move the secrets to their proper places afterwards)
• ... (more as I think of them)

Hey,

It seems that one of the dependencies of this project uses stdenv.lib (I've reported it to nixpkgs-mozilla already, hopefully a fix comes soon), and as such prevents building on the current unstable-small branch. The current workaround is to force this to follow stable, since the alias still exists.