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

Make encrypt, decrypt, rotate, set, and edit proper commands #1333

Closed
felixfontein opened this issue Oct 29, 2023 · 0 comments · Fixed by #1391 · May be fixed by #1343
Closed

Make encrypt, decrypt, rotate, set, and edit proper commands #1333

felixfontein opened this issue Oct 29, 2023 · 0 comments · Fixed by #1391 · May be fixed by #1343

Comments

@felixfontein
Copy link
Contributor

Right now there are a few explicit commands (exec-env, exec-file, publish, keyservice, groups, updatekeys, help), and several implicit ones (--encrypt, --decrypt, --rotate, --set, edit), some pseudo-commands which only work with other commands (--extract with --decrypt, --rm-* and --add-* with --rotate).

This is pretty confusing, both from the sops --help output and also from the code (it is not trivial to figure out which of the flags are commands), and we have a long list of top-level flags which are only used in some of the commands, or even just one (like --extract, --rm-*, --add-*).

I think it would be better long term to migrate all "flag commands" (--encrypt, --decrypt, --rotate, --set, and the fallback 'edit') to proper subcommands. I would do this in three steps:

  1. Add proper commands (additionally to the existing flag commands).
  2. Eventually deprecate the use of global flags outside of the (flag) commands where they are really needed.
  3. Eventually deprecate the flag commands themselves.
  4. Eventually remove the flag commands, and remove global flags for command-specific options.

1. should be done soon, 2. better sooner than later (this also makes the situation less confusing by telling users that the option they provided isn't actually used by the command they try to use), and 3. should only happen in a longer time (some years from now), and 4. even further in the future (say, at least 4-5 years?).

What do you think?

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