[d4mi3n]

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.

[chatmasta]

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.

[1oooqooq]

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

[teruakohatu]

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.

[jrnng]

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.

[emmelaich]

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.

[saagarjha]

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

[1oooqooq]

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.

[skinner927]

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.

[schrodinger]

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

[schrodinger]

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…

[Hikikomori]

A download and a cat away?

[schrodinger]

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.

[maccard]

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

[gcr]

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.

[theamk]

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.

[rpier001]

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

[p_l]

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

[golem14]

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

[caymanjim]

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.

[golem14]

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.

[ShroudedNight]

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.