Add SLSA Source Provenance workflow

[ppkarwasz]

Add a reusable workflow that generates a SLSA Source Provenance attestation for the triggering commit, and a caller that wires it up for this repository:

• slsa-provenance-reusable.yml: signs a SLSA Provenance attestation for the commit via Sigstore (OIDC) and stores the attestation in Git Notes using slsa-framework/source-actions. Merge commits are supported.
• slsa-provenance.yml: runs the reusable workflow on every push to a protected named reference (master, release, rel/*).

Combined with the branch and tag protection rules introduced in #705, this contributes to SLSA Source L3 compliance. The reusable workflow is also documented in .github/workflows/README.md.

Note

This PR should be evaluated once the protection rules introduced in #705 are enabled.

[garydgregory]

Hi @ppkarwasz

Is this a replacement for the Commons Release Plugin recent proposal for SLSA?

[ppkarwasz]

It's more of a complement:

• Add build-attestation target commons-release-plugin#422 allows us to create Build Provenance attestations,
• this PR allows use to create Source Provenance attestations, which give informations such as:
  • who made the commit,
  • what protections were in place,
  • possibly who reviewed the commit.

[garydgregory]

Build vs Source? I don't know what that means in this context.

[ppkarwasz]

These refers to the different SLSA tracks (see specification) that I mentioned in apache/commons-release-plugin#422. Summarizing:

1. The source track shows relationships between source commits,
2. The build track shows relationships between a source commit and built artifacts.

Recent supply-chain attack have often:

• Built artifacts from a commit that was never part of a repo. It was a commit on a fork, which was tagged.
• Built artifacts in a different way than the original artifact (e.g. on an attacker-controlled machine instead of GitHub Actions).

[garydgregory]

The source track shows relationships between source commits,

Is this the same as the commit history, the git log? Commit A's parent is B, B's parent is C, and so on? All the way to the first commit in the repo?

The build track shows relationships between a source commit and built artifacts.

This is the same as above, but per JAR, POM, all the files we put on Maven Central? In our case, these would be the same for each file, right?

Built artifacts from a commit that was never part of a repo. It was a commit on a fork, which was tagged.

This PR causes a build to fail if the above happens? Like if a RM tries to release from his fork instead of from the repo?

Let's say a bad guy breaks into Apache's dist server and replaces a JAR file, couldn't they also replace everything related to that JAR?

[ppkarwasz]

The source track shows relationships between source commits,

Is this the same as the commit history, the git log? Commit A's parent is B, B's parent is C, and so on? All the way to the first commit in the repo?

Yes, except each commit is signed by Sigstore using an ephemeral certificate, so you can verify the commit date too. Normally in Git you can use any author, committer and commit date.

Additional properties are also registered, like the existence of technical controls against force-push and deletion (see source-tool Controls for properties followed by source-tool.

This is the same as above, but per JAR, POM, all the files we put on Maven Central? In our case, these would be the same for each file, right?

Yes, the attestation contains both the SHA1 of the commit and checksums of the Maven artifacts and you bind them together, basically stating “I built these artifacts from this commit”.

This PR causes a build to fail if the above happens? Like if a RM tries to release from his fork instead of from the repo?

Let's say a bad guy breaks into Apache's dist server and replaces a JAR file, couldn't they also replace everything related to that JAR?

This PR does not verify the attestation, it just produces them. I will add other workflows that can verify attestation in the dependencies of a project: e.g. Log4j could verify that the Commons Compress artifact was signed by you and was built from a commit in the commons-compress repo.

There is no single way to verify an artifact: you need to know the release policy of a project and verify if they were met. If you release from a local release branch and then you push it to GitHub, consumers can verify that:

• The Compress JAR came from this repo and was signed by you,
• That the commit used by the release was pushed to this repo.

TL;DR: we set the expectations of how the project works and consumers verify that our own rules were followed.