rules_fuzzing icon indicating copy to clipboard operation
rules_fuzzing copied to clipboard

Stable release archives

Open fmeum opened this issue 2 years ago • 2 comments

The source archives that GitHub auto-generates for each release are not guaranteed to have a stable hash over time - see https://github.com/bazel-contrib/SIG-rules-authors/issues/11 for the full context.

In order to be able to safely reference rules_fuzzing releases with a stable hash, it would be very helpful if the v0.4.0 release could come with a manually uploaded release archive, for example generated with git archive --output=rules_fuzzing-v0.4.0.tar.gz v0.4.0.

Edit: The release notes for v0.4.0 have an incomplete WORKSPACE snippet.

fmeum avatar Sep 10 '23 14:09 fmeum

Edit: The release notes for v0.4.0 have an incomplete WORKSPACE snippet.

Thanks for pointing this out! I was using an older snippet as a template - let me know if you spot any other issues.

The source archives that GitHub auto-generates for each release are not guaranteed to have a stable hash over time - see bazel-contrib/SIG-rules-authors#11 for the full context.

In order to be able to safely reference rules_fuzzing releases with a stable hash, it would be very helpful if the v0.4.0 release could come with a manually uploaded release archive, for example generated with git archive --output=rules_fuzzing-v0.4.0.tar.gz v0.4.0.

How big of an issue this is in practice? One advantage that I see with the Github-generated archives is that their provenance is pretty much clear, as long as we trust Github. Custom-generated archives are at least in theory prone to an extra source of human error.

stefanbucur avatar Sep 11 '23 02:09 stefanbucur

How big of an issue this is in practice? One advantage that I see with the Github-generated archives is that their provenance is pretty much clear, as long as we trust Github. Custom-generated archives are at least in theory prone to an extra source of human error.

Yes, ideally we would be able to have both stable hashes and clear provenance. I would go as far as arguing that this is GitHub's biggest missed low-hanging fruit for improving supply chain security. GitHub has a blog post up about what they guarantee and don't guarantee in which they recommend using release archives for long-term stable hashes: https://github.blog/2023-02-21-update-on-the-future-stability-of-source-code-archives-and-hashes/.

Long-term stability is an important property: For example, I am currently looking into packaging rules_fuzzing for the Bazel Central Registry, but that requires a stable hash. Registry entries are immutable, so existing versions would break permanently when GitHub changes its archive generation in the future.

fmeum avatar Sep 11 '23 06:09 fmeum