echo -e -n "https://іnstall.example-clі.dev" | python -c 'exec("""import sys, unicodedata\nfor ch in sys.stdin.read():\n try:\n print (ch, " ", unicodedata.name(ch))\n except ValueError:\n print ("codepoint ", ord(ch))\n""")'
After seeing how much stuff was pulled when I once installed a couple programs with cargo, I added it to the "don't touch a project if it's made with this language" pile, alongside NIM and Python (though Python I can't quite avoid).
I don't really see the big deal--for as long as I've been using Linux, which is over 20 years now, installing many packages requires pulling in dozens of other packages, themselves perhaps composed of multiple libraries... The problem is they come from cargo and not a distro? I get the problem with the language repos being more prone to supply chain attack than distro repos, but i don't really get the impression it was ever normal to build complete apps without dependencies.
I think making IDN work the way it does was a mistake. I thought of making IDN with a character set specific for that use (I did think about how it would work) instead of using Unicode or any other existing character sets (none of them are suitable, as far as I am concerned; however, this new IDN character set would potentially be suitable for some other uses such as perhaps package names). Using one character set for everything is not very good, and Unicode is especially bad for this. (Although in my opinion, TRON code is generally better than Unicode, neither TRON code nor Unicode is the one to use for this)
However, there are other problems with paste in the terminal window, but bracketed paste mode can mitigate some of these problems in some cases, it is not entirely helpful.
Of course, more secure installation methods should be preferred, but those are not always available. I am simply comparing the provided solution to homograph attacks with another solution to the same problem.
Then again, I don't blindly pipe directly from the network into the shell either.
Brew is installed by copying a command line-
I mean, I guess you could retype it, but there is no intention for anyone to do that.
But it was held as something exceptional, when here in reality a number of extremely widely used products, frameworks and tools provide installation through a curled shell script command.
Another example is CUDA on Linux. Installed via some copy/pasted scripts from a webpage.
I fully agree, this seems to be becoming more and more common unfortunately.
As a child in the 1980s we'd go for long walks in the woods. One time a friend brought a pair of 30 inch bolt cutters with him, you know, as a personality extension. And of course, there was some dubious reason to use them, and he was a hero for being over-provisioned.
A solution like this is those bolt cutters - I can admire it, but the odds I'm out on a walk with it, is very, very low.
Now if you work in a bolt factory, sure, this can run on every laptop, every user account, every environment.
But I'd hope my edge firewalls are L7 scanning for cyrillic 'i' in my domains cause otherwise I'm just gonna connect and get myself hacked.
I'm personally a bit wary of introducing a relatively obscure security tool into my setup, to protect against a rare possible attack. The chance that I'll get caught copy-pasting a compromised URL into my terminal is fairly small, and there's also a small chance I'll compromise my system either now or at some later point via a supply chain attack if I use the tool. Which chance is bigger?
This is, for me, a "set and forget" kind of tool -- why would i need to update a script?
a pre exec handler for your shell gives somebody a lot of power. if this gets sufficiently popular, pwning this brew package can get one faar...
This is not and has never been safe.
It's just the plausible blame that shifts.
If you read the script before you pipe it into your shell, it's safe.
And if that's not safe, then it's just as dangerous to trust that an unopened bottle of ketchup is safe.
Nothing is safe. Everything is a judgement. Being culpable is a professional service. Lucky people out-earn unlucky people. The world is a scary place.
A lot of safety is down to accountability. A distribution through an attributable marketplace or being verifiably signed.
Safety isn't a performative action, so reading a script may still confuse you or you may miss subtleties. But opting for a safer install mechanism makes a huge difference, which is we always ought to prefer apt, dnf, over the likes of curlbash, brew, npm.
Safety is about managing risk. One element of managing risk is evaluating trust. I'm thinking that there are much fewer people I have to trust by copying the curl | bash install method from homebrew's secure website.
But at any rate, I completely agree that piping a curl'd script directly to the shell should be considered unsafe, even if it's from a trusted source. It's quite easy to do additional checks to reduce your risk significantly for this type of attack. You could read the contents of your clipboard with a hex editor and check for non-ascii characters. But wait? How do I install the hex editor? Don't I need a hex editor to check the install method of the hex editor? AAAAH! It's turtles all the way down!!!!
I guess yeah, you are right, distro repos are safest, but there's lots of times where they aren't sufficient.
This isn't strictly true. It's possible to detect on the server side if curl is being piped and deliver different content: https://web.archive.org/web/20241224173203/https://www.idont...
If you download it first before executing it (instead of downloading it a second time when executing it), then that mitigates one problem, but still not all of them (like you mention). Other mitigations are also possible, such as hashing, certificate pinning, sandboxing, etc.
But IMHO, your "unopened bottle of ketchup" analogy doesn't work. These days, the likelihood of someone trying to trick you into running arbitrary code disguised as an install script is so much higher than the chance that someone working at the ketchup bottling plant is deliberately contaminating bottles before they go out.
Absolutely incorrect. You can do far easier due dilligence for IDE plugins
If you're using stable/LTS branch, there were far more eyes on it too
And packages are signed, can't just hijack web domain to inject code
https://mamba.readthedocs.io/en/latest/installation/micromam...