[Distutils] Surviving a Compromise of PyPI - PEP 458 and 480

[Richard Jones]

Now that I think about it, I'm almost certain that Donald and I have had
the "hey, what about an upload.pypi.python.org" conversation in the past,
as a way around issues involving the CDN :)

Still a good idea, in my opinion.


    Richard


On Wed Dec 31 2014 at 3:01:53 PM Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 31 December 2014 at 12:32, Donald Stufft <donald at stufft.io> wrote:
>
>> PyPI trusts the CDN to give it the correct bits, without a signature from
>> the author that is being verified uploading just relies on TLS again. The
>> other PEP should close that gap though I believe.
>>
>
> I'm actually not sure what going through the CDN is buying us on the
> upload side of things in the first place, given the main pay-off provided
> by a CDN is geographically distributed caching of unchanging data for
> faster downloads.
>
> So it seems to me that that particular vulnerability could potentially be
> fixed more simply by bypassing the CDN entirely for the upload case. That's
> simplicity in the *conceptual* sense, though - there may be architectural
> issues in the current implementation of PyPI and the related tools that
> make it harder in practice than it would be in theory.
>
> Either way, I agree that any kind of upload compromise based attack is
> also out of scope for PEP 458 - that's now entirely about ensuring that the
> bits delivered to end users are the same bits PyPI published. Making sure
> that the bits *PyPI* publishes are the same ones that the *developer*
> published is the domain of PEP 480.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20141231/8c92e882/attachment.html>