←back to thread

Switching Pip to Uv in a Dockerized Flask / Django App

(nickjanetakis.com)
264 points tosh | 4 comments | 24 Jun 25 09:46 UTC | HN request time: 0s | source
Show context
bsenftner ◴[24 Jun 25 10:58 UTC] No.44364791[source]▶
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.

replies(2): >>44364830 #>>44365134 #
Bengalilol ◴[24 Jun 25 11:05 UTC] No.44364830[source]▶
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/

replies(1): >>44365004 #
glaucon ◴[24 Jun 25 11:30 UTC] No.44365004[source]▶
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.

replies(3): >>44365031 #>>44365092 #>>44365169 #
1. alexchamberlain ◴[24 Jun 25 11:34 UTC] No.44365031[source]▶
For a source package based on setup tools, setup.py is executed with a minimal environment and can run arbitrary code.
replies(1): >>44365073 #
2. ericvsmith ◴[24 Jun 25 11:41 UTC] No.44365073[source]▶
You can (and should!) tell pip not to do this with '--only-binary=:all:'. Building from source is a lousy default.
replies(1): >>44365721 #
3. soulofmischief ◴[24 Jun 25 12:58 UTC] No.44365721[source]▶
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.

replies(1): >>44369880 #
4. ericvsmith ◴[24 Jun 25 19:17 UTC] No.44369880{3}[source]▶
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.