-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 +1 for the proposal
The complete discussion on this topic is once again absurd and bizarre. We are discussing the issue with externally hosted packages every year and the situation has not improved. Especially people using "buildout" encounter very regulary issues with external site being down - with the result that we can not install or update our installation. I give a shit at the arguments pulled out every time by package maintainers using PyPI only for listing their packages. I am both annoyed and bothered by these people. My recommendation: if you want to use the PyPI resources for listing your packages _then_ upload your packages to PyPI _OR_ stay away from PyPI and be silent for ever. The egocentricity of some people defeating their external hosting is now after years laughable. So one again: either accept and use PyPI and leave it and go away. Andreas Donald Stufft wrote: > PyPI is now being served with a valid SSL certificate, and the > tooling has begun to incorporate SSL verification of PyPI into the > process. This is _excellent_ and the parties involved should all be > thanked. However there is still another massive area of insecurity > within the packaging tool chain. > > For those who don't know, when you attempt to install a particular > package a number of urls are visited. The steps look roughly > something like this: > > 1. Visit http://pypi.python.org/simple/Package/ and attempt to > collect any links that look like it's installable (tarballs, #egg=, > etc). Note: /simple/Package/ contains download_url, home_page, and > any link that is contained in the long_description). 2. Visit any > link referenced as home_page and attempt to collect any links that > look like it's installable. 3. Visit any link referenced in a > dependency_links and attempt to collect any links that look like it's > installable. 4. Take all of the collected links and determine which > one best matches the requirement spec given and download it. 5. Rinse > and repeat for every dependency in the requirement set. > > I propose we deprecate the external links that PyPI has published on > the /simple/ indexes which exist because of the history of PyPI. > Ideally in some number of months (1? 2?) we would turn off adding > these links from new releases, leaving the existing ones intact and > then a few months later the existing links be removed completely. > > Reasoning: 1. It is difficult to secure the process of spidering > external links for download. 1a. The only way I can think offhand is > by requiring uploading a hash of the expected files to PyPI along > with the download link and removing all urls except for the > download_url. This has the effect that only 1 file can be associated > with a particular release. 2. External links decrease the expected > uptime for a particular set of requirements. PyPI itself has become > very stable, however the same cannot be said for all of the hosts > linked that the toolchain processes. Each new host is an additional > SPOF. > > Ex: I depend on PyPI and 10 other external packages, each service has > a 99% uptime so my expected uptime to be able to install all my > requirements would be ~89% (0.99 ** 11). 3. Breaks the ability for a > CDN and/or mirroring infrastructure to provide increased uptime and > better latency/throughput across the globe. 4. Privacy implications, > as a user it is not particularly obvious when I run `pip install Foo` > what hosts I will be able issuing requests against. It is obvious > that I will be contacting PyPI and I will have made the decision to > trust PyPI however it is not obvious what other hosts will be able to > gather information about me, including what packages I am installing. > This becomes even more difficult to determine the deeper my > dependency tree goes. > > _______________________________________________ Catalog-SIG mailing > list Catalog-SIG@python.org > http://mail.python.org/mailman/listinfo/catalog-sig - -- ZOPYX Limited | Python | Zope | Plone | MongoDB Hundskapfklinge 33 | Consulting & Development D-72074 Tübingen | Electronic Publishing Solutions www.zopyx.com | Scalable Web Solutions - -------------------------------------------------- Produce & Publish - www.produce-and-publish.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQGUBAEBAgAGBQJRLu1eAAoJEADcfz7u4AZjLKMLviUYcIT4l+nimNyQRV+vqmHK huSIXeqkhjX2F/RvYvPh/sVU3H8Llt2JejocfsC5gJe3VmzlNUvo37QtB+yddGxC APGSwUPFPe1AOwy1x4cBoIhyjKSRtCVOMIAkX6uUSN9o7v16oYoFGNpoyOErUqk0 Hdb26dH1JPg6FvO2SVYrLakStRgE0gPYcLsp+yiQb/WyvFga154D7ZFtX2zrG3E8 hhZ7wib5ov8I5Xi8O4mOVovwaYufL2DiwByf0xcioc6ljCVHoNLjDL1hTiiew20r XDbTTv+8h7p+qt7UdeTak9G3L9TrHPX3H4WOALxPHdZI8dESJ6Wn5gKWwg+imwMh DWuvonfLfLsiSxgi5ZW6U6jo29ud+/RBkoONF+6PkV+Nr1AdmaxzCe8fJDM4PdMA GYgV2hTBQQzHdYony6ECMVWrDI8n0meNCwQhBhr8CDeEicsUeQn+MFehWfzAzVW7 BUCPCO3xCet4T381Zzl0V59nvaQgwKo= =UUqR -----END PGP SIGNATURE-----
<<attachment: lists.vcf>>
_______________________________________________ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
