Switching Pip to Uv in a Dockerized Flask / Django App

I'd like to see a security breakdown of uv versus pip versus conda versus whatever fashionable package manager I've not heard of yet.

Speed is okay, but security of a package manager is far more important.

uv is generally more secure than pip. It resolves dependencies without executing arbitrary code, verifies package hashes by default, and avoids common risks like typosquatting and code execution during install. It's also faster and more reproducible.

https://chaitalks.tech/uv-a-modern-python-package-manager-in...

https://docs.astral.sh/uv/pip/compatibility/

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.

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

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

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/

> security breakdown of uv versus pip versus conda versus whatever fashionable package manager

In the end, every package manager (so far at least) download and runs untrusted (unless you've verified it manually) 3rd party code. Whatever the security difference is between uv and pip implementation-wise is dwarfed compared to if you haven't found a way of handling untrusted 3rd party code yet.

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.

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.

How does uv get around this?

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

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

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.

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.