[Catalog-sig] pre-PEP: transition to release-file hosting at pypi site
donald at stufft.io
Tue Mar 12 21:01:26 CET 2013
On Mar 12, 2013, at 3:57 PM, holger krekel <holger at merlinux.eu> wrote:
> On Tue, Mar 12, 2013 at 14:36 -0500, Jacob Kaplan-Moss wrote:
>> On Tue, Mar 12, 2013 at 2:21 PM, PJ Eby <pje at telecommunity.com> wrote:
>>> The *only* thing I object to is the part where some people want to ban
>>> external links from /simple, always and forever, regardless of the
>>> package authors' choice in the matter.
>> Here's the thing though, there are already a bunch of other ways users
>> can install packages from external repositories. I can think of at
>> least two:
>> * I can pip/easy_install a given URL (e.g. easy_install
>> * I can use a custom index server (pip install -i http://localserver/ django)
>> The important part is that in each of those cases I can see clearly
>> where I'm getting things from.
>> OTOH, if I do "pip install Django" I — the person making the install —
>> have no control over where that package comes from. It really violates
>> people's expectations that this reaches out to somewhere that's
>> not-pypi. More importantly it prevents me from making a security
>> choice -- I literally don't know until the download starts where the
>> file might be coming from.
>>> From where I stand the absolutely non-negotiable part is that
>> `pip/easy_install/whatever package` should NEVER access an external
>> host (after some suitable transition period). This needs to include
>> older installer software, and it needs to make it hard for new tools
>> to do the wrong thing. How this is achieved really doesn't matter to
>> me -- if there's a "pip install --insecure Django" that's fine too --
>> but to me it's non-negotiable that the out-of-the-box configuration
>> not allow external hosts.
>> Yes, this means taking some options away from the package creator. It
>> means that when I'm wearing my author-of-Django hat I can't choose to
>> list Django on PyPI but provide the download elsewhere. That's not
>> perfect, but given a "creator choice" vs "out of the box security"
>> choice the latter has to win. [And as a package creator I still have
>> options: I can run my own package server, fairly easy to do these
>> Again, the *how* isn't a big deal to me, but the result is really
>> important: the tooling has to be secure-by-default, and that means
>> (among other things) `pip install package` can never hit something
>> that's not PyPI without me explicitly asking for it.
> Let's be clear, however, that we are at most reducing attack vectors,
> there are substantial attack vectors left. Nobody should be lead to
> think that PYPI is a trusted or reviewed source of software even
> if we got rid of external hosting completely.
"Trust" depends on your trust model.
PyPI is not and will never be a system where you can pip install random packages and expect nothing bad to happen.
You should however be able to trust that when you `pip install foo==1.0`` you will get exactly that. That it will not have been tampered with. It's up to you to decide is foo 1.0 is something trustworthy. There's handwaving here about what foo 1.0 is defined as. But in general when you ask for X you should get exactly X no more, no less.
>> Catalog-SIG mailing list
>> Catalog-SIG at python.org
> Catalog-SIG mailing list
> Catalog-SIG at python.org
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Catalog-SIG