[Distutils] Entry points: specifying and caching

[Thomas Kluyver]

On Sat, Oct 21, 2017, at 07:59 AM, Nick Coghlan wrote:
> Yeah, here's the gist of what I had in mind regarding the malware
> problem (i.e. aiming to ensure we don't get all of setup.py's problems
> back again):> 
> - a package's own install hooks do *not* get called for that package
> - hooks only run by default inside a virtualenv as a regular user
> - outside a virtualenv, the default is "hooks don't get run at all"

This one would make caching much less useful for me, because I install a
lot of stuff with 'pip install --user'.
I'm not really sure how useful this protection is. A malicious
package can shadow common module names and command names, so once
it's installed, it has an excellent chance of getting to run code,
even without hooks. And virtualenvs are not a security boundary -
malware installed in a virtualenv is just as bad as malware installed
with --user.
Moving away from running 'setup.py' to install stuff protects us against
packages doing silly things like running pip in a subprocess, but it
provides very little protection against deliberately malicious packages.
If we're going to do package install hooks, let's not cripple them by
trying to introduce security that doesn't really achieve much.
Nathaniel raises the point that it may be easier to convince other
package managers to regenerate an entry points cache than to call
arbitrary Python hooks on install. I guess the key question here is: how
many other use cases can we see for package install/uninstall hooks, and
how would those work with other packaging systems?
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171026/375b1938/attachment.html>