Don't encourage quoting mistakes and security holes about envoy HOT 6 CLOSED

I'm certainty not going to stop someone from placing a security hole in their naïve code.

I'm definitely not against adding more proper argument support though. Nick Coghlan has been doing some great work recently with his "shell-command" module that prevents shell injection. I've been considering adding that functionality into envoy.

from envoy.

Only supporting lists (or unpacking a sequence-of-strings in general) would, in fact, stop people from making tiny mechanical errors that result in subtle problems. Subprocess used this fairly brutal (but definitely correct) way of preventing the problem: you have to opt-in to interpolations that could make yourself unsafe with shell=True with subprocess. Getting what you expect all the time (rather than some of the time) with a naïve program is a positive property. Rather, one cannot prevent someone from going out of their way to cause a problem.

Notably, just like the database drivers, this work by Nick Coghlan has to interpolate his own strings, thus matching every expansion to exactly one argv.

It would take more work, but what about using the new-style format-string parser? Then one could write

envoy.run('ls -l {directory}', directory='./place')

or

envoy.run('ls -l {0}', './place')

The downside is that str.format exists only to format strings, and you have many additional operators (some of which may credibly named 'directory') that clutter the namespace. One bizarre way one could get around this might be having a subclass of string (or something that's just structurally typed similarly) with a very, very special format operator. I'm not sold on the idea, but it's something to think about:

>>> cmd = Command('ls -l {place}')
>>> cmd.format(place='./')
BoundCommand('ls -l "./")
>>> envoy.run(cmd)
...<stuff>

Here, BoundCommand's internal representation would actually take form of a sequence closely matching argv, this is just one possible way to render it (with quoting and escaping).

from envoy.

The whole point of the project is to make lists and creating such instances unnecessary. I don't mind supporting safer behaviors, but any simple command that works on the command line should work here as a regular string.

from envoy.

That recipe has evolved into a more formal project here: http://pypi.python.org/pypi/shell_command

from envoy.

Maybe adopt that, then? I also like the treatment of globs, whereby one is intended to get exactly one argv per match in the file system.

I suppose one useful embellishment might be to support dictionary replacement to look even more like str.format.

As-is, though, I saw someone using envoy for the first time today and in the very first program I see has a quoting hazard.

shell_command seems to use the same general style as psycopg2. The latter only has the disadvantage of using the long-standing but now allegedly obsolete string formatting language, the former uses a POSIX-Python hybrid-inspired notation...but nonetheless, it is a new notation. psycopg2 also leaves a nice warning liberally sprinkled via cross-reference in the docs.

Ease of use is important -- and could very well lead to fewer programs being written in bash, which just makes it nearly impossible to solve this problem -- but the main problem with bash, in my mind, is this defect of handling argv. The authors of the Plan9 shell took an opportunity address this error, but do not have a verbose syntax to convey the literals, perhaps it can also provide input?

http://cm.bell-labs.com/sys/doc/rc.html

from envoy.

This project is in a bit of a crisis state — it's really useful, and I use it on a daily basis. However, I wrote it in a few afternoons several years ago and haven't touched it since. In order to get the project into a stable state I'm closing all issues and pull requests

Don't take this as aggressive — it's just necessary for the project to make any progress any time soon (it's pretty clear the project is effectively unmaintained at the moment). Great things to come! Please watch the GitHub logs and feel free to re-open this discussion soon. I just need to really it into a good state first.

✨ ❤️ ✨

from envoy.