[Catalog-sig] Deprecate External Links

[Justin Cappos]

Having different sources for package metadata does pose security concerns,
for example version mismatch attacks by a MITM.   Unless we co-locate all
package metadata at a single source that is trusted for protecting against
these issues, this will be an issue.    (However, possibly not the biggest
threat right now.)

I do believe that if you do centralize metadata, you could outsource
mirroring the data if desired without losing the other security goals you
have.

Thanks,
Justin



On Wed, Feb 27, 2013 at 10:39 AM, M.-A. Lemburg <mal at egenix.com> wrote:

> On 27.02.2013 16:26, Donald Stufft wrote:
> > PyPI is now being served with a valid SSL certificate, and the
> > tooling has begun to incorporate SSL verification of PyPI into
> > the process. This is _excellent_ and the parties involved should
> > all be thanked. However there is still another massive area of
> > insecurity within the packaging tool chain.
> >
> > For those who don't know, when you attempt to install a particular
> > package a number of urls are visited. The steps look roughly
> > something like this:
> >
> >     1. Visit http://pypi.python.org/simple/Package/ and attempt to
> >         collect any links that look like it's installable (tarballs,
> >         #egg=, etc).
> >         Note: /simple/Package/ contains download_url, home_page,
> >         and any link that is contained in the long_description).
> >     2. Visit any link referenced as home_page and attempt to
> >         collect any links that look like it's installable.
> >     3. Visit any link referenced in a dependency_links and attempt
> >         to collect any links that look like it's installable.
> >     4. Take all of the collected links and determine which one
> >         best matches the requirement spec given and download it.
> >     5. Rinse and repeat for every dependency in the requirement
> >         set.
> >
> > I propose we deprecate the external links that PyPI has published
> > on the /simple/ indexes which exist because of the history of PyPI.
> > Ideally in some number of months (1? 2?) we would turn off adding
> > these links from new releases, leaving the existing ones intact and
> > then a few months later the existing links be removed completely.
>
> -1.
>
> There are many reasons for not hosting packages and distributions
> on PyPI itself.
>
> If you use and trust a package, you also have to know and trust its
> dependencies, no matter where they are hosted, so you're not gaining
> any security by disabling links to other download locations: if
> you don't trust the way a package is hosted, you don't use it; if
> you do, then removing the link breaks the package and all its
> dependencies.
>
> Instead of suggesting to removing support for externally hosted packages,
> why not propose a mechanism to provide a more direct/secure way to
> reference them ?
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source  (#1, Feb 26 2013)
> >>> Python Projects, Consulting and Support ...   http://www.egenix.com/
> >>> mxODBC.Zope/Plone.Database.Adapter ...       http://zope.egenix.com/
> >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
> ________________________________________________________________________
>
> ::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::
>
>    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>            Registered at Amtsgericht Duesseldorf: HRB 46611
>                http://www.egenix.com/company/contact/
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org
> http://mail.python.org/mailman/listinfo/catalog-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130227/75c61c96/attachment-0001.html>