bad quotes for home directory about python-gnupg HOT 1 CLOSED

Unfortunately, the parser kind of has to work that way to prevent the type of shell injection vulnerabilities which are (are?/were? Dude keeps claiming the issue's fixed, and everytime I check, it's not) possible with upstream python-gnupg. :/

For example, take a server with a webapp which uses python-gnupg. Through someone writing some stupid code where a remote user can influence the server's usage of any of the arbitrary string arguments which GnuPG often expects, the user could remotely run arbitrary (unauthorized) commands on the server. I.e. the user would convince the python-gnupg-using server to do gpg=gnupg.GPG(homedir="foo bar\"&socat - TCP-CONNECT:localhost:8080,crnl\"") or gpg.verify_file('somefilename', sig_file="\"&coproc /bin/bash\"") or whatever.

So… that _parsers._fix_unsafe() function is one of the last resorts in fixing these arbitrary strings (as you probably guessed). The problem in that sanitising arbitrary strings is a pretty much impossible task. One of the best ways to do it for a shell is with the quoting tricks I've added. Because there is a space in your directory, python-gnupg adds an extra layer of quotes for good measure (because who knows if you're trying to trick the server).

The reason that this is behaving differently now is that on Unix systems, the invocation of subprocess.Popen uses shell=False (it's sadly still True on Windows, otherwise nothing works). So on Unix systems now, the arguments should be sent through the absolutely terrifying function subprocess.list2cmdline() before being sent to directly to the OS's execve (see man 2 execve). I could possibly remove the last-ditch defense call to gnupg._parsers._fix_unsafe() since execve is being used. But that list2cmdline() function is horrible, and I'm scared to trust it.

Because of that, and because I've chosen to err on the side of caution in python-gnupg, I'm not willing to remove the call to _fix_unsafe(). Any directory, whether it's relative or absolute, will have an extra layer(s) of quotes around it if its path includes any whitespace, escaped quotes, ;, ^, or &. Sorry, closing as wontfix.

from python-gnupg.