On 1 September 2014 17:13, Christian Heimes email@example.com wrote:
On 01.09.2014 08:44, Nick Coghlan wrote:
Yes, it would have exactly the same security failure modes as sitecustomize, except it would only fire if the application imported the ssl module.
The "-S" and "-I" switches would need to disable the implied "sslcustomize", just as they disable "import site".
A malicious package can already play havoc with your installation with a custom ssl module. If somebody is able to sneak in a ssl.py then you are screwed anyway. sslcustomize is not going to make the situation worse.
That's not quite true - we're fairly careful about putting the standard library before userspace directories, so aside from the "current directory" problem, shadowing "ssl" itself can be tricky to arrange. "sslcustomize" would be more like "sitecustomize" - since it wouldn't normally be in the standard library, it can appear anywhere on sys.path, rather than having to be injected ahead of the standard library.
I think that's OK though - compared to the security nightmare that is downloading modules from PyPI and running "./setup.py install" (or, even worse, "sudo ./setup.py install"), this would be a rather esoteric attack vector, and the existing -S and -I mechanisms could be used to defend against it :)