undefined

points

[-]

Because it normalizes a practice that, while acceptable in context of a well known project with numerous dedicated eyeballs such as Rust language, is not a generally acceptable method of installing software.

by 2 hours ago|

parent|

[-]

deleted

by EGreg5 hours ago|

parent|

prev|

[-]

Exactly this.

The correct way is to have M of N signatures on specific package manager pinned versions. And you trust the auditors to look at each new version, of a well-known package.

We should start a project and get it funded, to do just that. The money can go to LLM tokens for audits, at least, and hosting the multisigs and the package managers.

Anyone want to partner on this? See my profile on HN and email me.

by atrettel4 hours ago|

prev|

[-]

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

by NAR87894 hours ago|

parent|

[-]

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?

by atrettel4 hours ago|

parent|

[-]

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

by nazcan2 hours ago|

parent|

[-]

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.

by atrettel1 hours ago|

parent|

[-]

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...

by drdexebtjl4 hours ago|

parent|

prev|

[-]

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.