Add a command-line interface to the secrets module

Ideas
23

These conversations all go the same way…

“It’s consistent with some other module that has a CLI”. But it’s also inconsistent with the ones that don’t. Also who cares? A CLI should be justified on its own utility – not because somewhere else there’s also a CLI.

“Quoting! YAML! Shellisms!” You can skip worrying about any of this if you use double quotes on the outside:

python -c "
print('python code here')
"

You can put anything other than \, " and $ between those double quotes and it’ll work in any shell. Most shells other than cmd even come with good enough multiline editing support that you can just type it in like that. If you need to get a windows file path in there without worrying about escape characters or to avoid nested quotes then you can use sys.argv:

python -c "import sys; filename = sys.argv[1]; do_something(filename)" "filename\with spaces\here.txt"

It’s not completely Turing complete[1] but it can handle everything that could be done by adding a module CLI whilst still only using cross shell syntax.

And YAML’s funky rules aren’t issues as long as the first character of the string is a boring one (that p for python -c is boring).

For automation/code agents it’s even easier. Any language with a list-args subprocess API can use their equivalent of either:

subprocess.run(["python", "-c", python_source_code])
subprocess.run(["python", "-"], input=python_source_code.encode())

In both cases, python_source_code requires no escaping or sanitisation at all. And both can use the same sys.argv trick as above to avoid having to construct python_source_code via icky/unsafe string substitutions.

And yes, not everyone knows this stuff but Python shouldn’t be growing appendages so that people can avoid learning to safely passing strings between processes. That knowledge can be gained in minutes and is far more widely useful than any number of module CLIs.

  1. at least not without restoring to stuff like special_string = bytes([63, 34, 92, 36]).decode() or exec(base64.b64deocde('anything')) ↩︎

2 Likes
24

I don’t think it’s necessarily a problem for the modules with CLIs (vs not) to be somewhat ad-hoc and that each one is independently motivated. There are downsides to it, but also benefits – practicality vs purity.

What is a problem, however, is that nobody – not even those with lots of experience; not me, not you, and not Guido – knows what the policy for new module CLIs is.

Whenever a new CLI comes up, we end up with different views on whether or not this time is finally the time to solve the policy problem, and the conversation often goes in circles.

I believe that the policy question needs to be solved simply so that conversations like this thread can be held in a productive manner. I don’t particularly care about python -m secrets, but I am somewhat tired of seeing us debate the same points on this forum over and over (often the same folks, with similar opinions to the ones they held last time, and 1-2 new interlocutors).

13 Likes
25

Nice. I use json often for pretty printing. One that I know isn’t on there is pathlib, because I made PathlibIO (PyPI) as a wrapper around most of pathlib.Path’s methods for testing and transforming paths on the command line

$ pathlibio is_dir / && echo Yes
Yes
$ pathlibio owner /etc/passwd
root
$ pathlibio with_suffix dog.png .jpg
dog.jpg

The point being that one could always create one’s own simple wrapper module around secrets for the meantime and put it on PyPI + install with pipx, if there are differing opinions on what it should do and whether the module should be runnable at all?

1 Like
26

I closed the issue because as someone who maintains cryptographic parts of the stdlib I didn’t find this convincing. I’ll expand a bit my rationale though:

  • TL;DR: use fire or create a PyPI module for CLIs.
  • I personally don’t like exposing a simple python -m secrets endpoint since there other secrets that could be generated and it depends on who will be using that module. On the other hand, if we were to add all possible generations with arguments as well, then this would be overly complex for a module that is initially meant to be simple.
  • I am not convinced that we need to generate tokens in a CLI more than a few times, and while it could be used to generate tokens in a Bash script instead of a Python script for instance, I still don’t think it would really be more helpful than using python -c 'import secrets; print(secrets.token_urlsafe())'.
  • Using python -m secrets as an alternative would be more obscure. When someone reads python -m secrets they will not necessarily know which kind of secrets is being generated. Today, maybe it’s tokens that want to be generated, but what if tomorrow it’s something else? So, if we were to have a CLI, we should be explicit.
  • I rejected my own proposal on having hashlib CLI because I was eventually convinced that it would likely not that common in a CLI.
5 Likes