search

bazel-contrib / rules_fuzzing

Bazel Starlark extensions for defining fuzz tests in Bazel projects
Apache License 2.0
84 stars 20 forks source link

Stable release archives #234

Open fmeum opened 1 year ago

fmeum commented 1 year ago

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.

stefanbucur commented 1 year ago

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.

fmeum commented 1 year ago

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.