protobuf icon indicating copy to clipboard operation
protobuf copied to clipboard

Published 20 hours ago • verified publisher icon protocolbuffers

Publish checksums with releases

Open alexeagle opened this issue 1 year ago • 29 comments

@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

alexeagle avatar Mar 14 '24 16:03 alexeagle

@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.

sgammon avatar Mar 15 '24 08:03 sgammon

@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.

alexeagle avatar Mar 15 '24 15:03 alexeagle

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

epicseven-cup avatar May 12 '24 02:05 epicseven-cup

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

esorot avatar Jul 09 '24 20:07 esorot

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.

zhangskz avatar Oct 01 '24 21:10 zhangskz

@zhangskz exactly, users should vendor the checksums to follow the principle of trust-on-first-use.

alexeagle avatar Oct 01 '24 23:10 alexeagle