Live data from Hacker News

"So that a truncated partial download doesn't end up executing half a script"

tailscale.com

31–40 of 87 posts

Re: "So that a truncated partial download doesn't end up executing half a script"

#31
post #6

Don't pipe curl/wget a script to a shell without reading what you've downloaded. This should be common sense. Do `wget $url; most install.sh` and only if you're satisfied with what you read , execute `sh install.sh`.

Everyone says this, but nearly nobody does it. Just like security through open source, it's more a nice myth than a reality.

I skim little python or bash scripts when I download them. It depends on the project. (I try not to download much source code because this is a pain to do).

Re: "So that a truncated partial download doesn't end up executing half a script"

#32

If only there was a way to transactionally run shell scripts such that if they don't complete fully, the changes are automatically reverted. Edit: cue the HN responses to use nix, and other solutions

Idempotence isn't guaranteed either

Re: "So that a truncated partial download doesn't end up executing half a script"

#33

Don't pipe curl/wget a script to a shell without reading what you've downloaded. This should be common sense. Do `wget $url; most install.sh` and only if you're satisfied with what you read , execute `sh install.sh`.

While I agree, how does this mesh with standard operating procedure on Windows/Mac being to download binary executables and run them? Is the analogous advice "inspect any exe files with Ghidra and fully understand them before running"? Or "only run executables from official distribution channels of open source projects the code of which you've read and understand"? Where, generally, should we place our trust in terms…

Windows and particularly macOS makes it difficult to run things that aren't code signed with trusted certificates. Same with packages in Linux package managers. That provides a large level of assurance that the thing you download is verified by a distributor that you presumably trust (otherwise why are you using their software?). Pipe to shell has no such guarantee: if a bad actor either MITMs you or gets access to their server and stuffs something bad in the script, you're out of luck.

Basically, if you believe that code signing is a good thing (and I hope we all can agree on that), curl to shell is not great security practice.

Re: "So that a truncated partial download doesn't end up executing half a script"

#34
A serious question for any Linux-heads here, no insult intended.

How is it possible that there are ELEVEN different possible package managers that need to be supported by an installation script like this?

I can understand that some divergences in philosophical or concrete requirements could lead to two, three, or four opinionated varieties, but ELEVEN?

Does that mean that if I want to write an app that runs on Linux I should also be seeking to support 11 package managers? Or is there something unique about tailscale that would necessitate it?

edit: Thank you for the responses so far, but noone has yet answered the core question: WHY are there eleven of them?

Re: "So that a truncated partial download doesn't end up executing half a script"

#35
post #25

Earlier quoted context omitted.

Thats who pushed XZ out as far as it went. Everyone is asleep at the wheel.

A single incident. How many incidents in how many decades have there been?

Ask the bottles team how they feel about maintainers and the job they are doing.

A fair number of upstream developers are unhappy with what maintainers and how they deal with bugs and updates.

The real problem is that software packaging and distribution is so very broken. I had a systems admin say "I love containers, they are a circle of salt around demonically bad software"... He wasnt wrong.

Re: "So that a truncated partial download doesn't end up executing half a script"

#36
post #10

Earlier quoted context omitted.

Didn't the xz situation kinda prove that even reading the script is probably not gonna do you a lot of good if you're up against someone smart?

The xz situation proved the opposite: if you're up against someone smart, you won't read the script (and you'll think you have).

The xz situation proved that while you didn't read the script, someone did detect the problem. It shows the benefit of many-eyes.

Re: "So that a truncated partial download doesn't end up executing half a script"

#39
post #29

I read TFA. Why would a truncated partial download happen and still run the script?

The most obvious answer is `curl | sh`. But also perhaps a network blip interrupting curl/wget, but the user failing to notice and going ahead and executing the file anyway.

Re: "So that a truncated partial download doesn't end up executing half a script"

#40

A serious question for any Linux-heads here, no insult intended. How is it possible that there are ELEVEN different possible package managers that need to be supported by an installation script like this? I can understand that some divergences in philosophical or concrete requirements could lead to two, three, or four opinionated varieties, but ELEVEN? Does that mean that if I want to write an app that runs on Linux…

If you write an app that runs on Linux, you should support flatpak, and (for bonus points) nix.

The rest should be done by the distros' maintainers.

Post reply on HN