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?

[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.

[ppkarwasz]

@garydgregory

I've added tests that specifically exercise the serialization models with serialize/deserialize and deserialize/serialize round-trips, in b45f2ed and 482a445. These confirm that the Jackson models carry all the necessary fields and don't lose data in either direction.

With those in place, I think coverage on this PR is in good shape:

• Main classes: ~90% line coverage on average.
• DTOs: ~80% line coverage on average.

Let me know if there's a specific area you'd like me to push further.

[garydgregory]

Hi @ppkarwasz

What is the relationship b/w this PR and the one in Commons Parent? Is one required by the other?

[ppkarwasz]

The PRs are independent and follow separate SLSA tracks:

• This PR is necessary for the SLSA Build Track and generates attestations to explain how binaries are built.
• Add SLSA Source Provenance workflow commons-parent#706 is necessary for the SLSA Source Track and generates attestation to explain how commits come into existence.

Deployed together they are stronger: you can verify that a binary comes from a particular commit and the commit was submitted to a protected branch. In recent supply-chain attacks, one of those conditions are not satisfied: for example the build is original, but the tagged commit comes from a fork, not the original repository.