Note: If any of these install scripts have changed these commands will error because the checksum will be invalid.

[jakwings]

There are existing methods to avoid this hassle, for example, to have the server provide both script.sh and script.sh.asc (ex. gpg --verify script.asc) or checksums.txt (ex. sha256sum --check checksums.txt).

Package managers (with mirror-able index database) have similar functionality built-in.

[gavinuhma]

That's a good point. I've been trying to think if there is a way to have the server provide the checksum. Using --check makes sense for that. I suppose one issue is that these install scripts are meant to be pretty static, so relying on the hardcoded non-server-provided checksum has value. The server can produce a valid checksum for a malicious script for example

[jakwings]

suppose one issue is that these install scripts are meant to be pretty static

also not common enough to prefer a package manager?

relying on the hardcoded non-server-provided checksum

Then you are introducing another trust chain, but where could one get those checksums? If you provide a central repo for them, checksum.sh will evolve into a package manager.

The server can produce a valid checksum for a malicious script for example

That's where (PGP) secret & public key pair shines. They can also sign the checksum_list.txt in order to save the expensive computation on the key pair.

---

BTW I prefer aria2c when it is not asymmetric key-based signiture/checksum:

aria2c --checksum md5=....... --out "$TMPFILE" "$URL"
aria2c --checksum sha-1=..... --out "$TMPFILE" "$URL"
aria2c --checksum sha-256=... --out "$TMPFILE" "$URL"

I also have a gpg_download function to download the file and its signature *.{asc,sig} and do the check. (I have saved and trust the developer's PGP public key beforehand for long term use.)

# Filenames of files downloaded from $URL and $URL.{asc,sig} must match.
gpg_download() {
    local URL="$1"
    curl -LO "$URL" && gpg --verify <(
        if curl -LOI --silent "$URL.asc" >/dev/null 2>&1; then
            curl -L "$URL.asc"
        else
            curl -L "$URL.sig"
        fi
    )
}

[jakwings]

if there is a way to have the server provide the checksum

The server can be configured to include the checksum in a http response header like X-Checksum-SHA256: ...... (for the complete file or chunks from ranged downloads?) but I guess most static file servers won't do ;-) I think simple checksums are mostly useful for downloading from mirror sites.

[gavinuhma]

also not common enough to prefer a package manager?

The pattern I see commonly which inspired this is from tools like Rust, Deno, and Nix that all use some form of curl URL | sh as their main installation instructions. I think it's a popular pattern because it doesn't involve dependencies like package managers and it works pretty well cross platform (assuming you have curl and a shell).

It would be better if everyone was signing their build scripts (and binaries).

Maybe checksum.sh could host and sign build scripts. So like checksum.sh/rust.sh which could also contain checksum.sh/rust.asc.

I was also thinking a tamperproof, append-only ledger would be interesting. So if the install scripts did change and become malicious it would at least be transparent and detectible.

I think the important thing is to keep the client requirements to a minimum, so if the server can do something fancy, and the client just needs to curl and hash or verify.

[jakwings]

Yeah, I agree.

I was also thinking a tamperproof, append-only ledger would be interesting. So if the install scripts did change and become malicious it would at least be transparent and detectible.

If this is not community driven and just a personal stuff, I'd rather

a. simply write two lines of shell code to download the file then check a hardcoded checksum or check using gpg(1)/signify(1)/age(1)/etc.

b. or keep various checksums in https://example.secure/checksums?product=NAME&version=VERSION so that all clients will fetch the checksums from it.

can't be any more complex as using a package manager.

[gavinuhma]

can't be any more complex as using a package manager.

@vyings This is the key thing!