[Catalog-sig] pre-PEP: transition to release-file hosting at pypi site

holger krekel holger at merlinux.eu
Tue Mar 12 20:57:07 CET 2013


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
> 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.

holger

> Jacob
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org
> http://mail.python.org/mailman/listinfo/catalog-sig
> 


More information about the Catalog-SIG mailing list