Hacker News Reader

Comment by atrettel | Hacker News Reader

The issue does not have to do with whether the download is a binary or source code. It has to deal with verifying the integrity of the download before installation.

Curl piped into a shell command provides no means to verify that the download is uncorrupted and unmodified before running it. For example, whenever I download software manually I check the downloaded file against the verified checksums to ensure that I have an unmodified version. Ideally I check this with gpg --verify on the signed checksum file (against the source's public key). This is a standard procedure for many organizations [1]. If you just download something and immediately run it without this step, you could potentially run a hacked version of the installation script.

[1] https://www.debian.org/CD/verify

View on HN

Doesn't curl still validate ssl certificates? So long as I'm curling an https url from a trusted domain, don't I still have a chain of trust?

Curl does verify certificates [1]. That does confirm that your connection is to the right server, but it does not confirm that the files were unmodified.

SSL/TLS/HTTPS is more about encrypting the traffic and ensuring that there was no tampering with the file between you and the server. The steps that I describe are more about ensuring that there was no tampering between you and the original source. Those are two separate problems. If you just rely on HTTPS, somebody can replace the file on the server with a modified version, and you would not know.

[1] https://curl.se/docs/sslcerts.html

But where do you get the checksum from? I realize in some cases you are downloading from a mirror (thus as long as you trust the source of the checksum, that is quite useful) - but if it is from the same host - then you are just comparing against the same webserver.

You raise a good point. This is why people sign the checksums. The signature confirms that authenticity of the checksums. That somewhat moves the goalpost, though, since it then depends on where you got the source's public key, but it is still a more secure practice overall. The advantage of having the public key is that you only need to get it once and you can check many downloads later.

It is also possible to have a signed file that you can use to check the authenticity of a downloaded file directly without having to use checksums. Rust [1] does it that way for its other installation methods.

[1] https://forge.rust-lang.org/infra/other-installation-methods...

For a Debian image, yeah, that is the threat.

But this is new software from someone no one trusts yet. Verifying the binary was not maliciously replaced by someone else doesn’t matter.

What we need here is a reproducible build made and published by an independent third-party.

Reply on news.ycombinator.com