Add build-attestation target

[ppkarwasz]

This PR was moved from apache/commons-build-plugin#417

It adds a goal to generate a SLSA build attestation and attaches it to the build as a file with the intoto.json extension.

The attestation records the following information about the build environment:

• The Java version used (vendor, version string)
• The Maven version used
• The gitTree hash of the unpacked Java distribution
• The gitTree hash of the unpacked Maven distribution

[ppkarwasz]

You can find the documentation of what elements are contained in the attestations in this file (included in the PR):

https://github.com/apache/commons-release-plugin/blob/feat/slsa/src/site/markdown/slsa/v0.1.0.md

I have some doubts regarding, which dependencies of the project build should be included in the attestation:

• Some information about the Maven distribution should certainly be present.
• However the checksums of all project dependencies, Maven plugins and their dependencies might be more suited for the build SBOM. By verifying the SBOM reproducibility, we have already discovered some small differences in the dependencies used by the release build and the voting builds.

[garydgregory]

What about the JDK or OS?

[ppkarwasz]

Information about the JDK is already present. I don't know if we need information about the OS: that information is usually partially included in the JDK version strings.

[garydgregory]

There is no need for an additional level of "internal" package naming IMO since the whole component is "internal" to our release process.

[ppkarwasz]

In 16f776f I added support for DSSE envelope signing, which leverages the functionality of the GPG Maven plugin to sign the attestation with GPG and wrap both the payload and signature in a single file.

A lot of it is vibe-coded, mostly reviewed, but it needs a thorough review, especially on the documentation side. If this helps, I could split this PR into three parts:

• the Jackson models for the data,
• the generation of attestations without signing,
• the signing feature.

What do you think?

[garydgregory]

I don't want to review vibe coded output until you review it line-by-line and prune/validate any junk out of it. When you say it's been proofed, I'll take a look.

[ppkarwasz]

@garydgregory,

I have reviewed the generated parts, fixed Javadoc comments and added additional tests.

The code is the first thing I look at and verify line by line. I must admit I don't look too much at Javadoc, especially since this project requires every method (even private ones) to have a comment.

[garydgregory]

If you don't review something, delete it then. Otherwise, you are effectively asking someone else to do it for you 😉

[ppkarwasz]

That is what I did with overly complex Javadoc comments.

[ppkarwasz]

As I mentioned before, this PR might be hard to check in one piece. What do you think about splitting it into pieces and discussing each piece separately?

[garydgregory]

Let me take a look in the morning...

[garydgregory]

HI @ppkarwasz

Thank you for the PR. I've scattered comments throughout.

TY!

[garydgregory]

This change should not be required.

[ppkarwasz]

IIRC this is inconsistent with other Commons projects, where com.* and org.* imports are in the same group. Is there any reason to group them separately?

[Copilot]

Pull request overview

Adds a new build-attestation Maven plugin goal to generate SLSA v1.2 build provenance (optionally DSSE+OpenPGP-signed) and attach it as an additional build artifact, along with supporting internal utilities, model classes, tests, and documentation.

Changes:

• Introduces build-attestation mojo that emits a SLSA provenance statement (or DSSE envelope) and attaches it as an intoto.jsonl artifact.
• Adds SLSA v1.2 Jackson model classes plus supporting utilities for Git/JDK/Maven provenance and DSSE signing.
• Adds tests, fixtures, and site documentation describing the new build type and attestation format.

Reviewed changes

Copilot reviewed 27 out of 27 changed files in this pull request and generated 11 comments.

Show a summary per file

