News for hackers. Stuff that matters.
Re:Uv is the best thing to happen to the Python ecosystem in... by d4mi3n on Wednesday October 29, 2025 @03:30PM (#45751836)
If I were to put on my security hat, things like this give me shivers. It's one thing if you control the script and specified the dependencies. For any other use-case, you're trusting the script author to not install python dependencies that could be hiding all manner of defects or malicious intent.

This isn't a knock against UV, but more a criticism of dynamic dependency resolution. I'd feel much better about this if UV had a way to whitelist specific dependencies/dependency versions.

Re:Uv is the best thing to happen to the Python ecosystem in... by chatmasta on Wednesday October 29, 2025 @03:38PM (#45751972)
If you’re executing a script from an untrusted source, you should be examining it anyway. If it fails to execute because you haven’t installed the correct dependencies, that’s an inconvenience, not a lucky security benefit. You can write a reverse shell in Python with no dependencies and just a few lines of code.
Re:Uv is the best thing to happen to the Python ecosystem in... by 1oooqooq on Wednesday October 29, 2025 @06:58PM (#45754200)
it's a stretch to "executing a script with a build user" or "from a validated distro immutable package" to "allowing something to download evergreen code and install files everywhere on the system".
Re:Uv is the best thing to happen to the Python ecosystem in... by teruakohatu on Wednesday October 29, 2025 @07:35PM (#45754534)
A vanilla python can write files, edit ~/.zsh to create an sudo alias that executes code next time you invoke sudo and type in your password.

uv installing deps is hardly more risky.

Re:Uv is the best thing to happen to the Python ecosystem in... by jrnng on Wednesday October 29, 2025 @08:17PM (#45754849)
That's sneaky. Do any code scanners check for that class of vulnerability?

Scanning for external dependencies is common but not so much internal private libraries.

Re:Uv is the best thing to happen to the Python ecosystem in... by emmelaich on Wednesday October 29, 2025 @09:33PM (#45755431)
https://linuxsecurity.expert/compare/tools/linux-auditing-to... shows a few.

I've used Tiger/Saint/Satan/COPS in the distant past. But I think they're somewhat obsoleted by modern packaging and security like apparmor and selinux, not to mention docker and similar isolators.

Re:Uv is the best thing to happen to the Python ecosystem in... by saagarjha on Thursday October 30, 2025 @04:54AM (#45757766)
Code scanners cannot protect you from code execution on your machine.
Re:Uv is the best thing to happen to the Python ecosystem in... by 1oooqooq on Wednesday October 29, 2025 @08:10PM (#45754795)
point is that a script executes the script in front of you.

uv executes http://somemirror.com/some-version

most people like their distro to vet these things. uv et all had a reason when Python2 and 3 were a mess. i think that time is way behind us. pip is mostly to install libraries, and even that is mostly already done by the distros.

Re:Uv is the best thing to happen to the Python ecosystem in... by maccard on Wednesday October 29, 2025 @03:49PM (#45752113)
If that’s your concern you should be auditing the script and the dependencies anyway, whether they’re in a lock file or in the script. It’s just as easy to put malicious stuff in a requirements.txt
Re:Uv is the best thing to happen to the Python ecosystem in... by p_l on Wednesday October 29, 2025 @03:54PM (#45752182)
uv can still be redirected to private PyPi mirror, which should be mandatory from security and reliability perspective anyway.
Re:Uv is the best thing to happen to the Python ecosystem in... by theamk on Wednesday October 29, 2025 @04:25PM (#45752575)
Is there anything new that uv gives you here though?

If you don't care about being ecosystem-compliant (and I am sure malware does not), it's only a few lines of Python to download the code and eval it.

Re:Uv is the best thing to happen to the Python ecosystem in... by skinner927 on Wednesday October 29, 2025 @06:14PM (#45753788)
You’re about to run an untrusted python script. The script can do whatever it wants to your system. Dependencies are the least of your worries.
Re:Uv is the best thing to happen to the Python ecosystem in... by schrodinger on Thursday October 30, 2025 @01:07AM (#45756628)
The script is just a cat or vim away from audit. Its dependencies on the other hand…
Re:Uv is the best thing to happen to the Python ecosystem in... by Hikikomori on Thursday October 30, 2025 @04:49AM (#45757738)
A download and a cat away?
Re:Uv is the best thing to happen to the Python ecosystem in... by schrodinger on Thursday October 30, 2025 @08:30AM (#45759283)
Sorry I was half asleep! Meant that you can easily look at the code in the script and audit what it does – you can just run `cat` in it and you’re done!

But it’s much harder to inspect what the imports are going to do and be sure they’re free of any unsavory behavior.

Re:Uv is the best thing to happen to the Python ecosystem in... by schrodinger on Thursday October 30, 2025 @08:32AM (#45759303)
This was very confusing!

I meant it’s easy to inspect your script’s logic — look it. Bunch harder to audit the code in dependencies though…

Re:Uv is the best thing to happen to the Python ecosystem in... by gcr on Wednesday October 29, 2025 @06:14PM (#45753790)
Would you feel better with a script containing eval(requests.get(“http://pypi.org/foo.py”)) ?

It’s the script contents that count, not just dependencies.

Deno-style dependency version pinning doesn’t solve this problem unless you check every hash.

Re:Uv is the best thing to happen to the Python ecosystem in... by golem14 on Wednesday October 29, 2025 @08:03PM (#45754746)
""" uv is straightforward to install. There are a few ways, but the easiest (in my opinion) is this one-liner command — for Linux and Mac, it’s:

curl -LsSf https://astral.sh/uv/install.sh | sh """

Also isn't great. But that's how homebrew is installed, so ... shrug ... ?

Not to bash uv/homebrew, they are better than most _easy_ alternatives.

Re:Uv is the best thing to happen to the Python ecosystem in... by ShroudedNight on Wednesday October 29, 2025 @11:06PM (#45756007)
I hate that curl $SOMETHING | sh has become normalized. One does not _have_ to blindly pipe something to a shell. It's quite possible to pull the script in a manner that allows examination. That Homebrew also endorses this behaviour doesn't make it any less of a risky abdication of administrative agency.

But then I'm a weirdo that takes personal offense at tools hijacking my rc / PATH, and keep things like homebrew at arm's length, explicitly calling shellenv when I need to use it.

Re:Uv is the best thing to happen to the Python ecosystem in... by caymanjim on Thursday October 30, 2025 @01:28AM (#45756706)
There's a completely irrational knee-jerk reaction to curl|sh. Do you trust the source or not? People who gripe about this will think nothing of downloading a tarball and running "make install", or downloading an executable and installing it in /usr/local/bin.

I will happily copy-paste this from any source I trust, for the same reason I'll happily install their software any other way.

Re:Uv is the best thing to happen to the Python ecosystem in... by golem14 on Thursday October 30, 2025 @06:06PM (#45765955)
It really depends on the use case. A one-off install on a laptop that I don't use for anything that gets close to production - fine by me.

For anything that I want to depend on, I prefer stronger auditability to ease of install. I get it, theoretically you can do the exact same thing with curl/sh as with git download/inspecting dependencies, installing the source and so on. But in reality, I'm lazy (and per another thread, a 70s hippie) and would like to nix any temptation to cut corners in the bud.

Re:Uv is the best thing to happen to the Python ecosystem in... by rpier001 on Thursday October 30, 2025 @01:06AM (#45756624)
I didn't see it in the comments, but FWIW you can choose specific dependencies. You can use regular [dependency specifiers](https://packaging.python.org/en/latest/specifications/depend...), see [PEP 723](https://packaging.python.org/en/latest/specifications/inline...).