[ajross]

All of that is true. But when I pull a package on Ubuntu or Fedora, it's checked against a key that came with the the system at install time as part of the whole package authentication infrastructure. The root of trust is rather stronger than running the output of some random unencrypted HTTP URL. And the distros recognize that and publish hash values for their install media in lots of obvious places.

This is just a bad habit from the OS X world that needs to die. Really there should be some part of the step that allows a typical user to at least try to manually authenticate the root of trust, via a published hash on a bootstrap package maybe (that's what third party RPM/deb archives do, for example).

[leo_santagada]

it is a https url, the same you use to move funds in your bank... If they provided a rpm/deb package it either would not be signed or you would have to download the public key and the package over https.

In the end is the same level of security, this one at least you can first download the script, read it and then pipe it to bash much more easily than a rpm/deb.

[ajross]

TLS encrypts the transfer. It... sort of authenticates the site (modulo multiple holes that exist in that scheme).

But that just pushes the problem on the user: now the user needs to know affirmatively that "rust-lang.org" is the correct source. And they need to know the same thing about every piece of software they install using this insanity.

That's a rather different situation than simply trusting the install-time keys shipped on your system, which you can authenticate manually (via a public key check against a well-published, historically attestable key) with comparative simplicity.

[d0mine]

"the install-time keys shipped on your system" -- given Rust's rapid pace of development, I highly doubt that default packages that are provided e.g., by Debian would be relevant.

To get a reasonably fresh version, you would need to use something like Ubuntu's ppa where you need to trust the ppa's author and TLS, to get you signed packages and the corresponding keys.

"keys + signed package" via TLS from a known (via google) site is more secure than "human readable sh script" via TLS but it is not by leaps and bounds.

[pnathan]

Oy vey! No! It's not! HTTPS as commonly implemented is well known to be much more compromisable than the approach of using an actual signed system. In particular, the CA system is.... not good (lots of discussion about this exists).

Having the Debian approach is far better here!

[chc]

I don't see how comparing an install script you get from somebody with a hash you get from that same somebody gains you an appreciable amount of security. If their server is compromised, you can't trust the hash either. Basically, what you need is a source of trust external to the transaction. If that isn't available and you aren't going to manually review everything, I don't see how this is meaningfully different.

[ajross]

It doesn't give you "perfect" authentication (because nothing does, that's the why the whole root of trust issue is so difficult), but to argue that it isn't appreciably different than literally running the output of curl is just silly.

If I don't trust the hash value I got from the Fedora web site I can ask Google. I can check it vs. the mirrors. I can ask my friend who installed it already to see if it matches her file. I can check the signature on the hash to make sure it matches the key I have stored from my existing install (or the one before that, etc...). That's not perfect but at least it's something.

[chc]

Yes, but I'm talking about the case where you do trust the hash value just like people who use this method trust rust-lang.org. If you don't trust this software, you could download it and get a hash from somebody you trust as well — in neither case are you forced to do it the easier and less secure way. Obviously a quick install process where you trust the source will be less secure than a laborious process where you carefully inspect the code or obtain and verify multiple hashes via sneakernet. But I'm not convinced that the "secure" easy path where you get a file from somebody and a hash/key from the same source, see that the two match and then run the file is actually more secure in any meaningful way than piping curl into sh. The difference seems to be more in the user's level of caution — this method just lays what you're doing bare rather than burying it under layers of indirection.

[ajross]

But... you can't get a hash from somebody you trust with this scheme. The script downloads and runs and throws itself away with no attempt made to authenticate anything (well, I guess there's the TLS cert as it's a https url -- that's something at least).

Or if it's there somewhere I don't see it. Where it it?

[chc]

The point is that if you're paranoid, you won't pipe curl into sh just like you won't blindly trust an unauthenticated hash. There is nothing stopping you from putting more effort into installing this software just like there's nothing stopping you from putting more effort into installing an apt package of questionable provenance.

[leo_santagada]

you can also read the bash script before running it... and it is infinitely more secure than just trusting a hash as your friend and the mirrors can be compromised without you being able to notice (and it has happen before).

[ajross]

Er, huh? You're mixing two arguments here. You're talking about the difficulty of authenticating the root of trust (very hard) and trying to use it to address the issue of installing authenticated software (a long-solved problem).

I'm aware of no situations where linux distro mirrors have been compromised with code that will install on live systems. Again, the key is set up on the clients at install time, you can't drop compromised software on them via package install without stealing the signing keys.

The whole point here is that the "run the shell script off hte web" skips the whole root-of-trust issue, and suffers for it. It must stop, guys.