Dependency metadata depends on Maven profile

[ppkarwasz]

The metadata of dependencies in the generated SBOM might depend on the Maven profile under which the cyclonedx-maven-plugin runs, which is a problem for the reproducibility of builds.

A minimal example where:

mvn verify

and

mvn verify -Prelease

give different results is this:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>org.example</groupId>
  <artifactId>irreproducible-sbom</artifactId>
  <version>1.0.0</version>
  <packaging>pom</packaging>

  <properties>
    <project.build.outputTimestamp>0</project.build.outputTimestamp>
  </properties>

  <dependencies>
    <dependency>
      <groupId>commons-pool</groupId>
      <artifactId>commons-pool</artifactId>
      <version>1.5.4</version>
    </dependency>
  </dependencies>

  <build>
    <plugins>
      <plugin>
        <groupId>org.cyclonedx</groupId>
        <artifactId>cyclonedx-maven-plugin</artifactId>
        <version>2.7.10</version>
        <executions>
          <execution>
            <id>generate-sbom</id>
            <goals>
              <goal>makeAggregateBom</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

The commons-pool artifact has a non-empty distributionManagement element in the release profile, but an empty one in the default profile.

[hboutemy]

reproducibility of build does not mean that you can rebuild in any condition and still get the same result: result depends on what you are running
then I don't see the fact you are seeing as a problem that has a fix: it's just a fact

[ppkarwasz]

I see this as a little incoherence in the way Maven builds the model of dependencies:

• the properties of a project are not taken into account when interpolating values in dependencies (this is only done for parent POMs),
• the profiles of a project are taken into account for building the model of dependencies.

Probably I should discuss this problem on dev@maven.
Regarding a workaround for CycloneDX, I think this is related to #245: if there was a switch to stop using <distributionManagement>, the problem I am having with commons-pool would be solved.

I agree that Maven profiles might just be considered as part of the environment that influences the result of the build, but I would prefer SBOMs to be independent of this variable.

[hboutemy]

Probably I should discuss this problem on dev@maven

yes, because cyclonedx-maven-plugin won't be able to change anything at that level

Regarding a workaround for CycloneDX, I think this is related to #245: if there was a switch to stop using <distributionManagement>, the problem I am having with commons-pool would be solved.

can you explain what is you problem on commons-pool?

[ppkarwasz]

Older versions of commons-parent (e.g. commons-parent:15) have a <distributionManagement> element in their "release" profile.

Therefore the metadata of commons-pool2 and other artifacts generated by CycloneDX depends on the name of the profile we use to compile the artifact. Since we use -Prelease, we have a different result than without the profile.

[hboutemy]

any pointer to a concrete SBOM, please?
IIUC, the metadata is not the one from the built project but from a dependency?

[ppkarwasz]

Our latest SBOM is affected:

https://repo.maven.apache.org/maven2/org/apache/logging/log4j/log4j-bom/2.22.0/log4j-bom-2.22.0-cyclonedx.xml

(look at the commons-pool component; the commons-pool2 component is Ok).

If I run ./mvnw verify artifact:compare -DskipTests on the published sources verification fails. I need to add -Prelease.

[hboutemy]

thanks for the example: I'll have a precise look

but the fact that the rebuild check requires a profile to get the same output as the reference is not a problem to me: Reproducible Builds is not expected to make the build insensitive to many aspects of the build environment and command line. The build specification is precise enough. Another way to say it is also that not getting the same output does not mean that the output is inherently "wrong" or "bad": it's just different from the reference (as if you built with a newer JDK, for example, which would bring many additional differences at bytecode level)

[vy]

I can see where @ppkarwasz is coming from: canonical input hasn't changed, why would the output? That said, I agree with @hboutemy's assessment. I think it practically boils down to "Do you want to get the same output? Provide the same input in the same manner then!".

@ppkarwasz and I spent significant time (mostly wasted on CRLF-vs-LF discrepancies 😮‍💨) on making reproducible builds platform-independent for Log4j et al. After several months, looking back right now, instead of rolling out dozens of custom hacks, I wish we would rather have simply said "Distribution is reproducible if the build platform, JDK, and instructions are identical."

[ppkarwasz]

I posted a question on dev@maven regarding the influence of profiles on the effective models of dependencies.

@vy, @hboutemy: I agree that in order to reproduce the artifacts the user should run -Prelease, so I am closing this issue. However I was not expecting this kind of differences (i.e. differences in the metadata of a transitive dependency) to appear.

[hboutemy]

I'm happy that you tried the "making reproducible builds platform-independent" path and went to the conclusion that it is not worth the effort: that's my conclusion too

I suppose you saw that recent releases of log4j2 have been successfully independently rebuilt and compared against the reference build on Maven Central: https:/jvm-repo-rebuild/reproducible-central/blob/master/content/org/apache/logging/log4j/log4j/README.md

this proves that they are Reproducible

and the consequence is that if someone rebuilds and gets a different result, the culprit is not the software but the rebuilder, who was not able to do what many other people can do

[ppkarwasz]

@hboutemy,

No, I didn't check reproducible-central recently. Thanks for adding Log4j to the project.

Should we also publish some form of *.buildspec to Maven Central? I am still trying to understand how to use CycloneDX formulation element.

[hboutemy]

Should we also publish some form of *.buildspec to Maven Central?

no, this is not an official format but just my own reproducible-central internal format

I am still trying to understand how to use CycloneDX formulation element.

perhaps this one would be a good target, even if I read the description as a recording of how the build was done, not a definition of how to rebuild (which may not be exactly the same)

notice that given CycloneDX is not so much about reproducible builds, the rebuild spec is not really a topic yet here