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