Hacker News Reader

Comment by d4mi3n | Hacker News Reader

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.

View on HN

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.

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".

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.

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.

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.

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.

Code scanners cannot protect you from code execution on your machine.

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.

The script is just a cat or vim away from audit. Its dependencies on the other hand…

A download and a cat away?

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.

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…

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

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.

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.

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...).

uv can still be redirected to private PyPi mirror, which should be mandatory from security and reliability perspective anyway.

""" 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.

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.

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.

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.

Reply on news.ycombinator.com