Repository navigation
Note: If any of these install scripts have changed these commands will error because the checksum will be invalid. #1
Description
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.
Activity
gavinuhma commentedon Oct 28, 2022
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 commentedon Oct 28, 2022
also not common enough to prefer a package manager?
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.
That's where (PGP) secret & public key pair shines. They can also sign the
checksum_list.txtin order to save the expensive computation on the key pair.BTW I prefer aria2c when it is not asymmetric key-based signiture/checksum:
I also have a
gpg_downloadfunction 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.)jakwings commentedon Oct 28, 2022
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 commentedon Oct 29, 2022
The pattern I see commonly which inspired this is from tools like Rust, Deno, and Nix that all use some form of
curl URL | shas 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.shwhich could also containchecksum.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 commentedon Oct 29, 2022
Yeah, I agree.
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 commentedon Oct 31, 2022
@vyings This is the key thing!