Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow specific files to be re-encrypted with --rekey #149

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

devplayer0
Copy link

@devplayer0 devplayer0 commented Sep 1, 2024

Sometimes it's useful to rekey only specific secrets. This change allows
paths to be passed to the --rekey option in order to only re-encrypt
them, defaulting to all as before.

An example of where this is useful is when adding a new machine to a centralised repo with many secrets, where only a few that are shared between all configs need to be rekeyed.

Copy link
Member

@veehaitch veehaitch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for doing this! This seems like a useful addition. However, I wonder if --rekey-one is the best name. Actually, you can rekey multiple files. Without thinking too much about it, wouldn't it be possible to make the --rekey option accept the file paths while defaulting to all secrets if no argument is given (to maintain backward compatibility)?

Sometimes it's useful to rekey only specific secrets. This change allows
paths to be passed to the `--rekey` option in order to only re-encrypt
them, defaulting to all as before.
@devplayer0 devplayer0 changed the title Add --rekey-one option Allow specific files to be re-encrypted with --rekey Sep 5, 2024
@devplayer0
Copy link
Author

Thanks for doing this! This seems like a useful addition. However, I wonder if --rekey-one is the best name. Actually, you can rekey multiple files. Without thinking too much about it, wouldn't it be possible to make the --rekey option accept the file paths while defaulting to all secrets if no argument is given (to maintain backward compatibility)?

Yeah that's a good point, it's definitely neater that way. I've updated the PR to implement this.

@@ -35,10 +35,12 @@ fn build() -> Command {
)
.arg(
Arg::new("rekey")
.help("re-encrypts all secrets with specified recipients")
.help("re-encrypts secrets with specified recipients")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
.help("re-encrypts secrets with specified recipients")
.help("re-encrypts all or the given secrets with specified recipients")

* `-r`, `--rekey`:
Decrypt all secrets given in the rules configuration file and encrypt them
with the defined public keys. If a secret file does not exist yet, it is
* `-r`, `--rekey` [PATH]:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please also add the [PATH] to the synopsis section.

Comment on lines +41 to +56
} else if let Some(paths) = opts.rekey {
if paths.is_empty() {
// Option passed but no files specified - rekey all
ragenix::rekey(&rules, &identities, true, &mut std::io::stdout())?;
} else {
let paths_normalized = paths
.into_iter()
.map(util::canonicalize_rule_path)
.collect::<Result<Vec<PathBuf>>>()?;
let chosen_rules = rules
.into_iter()
.filter(|x| paths_normalized.contains(&x.path))
.collect::<Vec<ragenix::RagenixRule>>();

ragenix::rekey(&chosen_rules, &identities, false, &mut std::io::stdout())?;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be better if you did this in the ragenix module. Since you are already adding a new parameter to rekey, it could be the given paths. Alternatively, adding a new rekey_{some,given,chosen} function is also fine for me.

@veehaitch
Copy link
Member

Ah, and also please update the usage section of the README 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants