`ubi` should verify checksums by default

[autarch]

If a release has an accompanying checksum file, it'd be nice if ubi downloaded the checksums and validated them.

This will require looking at a whole bunch of projects to see what naming scheme they use for these checksums and what the files look like. At least I know how this works for my own actions-rust-release-based projects.

Some examples:

ubi

Publishes foo.tar.gz and foo.tar.gz.sha256 files.

https://gitlab.com/gitlab-org/cli/-/releases

Publishes a single checksums.txt file with all the checksums for the release.

https://github.com/golangci/golangci-lint

Publishes a single golangci-lint-1.62.2-checksums.txt file with all the checksums for the release.

https://github.com/chrishrb/go-grip

Publishes foo.tar.gz.md5 files. This files just contain the hash, with no filename.

https://github.com/goreleaser/goreleaser

Publishes foo.sbom.json files which contain a $.files element. This is an array of objects, where each object contains a .checksums object with hashes (SHA1 and SHA256) for the executable file in the release.

There's also a checksums.txt file.

---

If you're reading this, please feel free to add any other examples you know of that follow a pattern not covered in the list above.

[autarch]

I realized that the SBOM files contain checksums for individual files in the released tarball. Making use of this would be a lot more involved than just checksumming the entire archive file, so I'm going to leave this out for now.

[autarch]

I mostly implemented this, but then I wondered if this is really worthwhile. Verifying checksums doesn't really tell us that much. It'd detect the case where a file is corrupted during transfer, but in this case it's likely that either A) it will error when we try to unpack/uncompress it; B) the resulting executable won't run. Also, how often does this sort of corruption happen? I've downloaded many, many, many things over the years and I'm not sure I've ever seen this happen!

A much more useful thing to check would be whether the release matches a cryptographic signature. But AFAICT, most projects don't publish this sort of thing.

Of the projects above, only goreleaser does this. They publish a checksums.txt file along with a checksums.pem file (the cert used to sign), and a checksums.sig file (the signature). This is all done using cosign.

In this case, verifying the checksum along with verifying the signing of the checksums file provides a much stronger guarantee that the contents of the release artifact have not been either corrupted or, more importantly, tampered with.

[autarch]

https://lib.rs/crates/sigstore

[ELLIOTTCABLE]

w.r.t. validating signatures - looks like yamlfmt is also publishing signatures with releases.

[autarch]

Thanks for the pointer to yamlfmt.

There's something weird about the cert they're publishing. I can't get any info from it with openssl:

openssl x509 -in ~/Downloads/checksums.txt.pem -text
Could not read certificate from /home/autarch/Downloads/checksums.txt.pem
Unable to load certificate

[scop]

aqua-registry has info about quite a few projects using cosign. Search for cosign: in https://github.com/aquaproj/aqua-registry/blob/main/registry.yaml

In addition to cosign, SLSA provenance is another type of information that can be used to verify artifacts. See slsa_provenance: in the aqua registry.yaml, and https://github.com/slsa-framework/slsa-verifier

Yet another similar thing is GitHub artifact attestations. No entries in aqua registry.yaml yet, but some are starting to appear soonish: aquaproj/aqua-registry#32597

[Adirelle]

There's something weird about the cert they're publishing. I can't get any info from it with openssl:

openssl x509 -in ~/Downloads/checksums.txt.pem -text
Could not read certificate from /home/autarch/Downloads/checksums.txt.pem
Unable to load certificate

For some reason, this file is a base64-encoded version of the certificate:

base64 -d checksums.txt.pem | openssl x509 -noout -text

[scop]

For some reason, this file is a base64-encoded version of the certificate

This is a known cosign issue, it redundantly base64 encodes pem files by default without indicating having done that in the filename: sigstore/cosign#2666 (comment)

[cedws]

I would be interested in being able to verify against a static checksum passed to ubi for pinning. GitHub release assets can be replaced at any time. Without checksum pinning this is a supply chain risk as assets can be stealthily swapped out for malicious ones if an account or organisation becomes compromised.

I'm the author of a project with (setup-everything) that has some overlap with ubi, though my project is more concerned with tool setup in the context of a secure CI workflow. It would be great if I could replace the Python scripts it uses with ubi, but perhaps the features I need are out of scope.

[autarch]

Having ubi accept a checksum and verifying that would be trivial. I'd be open to a PR for it.

[risu729]

On June 6th, GitHub started to generate SHA256 checksums for release assets.
We might be able to use them to verify assets.
https://github.blog/changelog/2025-06-03-releases-now-expose-digests-for-release-assets/

I opened a discussion in mise. jdx/mise#5464

[cedws]

On June 6th, GitHub started to generate SHA256 checksums for release assets.

It's disappointing that only newly uploaded release assets have digests, so there'll still be a need to calculate hashes by downloading assets for years to come.

[autarch]

I think the auto-generated checksums have the same issue as I noted in an earlier comment, which is that checking them doesn't achieve much. There's nothing to prevent a bad actor from replacing release assets if they compromise a repo. Presumably, GitHub will generate new checksums when that happens.

Yes, as noted, if you record the checksum locally for a given asset, then checking it has some value, but this is a huge pain and almost nobody will do this.

I think schemes which involve some sort of actual signature by the author are more valuable.