Publish checksums with releases

[alexeagle]

@comius points this out in https://github.com/bazelbuild/rules_proto/pull/205/files#r1524512758

Currently users of protobuf can download releases from https://github.com/protocolbuffers/protobuf/releases - however they have no way to guarantee that the bytes they downloaded are the same that were published. A man-in-the-middle attack could tamper with the binary, for example, injecting a supply-chain-security vulnerability into the generated protobuf stub code.

Like many GitHub-released projects, there ought to be a checksums.txt file included as an additional release asset. This could be in the form of a .sha256-suffixed file for each release artifact, like https://github.com/astral-sh/ruff/releases or (more convenient IMO) a single checksums.txt file like https://github.com/google/yamlfmt/releases

[sgammon]

@alexeagle I'm in the build doing some refactoring and fixing (#16176 etc)... did you want to take this on? If not, I'll file it along with some other dependency security enhancements (SLSA, Sigstore, etc), in a stack of PRs so they can merge what they feel comfortable with. I've taken the same approach with Guava.

[alexeagle]

@sgammon that would be great, but I suspect the release machinery here is hidden in google3. It would be good to get a 👍🏻 from the maintainers on an approach for this.

[epicseven-cup]

Hi, I was just about to post this question as well any updates on this?

[esorot]

Thanks for filing this issue. We've added it to our backlog to be prioritized.

[zhangskz]

Wouldn't any attack that could compromise the binaries also be able to just tamper with the checksums as well, if they live side-by-side? I think we would generally recommend setting sha256 (e.g. bazel http_archive) directly to prevent this type of case. LMK if there's something we're failing to consider here!

This is probably still a nice-to-have backlog task, but we're unlikely to get to this atm unless the priority changes.

[alexeagle]

@zhangskz exactly, users should vendor the checksums to follow the principle of trust-on-first-use similar to host keys in a known_hosts file.

[justfalter]

@alexeagle

exactly, users should vendor the checksums to follow the principle of trust-on-first-use similar to host keys in a known_hosts file.

From the linked article:

In the SSH](https://en.wikipedia.org/wiki/Secure_Shell) protocol, most client software (though not all[2]) will, upon connecting to a not-yet-trusted server, display the server's public key fingerprint, and prompt the user to verify they have indeed authenticated it using an authenticated channel.

It is not possible to perform Trust on First Use without having a means for verifying the authenticity of the information.

@zhangskz

Wouldn't any attack that could compromise the binaries also be able to just tamper with the checksums as well, if they live side-by-side? I think we would generally recommend setting sha256 (e.g. bazel http_archive) directly to prevent this type of case. LMK if there's something we're failing to consider here!
This is probably still a nice-to-have backlog task, but we're unlikely to get to this atm unless the priority changes.

This is why most (all?) linux distros cryptographically sign the software they release. The distro comes with a set of trusted GPG keys, and all packages have their signatures verified before installing.

The same is true for many open-source software projects. NodeJS publishes the GPG keys that are used to sign NodeJS releases.

The flow is generally:

• Release-manager publishes their public GPG key.
• Release-manager creates a new release of their software:
  • Has compiled binary example.linux-arm64.gz
  • Calculates sha256 of binary as example.linux-arm64.gz.sha256
  • Using their private GPG key, generates a detached signature of example.linux-arm64.gz.sha256 as example.linux-arm64.gz.sha256.asc.
  • Uploads example.linux-arm64.gz, example-linux-arm64.gz.sha256, and example.linux-arm64.gz.sha256.asc as assets on release.

In order to verify:

• User verifies integrity of example.linux-arm64.gz.sha256 using example.linux-arm64.gz.sha256.asc and the known-publisher GPG key.
• User verifies that sha256 of example.linux-arm64.gz matches value in example.linux-arm64.gz.sha256.

In order for an attacker to tamper, they would need to have compromised both the GPG key for the release-manager, as well as obtain privileged access to wherever the releases are hosted.

[sgammon]

@justfalter This issue deals with checksum publishing for Protobuf releases for some channels where they are not available today. Most distribution channels for Protocol Buffers do provide checksums and signatures. For example, Maven-hosted protobuf.

It is not possible to perform Trust on First Use without having a means for verifying the authenticity of the information

"Trust on first use" implies no requirement for root of trust, and Wikipedia isn't an authoritative source anyway. In Maven's case, publishing authority for a given coordinate group is checked and enforced by Sonatype. Continuing with this example: if you trust your CA PKI to verify Maven Central, and therefore trust the signatures it provides as tamper-proof in transit, and also trust Sonatype to host Central securely and perform their verifications, then there is a root of trust established for Protocol Buffers consumed through Maven.

This issue deals largely with checksums published specifically for Protobuf releases on GitHub. Bazel users need the sha256 of a given dependency to pin it in their WORKSPACE file. However, Bazel is already deprecating the WORKSPACE file, having moved to BCR, which does distribute a checksummed version of Protobuf.

In most cases, Protobuf is "checkable," with a solid root of trust.

[justfalter]

@sgammon

This issue deals largely with checksums published specifically for Protobuf releases on GitHub.

FWIW, I am a bazel user who is very much interested in seeing sha256 checksums published for protobuf releases. When I read zhangskz's mention that binaries and checksums could be tampered with alike, I chose to inform on a common avenue for avoiding that situation.

In my opinion, there's a bit of XY problem going on here - the X seeming to be that protocolbuffers/protobuf provides no means for verifying the integrity of its posted release binaries. This applies to more than just bazel users.

[sgammon]

@justfalter Google itself relies on protobuf and hash-locks protobuf in their own WORKSPACE files; is this not a valid root of trust, in your view? Google technically publishes those, just not here, in the repo. If you don't trust Google's own trust of Protobuf (or by extension, don't trust Google), how can you trust protobuf enough to use in your project in the first place?

What channel besides Bazel uses the source releases directly from the repository? Shouldn't Bazel users simply use BCR if they are concerned about security (again, assuming trust in Google since they run both BCR and the development of protobuf)?

[justfalter]

Google itself relies on protobuf and hash-locks protobuf in their own WORKSPACE files; is this not a valid root of trust, in your view? Google technically publishes those, just not here, in the repo. If you don't trust Google's own trust of Protobuf (or by extension, don't trust Google), how can you trust protobuf enough to use in your project in the first place?

You misunderstand me. This isn't about whether anyone trusts Google. This is about having a means for verifying that the binaries downloaded from https://github.com/protocolbuffers/protobuf/releases are the same ones that were originally uploaded by the release maintainers.

This repository has 178 releases created by at least 22 different Github accounts, and a compromise of one of those could allow an attacker to replace the binaries for any of the existing releases. It's true that the discussed TOFU approach would guard against binaries changing out from underneath them, but that doesn't cover for the total population of protobuf users (see below).

The hashes could be published out-of-band (ex: to https://protobuf.dev/ ?) as a guard against their being modified alongside the binaries.

What channel besides Bazel uses the source releases directly from the repository?

• The many thousands of shell scripts fetching protocolbuffers releases using curl or wget. https://github.com/search?q=+language%3AShell++protocolbuffers%2Fprotobuf+AND+%28curl+OR+wget%29&type=code
• The nearly 6400 public repositories using the arduino/setup-protoc github action. Note that it blindly downloads and extracts the protocolbuffers/protobuf releases.