<p dir="ltr"><br>
On 2 Sep 2014 03:08, "Donald Stufft" <<a href="mailto:donald@stufft.io">donald@stufft.io</a>> wrote:<br>
><br>
><br>
>> On Sep 1, 2014, at 1:01 PM, Christian Heimes <<a href="mailto:christian@python.org">christian@python.org</a>> wrote:<br>
>><br>
>> On 01.09.2014 17:35, Nick Coghlan wrote:<br>
>>><br>
>>> Oh, now I get what you mean - yes, sitecustomize already poses the same<br>
>>> kind of problem as the proposed sslcustomize (hence the existence of the<br>
>>> related command line options).<br>
>><br>
>><br>
>> If an attacker is able to place a module like sitecustomize.py in an<br>
>> import directory or any .pth file in a site-packages directory than this<br>
>> Python installation is compromised. .pth files are insidious because<br>
>> they are always loaded and their code is always executed. I don't see<br>
>> how sslcustomize is going to make a difference here.<br>
>><br>
><br>
> Right, this is the point I was trying to make. If you’ve installed a malicious<br>
> package it’s game over. There’s nothing Python can do to help you.</p>
<p dir="ltr">Yes, that's what I said originally when pointing out that isolated mode and the switch to disable site module processing would need to disable sslcustomize processing as well.</p>
<p dir="ltr">Antoine was replying to a side comment about it being tricky to shadow stdlib modules. I left out the qualifier "directly" in my original comment, and he left out "indirectly through sitecustomize" in his initial reply, so we were talking past each for a while.</p>

<p dir="ltr">Cheers,<br>
Nick.<br></p>
<p dir="ltr">><br>
> ---<br>
> Donald Stufft<br>
> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA<br>
><br>
</p>