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.
On Wed Dec 31 2014 at 3:01:53 PM Nick Coghlan email@example.com wrote:
On 31 December 2014 at 12:32, Donald Stufft firstname.lastname@example.org 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.
-- Nick Coghlan | email@example.com | Brisbane, Australia