Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think this is a worthy cause, but maybe a little misguided: the problem with "curl-piping" isn't so much the fact that you're throwing a random shell script into your shell, but the fact that you're downloading arbitrary code in a way that's disconnected from the normal integrity/authenticity guarantees of a package manager.

In other words: you can be confident in the bootstrapping script you've just downloaded because it passed its checksum, but that script is just going to download more binaries from the Internet.



> the fact that you're downloading arbitrary code in a way that's disconnected from the normal integrity/authenticity guarantees of a package manager.

I'm old enough to remember when apt packaging got burned because it used http instead of https even though apt packages get signed.

If you're downloading software from websites protected with HTTPS, and that's good enough for you, then downloading and executing a script from those same websites using HTTPS is also good enough.

Would it be better if those things were signed with a key for which there is a code signing certificate? Eh, maybe, yes, if the PKI for the code signing is sufficiently better than WebPKI, which... is not necessarily obvious. Meanwhile, access to that PKI is probably sufficiently harder to come by than WebPKI TLS server certificates that a lot of people don't bother, and rightly so.

Now suppose you say "I don't trust this, I'm just going to clone their github repo and build from source". Do you get more protection that way? Maybe, maybe not.

Now, if you get packages from Debian and the like, you get them signed, and maybe the person who contributed the package to their repository did a thorough code review and audit of the upstream they are packaging, or maybe not, who knows.

This is why containerizing this stuff helps. But it's not really accessible to people yet.

What might be nice is that any program that a user executes automatically gets some level of isolation corresponding to how it was delivered, authored by whom, etc. So programs from the OS get the least isolation, and programs written by the user less isolation, and programs of unknown provenance get the most isolation.


> that script is just going to download more binaries from the Internet

Not necessarily. A number of these scripts either configure a package manager or the shell script contains the binary itself which is unpacked when the script is run.


Sure, I suppose that's possible. Most of the ones I'm familiar with just download an architecture-compatible binary from a CDN somewhere.

Even if there's a shar-style[1] packed binary in the script, you have no idea what that binary does when you verify that the checksum is correct.


Well-written scripts I've seen also contain the hash of binaries that are downloaded. So as long as the hash function is good, checking the hash of the script should still ensure that the binary downloaded is what you want.

> you have no idea what that binary does when you verify that the checksum is correct.

This isn't any different from using a package manager. You're still downloading a binary that could do anything and you have to have some level of trust in the source.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: