IMHO, this is one of the critical parts of an install script that I see missing constantly. Homebrew doesn’t by default do any signature checks on what it’s downloading. Docker’s install used to be a curl | sh as well.

I first thought about this when seeing people’s (especially Golang) NixOS files which included a statement like the following:

src = fetchgit {
  url = "git://github.com/NixOS/nix.git";
  rev = "1f795f9f44607cc5bec70d1300150bfefcef2aae";
  sha256 = "1cw5fszffl5pkpa6s6wjnkiv6lm5k618s32sp60kvmvpy7a2v9kg";
}

I may be wrong here and there may be signature checks under the hood, but I feel like building this mechanism into the curl | bash would be a huge bonus. I wish more programs (and especially homebrew) did this, but would like to hear if there’s a solid reason why not (there probably is).

IMHO: curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh?version=X.X.X | inline-md5sum MD5SUM | sh -" would be a much more robust curl to bash as it would include the current version (fully reproducible curl | bash-es) as well as a quick signature check. Heck, you could even have the signatures posted elsewhere or tied to PGP/AGE.

This is good, but it, IMO, should be SHA256 or Blake2 instead, which are considered cryptographically strong unlike MD5.

Just remember… if the script and the known-correct value for the hash are being obtained from the same site, this is unlikely to be protective. If someone is maliciously replacing the script, surely they will also replace the checksum sitting next to it.

This will probably flag plenty of errors where someone updates their script but not their checksum, though. Which is generally a good thing too, unless it teaches people to ignore the errors.

I wrote a similar tool to sign/check files in a pipeline: sick.

It requires a public key to verify the signature though, but works in a similar way:

curl $URL | sick | sh

The only caveat is that it puts the whole file into memory for now (though bufferizing it on disk would be easy to do). If the ed25519 signature shipped with the file doesn’t match, then nothing is printed to stdout. If it matches, the content (without the signature) is ouputed to stdout.

Maybe just curl from ipfs.

As long as the key is the correct, you’ll always get the same data. About as good as a download link next to a hash.

Anything that gets the computer checking the checksum for you is a step up in my book! Relatedly, I did a roundup a couple of years ago of minimal techniques for verifying checksums without having to eyeball them manually. If anyone knows any better ones I’d love to hear them.

i believe a similar result can be achieved using plain shell scripting. this is single bash pipeline, so it’s also usable in a single RUN stanza in a Dockerfile, without creating intermediate layers:

set -euo pipefail \
    && curl -fsSL https://... > file-contents \
    && expected_hash=... \
    && echo "$expected_hash  file-contents" | sha1sum --check --quiet - \
    && (cat file-contents; rm -f file-contents) | wc -l

it works like this:

• the set line is for ‘safer bash’ (search the web for details) and is a good default in general.
• store curl output in a file, aptly named file-contents
• call sha1sum to check the file; pipeline aborts if there’s a mismatch
• pipe the file contents into a program of choice, and cleanup (data and hash) afterwards.

some more remarks:

• short code to avoid 3rd party scripts, their downloads, version control for local copies, etc.,
• the subshell trick is the lazy person’s version to a cleanup using mktemp, trap etc
• the files are removed in the happy case only; leftover file may be helpful for debugging
• sha1sum prints an error message like sha1sum: WARNING: 1 computed checksum did NOT match (use --status to suppress, but it’s generally good to see why things fail)

It looks like a security theater. You trust the source if you downloading it. Make sure it’s httpS. That’s it. This md5 hash checking creates false sense of security.