[Catalog-sig] V4 Pre-PEP: transition to release-file hosting on PYPI

[holger krekel]

On Fri, Mar 15, 2013 at 22:01 -0400, PJ Eby wrote:
> On Fri, Mar 15, 2013 at 7:16 PM, Carl Meyer <carl at oddbird.net> wrote:
> > Ok, pending agreement from Holger I'll make a change in the PEP to
> > explicitly allow clients to make decisions based on either the rel
> > attributes or based on hostnames. Would that be sufficient to address
> > your concerns?
> 
> Yes.  I just don't want to be in a situation down the road where
> there's another argument about this on Catalog-SIG when PyPI starts
> using a CDN that, "but it says this in the rel and you're supposed to
> use that", and I say, "but Carl and Holger said..."  and they go,
> "doesn't matter, PEP says"   ;-)
> 
> This way, the PEP will be clear that supporting a split of PyPI's
> hostnames isn't in current scope.

> 
> I am also okay with the PEP allowing *.indexhost instead of just
> indexhost as the filtering mechanism, as long as it specifies one
> *now*.  (Again, so this doesn't have to be revisited later.)  If
> somebody who knows something about CDNs, TUF, etc., needs to weigh in
> on it first, that's fine.  I just want to know where things stand.
 
One related question.  The "rel=internal" links will contain
a (md5 currently) hash so if the referenced resource resolves to
a file matching that hash, we can be sure about its integrity.
What kind of security does host-checking add on top?

holger

> > Putting the /simple/ API on a CDN isn't quite that easy because it
> > currently involves some server-side redirects to effectively make
> > project names case-insensitive.
> 
> FWIW, easy_install works fine without this.  If a matching index page
> isn't found, it checks the full package list.  PyPI's redirection just
> reduces bandwidth usage and request overhead in the case where the
> case of the user's request doesn't match the actual package listing.
> But it could be completely static without affecting easy_install and
> tools that use its package-finding code.
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org
> http://mail.python.org/mailman/listinfo/catalog-sig
>