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