[Distutils] PEP 470 discussion, part 3

[Richard Jones]

Thanks for responding, even from your sick bed.

This message about users having to view and understand /simple/ indexes is
repeated many times. I didn't have to do that in the case of PIL. The tool
told me "use --allow-external PIL to allow" and then when that failed it
told me "use --allow-unverified PIL to allow". There was no needing to
understand why, nor any reading of /simple/ indexes.
Currently most users (I'm thinking of people who install PIL once or twice)
don't need to edit configuration files, and with a modification we could
make the above process interactive. Those ~3000 packages that have internal
and external packages would be slow, yes.

This PEP proposes a potentially confusing break for both users and
packagers. In particular, during the transition there will be packages
which just disappear as far as users are concerned. In those cases users
will indeed need to learn that there is a /simple/ page and they will need
to view it in order to find the URL to add to their installation invocation
in some manner. Even once install tools start supporting the new mechanism,
users who lag (which as we all know are the vast majority) will run into
this.

On the devpi front: indeed it doesn't use the mirroring protocol because it
is not a mirror. It is a caching proxy that uses the same protocols as the
install tools to obtain, and then cache the files for install. Those files
are then presented in a single index for the user to use. There is no need
for multi-index support, even in the case of having multiple staging
indexes. There is a need for devpi to be able to behave just like an
installer without needing intervention, which I believe will be possible in
this proposal as it can automatically add external indexes as it needs to.

I talked to a number of people last night and I believe the package
spoofing concept is also a vulnerability in the Linux multi-index model
(where an external index provides an "updated release" of some core package
like libssl on Linux, or perhaps requests in Python land). As I understand
it, there is no protection against this. Happy to be told why I'm wrong, of
course :)


      Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140724/1084130f/attachment.html>