[Distutils] PEP 470 discussion, part 3

[Nick Coghlan]

On 25 Jul 2014 02:05, "Donald Stufft" <donald at stufft.io> wrote:
>
> Sorry, I think the provides functionality is outside of the scope of what
we would use TUF for. It is *only* respected if you have that project
installed. In other words if there is a package “FakeDjango” which provides
“Django”, then ``pip install Django`` will *never* install “FakeDjango”.
However if you’ve already done ``pip install FakeDjango`` then later on you
do ``pip install Django`` it will see that it is already installed (because
“FakeDjango” provides it).

For the record, from a system integrator perspective, this is considered a
feature rather than a bug: it's designed so it's possible to swap in an
alternative to the real package as a temporary measure until the real one
catches up. For example, right now, getting systemd to work right inside a
Docker container is a bit tricky, but you don't really need it if you're
just running one or two services per container. The workaround is a
substitute package called "fakesystemd" - it lets the package installation
proceed, even though the systemd integration won't work. The folks actually
working with systemd inside Docker then swap the fake one out for the real
one.

> IOW it only matters once you’ve already chosen to trust that package and
have installed it. This is to prevent any sort of spoofing attacks and to
simplify the interface. This doesn’t prevent a project which you’ve elected
to trust by installing it from spoofing itself, but it’s impossible to
prevent them from doing that anyways without hobbling our package formats
so much that they are useless. For instance any ability to execute code
(such as setup.py!) means that FakeDjango could, once installed, spoof
Django just by dropping the relevant metadata files to say it is already
installed.

Yep. While it may sound self-serving (because it is - this is ultimately
one of the services that gets me paid), a commercial relationship that
helps assure them "this won't eat your machine" is one of the reasons
companies pay open source redistributors and other service providers for
software that is freely available directly from upstream. They're not
really paying for the software directly - they're outsourcing the task of
due diligence in checking whether the software is safe enough to allow it
to be installed on their systems. Even the core repos of the community
Linux distros provide a higher level of assurance than the "anything goes,
use at your own risk" style services like PyPI, Ubuntu PPAs and Fedora's
COPR.

That doesn't make the latter services bad, it just means they occupy a
niche in the ecosystem that makes using them directly inherently
inadvisable for users with a low tolerance for risk.

Cheers,
Nick.

>
> --
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
DCFA
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140725/ee167c3d/attachment.html>