[This is not a response to anything that Nick wrote. -- I don't have the
rest of the thread, so unfortunately I've to paste from the archive.]
Paul:
> I'll give up the fight at this point. I don't know this part of the
> pip code well enough to offer a patch implementing my suggestion, and
> in any case I think that duelling patches is a very unhealthy thing
> for a project. So as you did the work, I'll accept your view. But
> could I ask that in future debates like this, if anyone suggests that
> the pip developers are mandating the current behaviour, that mistake
> is immediately corrected to point out that it's the PEP 438 authors
> who are in fact doing this (and that pip is merely following the
> requirements in that PEP)? I will certainly do this myself.
Thank you for your measured responses, and I agree with you that pip should
follow PEP 438. The main argument on python-dev was about *editorializing*
the contents of the PEP in both pip warning messages and posts to the mailing
lists (and by that I certainly do *not* mean your posts).
The PEP appears to say:
"Installers should provide a blanket option to allow installing any verifiable
external link."
Perhaps something like --allow-verifiable-external would do? I would not be
unhappy if link-spidering were to be removed, I find it reasonable to provide
the explicit link.
But don't take that too seriously, some important looking packages rely on
link spidering:
https://pypi.python.org/pypi/bzr/2.6.0
https://pypi.python.org/pypi/meliae/0.4.0.final.0
https://pypi.python.org/pypi/CobraWinLDTP/4.0.0
https://pypi.python.org/pypi/PloneIISApp/4.2
https://pypi.python.org/pypi/which/1.1.0
https://pypi.python.org/pypi/python-cjson-custom/1.0.3x7
https://pypi.python.org/pypi/CAGE/1.1.4
https://pypi.python.org/pypi/libavg/1.8.0
https://pypi.python.org/pypi/BlogBackup/1.4
https://pypi.python.org/pypi/Polygon3/3.0.6
https://pypi.python.org/pypi/Pygame/1.8.0
https://pypi.python.org/pypi/DOLFIN/1.3.0
https://pypi.python.org/pypi/snippet/2.3.6.1
https://pypi.python.org/pypi/savReaderWriter/
https://pypi.python.org/pypi/PyCY/1.0.0
https://pypi.python.org/pypi/WikklyText/1.6.0
https://pypi.python.org/pypi/python-lzo/1.08
https://pypi.python.org/pypi/blockcanvas/4.0.3
https://pypi.python.org/pypi/boolopt/1.0
https://pypi.python.org/pypi/egenix-mx-base/3.1.0
https://pypi.python.org/pypi/egenix-mx-commercial/2.0.7
https://pypi.python.org/pypi/python-musicbrainz2/0.7.2
https://pypi.python.org/pypi/OpenAlea/0.9
Donald:
> Stefan was using it but has since removed it because he was upset
> over a *warning*.
Not quite the sequence of events. -- I left the existing explicit link
for some time after the first posts to python-dev. Then serious security
issues were marginalized ("not a meaningful scenario"). I find this a
little surprising, since PEP 458 is precisely there to address them.
The user base that cdecimal targets (banks, stock exchanges, scientists)
are able to verify checksums -- in fact in some places it might be a
firing offense not to do so.
Mocking that procedure (as has happened in certain channels) is not very
productive.
Before the thread on python-dev switched to external vs. internal, my
major point was that pip users might get the impression that internal
packages are safe and external packages are unsafe.
Justin Cappos:
> Perhaps it would be good to require a project key for external packages
> since their packages lose many of the other protections against
> mix-and-match attacks, timeliness attacks, etc.
That could be an option, but the effect on authors needs to be considered.
For example, inria.fr authors may not want to go through the bureaucratic
hassle of getting permission to sign something.
Stefan Krah
_______________________________________________
Distutils-SIG maillist - [email protected]
https://mail.python.org/mailman/listinfo/distutils-sig
