3 ms·

> Avoids arbitrary code execution for installation. (Avoids setup.py) This isn't much of an advantage as you're trusting code compiled on an untrusted machine.

> Avoids arbitrary code execution for installation. (Avoids setup.py) This isn't much of an advantage as you're trusting code compiled on an untrusted machine. I suppose it saves you some CPU cycles, but don't be fooled into thinking it's safer.

geofft 11y ago
There's a somewhat compelling use case for `pip install foo` not trusting the packages, but the actual Python code that runs "import foo" trusting it. In particular, if I'm a sysadmin of a shared machine and a user asks me to install something systemwide, I don't want arbitrary code running as root, but if the installed code is malicious, that's up to the unprivileged user who chooses to use it to keep their own data safe. It's not terribly compelling given stuff like virtualenv, though, since users can just `pip install` stuff on their own and the experience is strictly nicer. And it's also not compelling if there isn't an explicit promise that this is treated as a security boundary.
- schmichael 11y ago
  > In particular, if I'm a sysadmin of a shared machine and a user asks me to install something systemwide, I don't want arbitrary code running as root, but if the installed code is malicious, that's up to the unprivileged user who chooses to use it to keep their own data safe. Ah, that makes a lot of sense, especially for applications (eg meld) and command line utilities (eg httpie) which are nice to install systemwide as root, but only ever run in an unprivileged user's context.
rogerbinns 11y ago
It is also a problem for packages that do use setup.py. My apsw extension has several options including fetching some other prequisites, and choosing which extensions to include, but you can't give options to pip to pass along. http://rogerbinns.github.io/apsw/build.html#setup-py http://rogerbinns.github.io/apsw/build.html#setup-py
rtpg 11y ago
Assuming you trust the package source already, I think the advantage lies more in not having the setup process accidentally erase your home directory for whatever reason.

geofft 11y ago

There's a somewhat compelling use case for `pip install foo` not trusting the packages, but the actual Python code that runs "import foo" trusting it. In particular, if I'm a sysadmin of a shared machine and a user asks me to install something systemwide, I don't want arbitrary code running as root, but if the installed code is malicious, that's up to the unprivileged user who chooses to use it to keep their own data safe. It's not terribly compelling given stuff like virtualenv, though, since users can just `pip install` stuff on their own and the experience is strictly nicer. And it's also not compelling if there isn't an explicit promise that this is treated as a security boundary.

schmichael 11y ago
> In particular, if I'm a sysadmin of a shared machine and a user asks me to install something systemwide, I don't want arbitrary code running as root, but if the installed code is malicious, that's up to the unprivileged user who chooses to use it to keep their own data safe. Ah, that makes a lot of sense, especially for applications (eg meld) and command line utilities (eg httpie) which are nice to install systemwide as root, but only ever run in an unprivileged user's context.

rogerbinns 11y ago

It is also a problem for packages that do use setup.py. My apsw extension has several options including fetching some other prequisites, and choosing which extensions to include, but you can't give options to pip to pass along. http://rogerbinns.github.io/apsw/build.html#setup-py http://rogerbinns.github.io/apsw/build.html#setup-py

rtpg 11y ago

Assuming you trust the package source already, I think the advantage lies more in not having the setup process accidentally erase your home directory for whatever reason.