On Wednesday, February 27, 2013 at 11:30 AM, Ronald Oussoren wrote:
> The security bits are still in flux, AFAIK both proposals won't require SSL 
> for the 
> actual download to be secure.

The proposals you are talking about should not be depended on solely, the best
method for hosting a secure infrastructure is "defense in depth". Basically you
know you cannot make a perfect system, so you attempt to join several imperfect
systems together with the idea that each one makes it harder to compromise.
> > > 
> > > Instead of suggesting to removing support for externally hosted packages,
> > > why not propose a mechanism to provide a more direct/secure way to
> > > reference them ?
> > > 
> > 
> > I did mention a method for doing that in my email. However there are reasons
> > beyond the security ones to require packages being hosted on PyPI. Namely
> > uptime, privacy, and performance.
> > 
> You only mentioned restricting downloads to the 'Download-URL' property in 
> the 
> package metadata. Another alternative would be to add a PyPI API for 
> registering
> specific downloads with the same restrictions on filenames as for files 
> hosted 
> by PyPI itself.  With that PyPI could be queried for the exact downloads 
> associated
> with a release instead of having to perform screen scaping.

Yes, I did not mention every possible method. There are again other reasons for
keeping things centralized. Remember that not every user of Python nor PyPI
is located in a country where they can reasonably assume that traffic is not
being watched or meddled with. https://ooni.torproject.org/ attempts to catalog
this (using Python by the way!).
> At this time I don't know if requiring that files are hosted on PyPI is a 
> good idea,
> as Marc-Andre said there are reasons for hosting them elsewhere.  That might
> change when the package signing infrastructure is further specified.
> Ronald
> P.S. And only using downloads hosted on PyPI doesn't require changes to PyPI
> anyway, just patches to pip and setuptools :-)

I have issues for pip and buildout currently, and plan to file more. However 
is a lot of old versions of these software in use that would benefit from PyPI 
this change. 
> > _______________________________________________
> > Catalog-SIG mailing list
> > Catalog-SIG@python.org (mailto:Catalog-SIG@python.org)
> > http://mail.python.org/mailman/listinfo/catalog-sig

Catalog-SIG mailing list

Reply via email to