On 25 Jul 2014 02:05, "Donald Stufft" <don...@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@python.org > https://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
