Re: pre-PEP: transition to release-file hosting at pypi site

On Mar 12, 2013, at 3:57 PM, holger krekel <[email protected]> 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 <[email protected]> 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
>> https://www.djangoproject.com/download/1.5/tarball/)
>> * 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
>> days.]
>> 
>> 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.

> 
> holger
> 
>> Jacob
>> _______________________________________________
>> Catalog-SIG mailing list
>> [email protected]
>> http://mail.python.org/mailman/listinfo/catalog-sig
>> 
> _______________________________________________
> Catalog-SIG mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/catalog-sig


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

_______________________________________________
Catalog-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/catalog-sig

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)

iQIcBAEBAgAGBQJRP4mWAAoJEG48vOkzctz6C30P/23VCL5FE4uM3A5SSsSYczNd
OQOS6jsH629lQfn8h0vTiSpCUqGe5aGtG0Z+niYHxr5ynfSzfl3B67wO87AKl9iz
y8gMei1/AYp1+9xZC/8RFvWlSy0ZpLDWT5YEfUxgKfGonOIRo6JgIV2CeJoRwVmZ
moK15C+4uOX0yjB9PpFiMO1a+6ybLZxRQiMex20zasBSv35h3ajJfCI3kmt6L9c4
u68zllirG/38kjcoVgRfBQjJwDIZmoY2zJczyQu3/Lxj9f24UjeTxqYPryWeUGEh
kAySDEsxeor+xGyO3DK1utCqTbA1YNK8a/f6/dhkKOvMJNj6TjD73le+E6n0o/aA
YRelFz7V4gSz1/w06oyqSvxFWENH9ck1N94O2I+ZTBDG/5R9o1UzfsNZKtjCtmxe
gBZB7dhMav3lavo1os0R2R3CfMLN6s8Z0mrqN2JrRIwP1KYUmbojQPS0LnC82+m8
Ri2SWVKgnYIUtBpa+m6Kde9CNyGhza8x22HnI/5dGaC+2EED1ACT0fbN+ZM2geKC
eNElgbdoDr57jiX+4wQFh57MbMjfyve49Mvu9drwVGX3JJsH1Ce+uRcDg1kFomGX
62WgeXtJcar9jbTfWjTXxnUo9J/fDWU4pp3NK/xciYPAUkHrqBQh62Huhmetezpz
8p7Wu5/RRGmTQqigruBg
=9pri
-----END PGP SIGNATURE-----