File	Description
pom.xml	Adds dependencies/BOMs and configures filtered test resources; also changes project version.
checkstyle.xml	Adjusts import grouping to accommodate new third-party imports.
fb-excludes.xml	Adds SpotBugs suppression for representation-exposure findings.
src/main/java/org/apache/commons/release/plugin/mojos/BuildAttestationMojo.java	New mojo that builds and writes/attaches the attestation (optionally signed).
src/main/java/org/apache/commons/release/plugin/internal/ArtifactUtils.java	Utilities to build PURLs, filenames, and digest sets for artifacts.
src/main/java/org/apache/commons/release/plugin/internal/BuildDefinitions.java	Collects external parameters and creates JDK/Maven resource descriptors.
src/main/java/org/apache/commons/release/plugin/internal/DsseUtils.java	DSSE PAE generation and GPG signing helpers.
src/main/java/org/apache/commons/release/plugin/internal/GitUtils.java	Git helpers for branch detection, SCM URI conversion, and gitTree hashing.
src/main/java/org/apache/commons/release/plugin/internal/package-info.java	Package-level docs for internal utilities.
src/main/java/org/apache/commons/release/plugin/slsa/v1_2/package-info.java	Package-level docs for SLSA v1.2 model classes.
src/main/java/org/apache/commons/release/plugin/slsa/v1_2/BuildDefinition.java	SLSA build definition model.
src/main/java/org/apache/commons/release/plugin/slsa/v1_2/BuildMetadata.java	SLSA build metadata model.
src/main/java/org/apache/commons/release/plugin/slsa/v1_2/Builder.java	SLSA builder model.
src/main/java/org/apache/commons/release/plugin/slsa/v1_2/DsseEnvelope.java	DSSE envelope model.
src/main/java/org/apache/commons/release/plugin/slsa/v1_2/Provenance.java	SLSA provenance predicate root model.
src/main/java/org/apache/commons/release/plugin/slsa/v1_2/ResourceDescriptor.java	Resource descriptor model used for subjects/materials.
src/main/java/org/apache/commons/release/plugin/slsa/v1_2/RunDetails.java	SLSA run details model.
src/main/java/org/apache/commons/release/plugin/slsa/v1_2/Signature.java	DSSE signature model.
src/main/java/org/apache/commons/release/plugin/slsa/v1_2/Statement.java	in-toto Statement model wrapping the provenance.
src/site/markdown/slsa/v0.1.0.md	Documents the build type and attestation format/fields.
src/test/java/org/apache/commons/release/plugin/internal/BuildDefinitionsTest.java	Unit tests for command-line reconstruction.
src/test/java/org/apache/commons/release/plugin/internal/MojoUtils.java	Test utilities for setting up Plexus container/repo session.
src/test/java/org/apache/commons/release/plugin/mojos/BuildAttestationMojoTest.java	Integration-style tests for unsigned/signed attestation outputs.
src/test/resources/plugin.properties	Filtered plugin coordinates used by tests.
src/test/resources/attestations/commons-text-1.4.intoto.json	Filtered attestation fixture used as expected statement content.
src/test/resources/artifacts/artifact-jar.txt	Mock artifact fixture.
src/test/resources/artifacts/artifact-pom.txt	Mock artifact fixture.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ppkarwasz]

Hi @garydgregory,

I corrected some minor defects, mostly in documentation, but with two relevant changes:

• The attestation didn't have an important _type property. 😜 Fixed in 476ac4f
• The standard Maven ScmManager turned out less useful than I thought: it can not even return the current branch of a Git repo. Since I improved GitUtils to test methods against real repositories created by git, I just remove ScmManager in 9f69d2e and added some logic to find the current commit SHA1 manually.

Since this PR is huge, what do you think about pushing the SLSA models to master directly, so we can only discuss the classes that matter?

[ppkarwasz]

I pushed the SLSA models to master in 546dfbf and changed the target of this PR to the same branch.

This should reduce the overhead of reviewing this PR.

[garydgregory]

I pushed the SLSA models to master in 546dfbf and changed the target of this PR to the same branch.

This should reduce the overhead of reviewing this PR.

I added comments. A bunch of new public code with zero tests? Ahem... please fix that.

[ppkarwasz]

I added comments. A bunch of new public code with zero tests? Ahem... please fix that.

Those classes are DTOs. The surface is getters, setters, and Jackson annotations, and this PR already exercises them indirectly through the code that uses them, so I don't think per-field getter/setter tests would add much.

I looked into golden-file tests against canonical examples, but neither in-toto nor SLSA publishes a conformance fixture set, and the parts of the schema that actually vary in practice (predicate, externalParameters, internalParameters) are spec'd as open object types. There's a limit to what a round-trip test pins down beyond the field names themselves.