Is your feature request related to a problem? Please describe.
Sensitive data like a password should not be arguments of a CLI. They would end up appearing in the CLI history.
Describe the solution you'd like
If an argument is named password or key or some other common name for sensitive data, report an issue.
A fix suggestion would be to interactively prompt for passwords as hidden stdin instead using getpass.getpass()
As described in the CLI standard:
Do not read secrets directly from flags. When a command accepts a secret, eg. via a --password argument, the argument value will leak the secret into ps output and potentially shell history. And, this sort of flag encourages the use of insecure environment variables for secrets.
Consider accepting sensitive data only via files, e.g. with a --password-file argument, or via stdin. A --password-file argument allows a secret to be passed in discreetly, in a wide variety of contexts.
(It’s possible to pass a file’s contents into an argument in Bash by using --password $(< password.txt). This approach has the same security issue of leaking the file’s contents into the output of ps. It’s best avoided.)
Is your feature request related to a problem? Please describe. Sensitive data like a password should not be arguments of a CLI. They would end up appearing in the CLI history.
Describe the solution you'd like If an argument is named password or key or some other common name for sensitive data, report an issue.
A fix suggestion would be to interactively prompt for passwords as hidden stdin instead using getpass.getpass()
As described in the CLI standard:
Describe alternatives you've considered n/a
Additional context
Love this idea? Give it a 👍. We prioritize fulfilling features with the most 👍.