On: Switching Pip to Uv in a Dockerized Flask / Django App

[glaucon]

I'd be interested to know under what circumstances pip executes arbitrary code while resolving dependencies ... how does that work ?

And while I'm here ... how does uv go about mitigating typosquatting risks ? I could imagine how it might issue warnings if you perhaps it notices you requesting "dlango", which would work OK for the top 10% but are you suggesting there's some more general solution built into uv ?

I did a quick search but 'typosquatting' is not an easy string to cut through.

[db48x → glaucon]

To install a package and its dependencies, you need the list of dependencies. This metadata is not always statically available!

Python packages are often just a zip file full of py files, with one of them called 'setup.py'. Running this file installs the package (originally using [distutils](https://docs.python.org/3.9/install/index.html#install-index)). This installation may fail if dependencies are not present, but there’s no method provided for installing those dependencies. You’re supposed to read the error message, go download the source for the missing dependencies, then run their setup.py scripts to install them.

[badmintonbaseba → db48x]

How does uv get around this?

[db48x → badmintonbaseba]

I don’t know; I’ve only just heard of uv. I know about the packaging problem because I’ve had to deal with that nonsense a few times.

[bckr → badmintonbaseba]

Don’t think it does. You see the import errors when you run your code and you add the requirements to your project.

[nonethewiser → badmintonbaseba]

because instead of running setup.py it directly fetches the specified dependencies

[un_ess → glaucon]

a)"Thanks to backwards compatibility, a package offered only as a source distribution and with the legacy setup.py file for configuration and metadata specification will run the code in setup.py as part of the installation." https://blog.phylum.io/python-package-installation-attacks/

b) pip now has an option _not_ to run arbitrary code by disallowing source distributions, by passing --only-binary :all:

"By default, pip does not perform any checks to protect against remote tampering and involves running arbitrary code from distributions. It is, however, possible to use pip in a manner that changes these behaviours, to provide a more secure installation mechanism." https://pip.pypa.io/en/stable/topics/secure-installs/

[alexchamberlain → glaucon]

For a source package based on setup tools, setup.py is executed with a minimal environment and can run arbitrary code.

[ericvsmith → alexchamberlain]

You can (and should!) tell pip not to do this with '--only-binary=:all:'. Building from source is a lousy default.

[soulofmischief → ericvsmith]

Requiring increasingly long arcane incantations in the name of backwards compatibility is a terrible design philosophy and introduces security fatigue. Most users will not use aliases, and it's poor security posture to ask them to.

Given how often the python community already deals with breaking changes, it shouldn't be much different for pip to adopt saner defaults in a new major version.

[ericvsmith → soulofmischief]

While I agree, pip has very strong backward compatibility requirements. I'm not sure why, maybe because people tend to upgrade it without considering the consequences.