Hi all, Apologies that this has only come up on Slack, in PRs, and in conversations with Gary. It's overdue on the list.
Since mid-March I've been working with OSTIF on introducing SLSA Provenance attestations to Apache Commons projects. Provenance attestations are signed in-toto documents that describe how an artifact was built, in a form that lets downstream users verify it against a policy reflecting the project's release process. The most common Build Provenance type, and the only one I was aware of before this work, is the community-maintained definition for GitHub Actions workflows: https://github.com/slsa-framework/github-actions-buildtypes/tree/main/workflow/v1 That attestation is Sigstore-signed and uses the workflow plus the source commit as its parameters. Since Commons and most ASF projects are built on committer-owned machines rather than on GitHub Actions, it makes more sense for us to define our own build type and sign it with the release manager's GPG key. I've proposed one such definition here: https://github.com/apache/commons-release-plugin/blob/461186557de2b1001ef6d35193777652e503bdef/src/site/markdown/slsa/v0.1.0.md It's part of a PR that adds a `build-attestation` goal to our Release Plugin: https://github.com/apache/commons-release-plugin/pull/422 I'd appreciate it if you could take a look and share your thoughts. ### The plan The `build-attestation` goal would publish in-toto attestations as Maven artifacts attached to our builds, using the type `.in-toto.jsonl`. This format can hold multiple in-toto attestations in a single file, so it could also carry our CycloneDX and SPDX SBOMs in one download. In principle it could also include attestations from voters who rebuild the artifact, although that isn't currently possible because of how Nexus works. These attestations can then be verified by Ampel [1], a fully-fledged in-toto verification engine that is on its way to becoming an OpenSSF project. Ampel works with shareable policy documents like this one: https://github.com/puerco/lab/blob/master/javatest/apache-commons-sbom-slsa.policyset.json I'd suggest publishing such a policy from one of our Git repos (`commons-parent` is one option, but I'm open to suggestions). We could then use it for two things: 1. Verifying our own intra-Commons dependencies, as a replacement or complement to the `dependency-review` workflow. The risk of consuming a forged Commons release is essentially zero, but it sets a good example. 2. Letting downstream consumers apply the same policy in their own applications. Initially this would mostly cover signature verification, but the policy can be extended over time, from one central place, to communicate more about how we build releases. What do you think? Piotr [1] https://github.com/carabiner-dev/ampel --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
