On 13 May 2014 12:16, Stefan Krah <[email protected]> wrote: >> I believe that option has been there for a while as >> --allow-[all]-external. Again, naming and discoverability may be an >> issue, but the functionality is available. > > Yes, but I understood that the latest proposals in this thread wanted > to get rid of even this functionality. Did I get that wrong?
My understanding of the latest PR for pip is: 1. There will be a single per-package opt-in flag, that is needed for any package not hosted on PyPI (effectively merging --allow-external and --allow-unverifiable) 2. There will be an "allow any safe external package" flag (--allow-all-external). This is as far as we can go while being compatible with PEP 438. Nick and Donald have made comments about deprecating --allow-all-external and looking at alternatives to the current external link handling. But that will be the subject of a PEP before it gets implemented, and so I'm assuming the final proposal will be acceptable to any interested parties (at least, to the extent that the PEP process works :-)) > With "link-spidering" I mean "everything that pip does when no file is > uploaded and no explicit download link is given". > > The term may be incorrect, but I hope that way it's clear. Thanks. That's clear, but a little general, as pip treats direct links to files it knows are downloadable (sdists, wheels, eggs) differently from any other download links found by spidering (in that having a hash makes direct-linked files "safe"). We're considering alternatives to link-spidering, but I don't believe anyone is suggesting that pip will lose the ability to install files not hosted on PyPI. At a bare minimum, explicit URLs, --find-links and --extra-index-url will always be available. > External and verifiable packages have the same security as uploaded files > (though I would like to use sha256 instead of md5 the URL). Correct (I think it might even be correct for indirectly linked files where each link has a hash, which PEP 438 doesn't consider verifiable - although I'm not a security expert so don't quote me). The PEP is open to sha256 in place of md5, although I don't know if pip supports it. > What is the use case for the opt-in? Unless there are many alternatives > for a package, a user is hardly going to reject a package on the grounds > that the combination of launchpad.net + python.org has a cumulative > uptime of 99.99% instead of 99.999%. Ultimately I'd have to say "it's what the PEP requires". I didn't participate in the discussion on that aspect of the PEP, so I can only assume that the decision was made for sufficient reasons, and nobody raised any objections. It's an explicit goal in the PEP and there's no discussion of counterarguments and their resolution, so I have to assume that no-one argued. Maybe the people who would have argued didn't get involved in the discussion, but the PEP process is the only way we have of addressing that issue, so if it didn't work I'm not sure what else we do. > So, assuming for a moment that the explicit links are present, it would be > reasonable to have the download work by default and have pip emit a neutral > remark (not even a warning): > > "remark: egenix-mx-base is a secure external package." > > FreeBSD ports have been using the download-from-many-but-verify strategy > for a long time. I don't see why users should find this surprising. See my long discussion with Donald earlier in the thread. I started off with a similar view. There's been a lot of discussion on this point (in this thread and probably also at the time the PEP was agreed). It's worth going back and reading that if you want the details. Regardless of the history, Nick is now looking at a different model, and it sounds to me like he's thinking in terms of replacing all link-following with an alternative external hosting model. You're probably better expanding on that with him, as pip will simply end up following the model agreed in whatever PEP comes out of that discussion. Paul _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
