Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plugin doesn't support reproducible build #177

Open
jonesbusy opened this issue Feb 19, 2025 · 5 comments · May be fixed by #179
Open

Plugin doesn't support reproducible build #177

jonesbusy opened this issue Feb 19, 2025 · 5 comments · May be fixed by #179

Comments

@jonesbusy
Copy link

Hi,

Given a build with

<properties>
....
    <project.build.outputTimestamp>2025-01-01T00:00:00Z</project.build.outputTimestamp>
...
</properties>

and spdx plugin

        <plugin>
          <groupId>org.spdx</groupId>
          <artifactId>spdx-maven-plugin</artifactId>
          <version>1.0.0-RC1</version>
          <executions>
            <execution>
              <id>build-spdx</id>
              <goals>
                <goal>createSPDX</goal>
              </goals>
            </execution>
          </executions>
        </plugin>

Then

mvn clean install
mvn verify artifact:compare
[ERROR] sha512 mismatch **.spdx.json: investigate with diffoscope ****.spdx.json target/site/l*****.spdx.json
[ERROR] Reproducible Build output summary: 3 files ok, 1 different

Using diffoscope like recommended by maven show difference because of the date on the spdx license

 {
      "SPDXID": "SPDXRef-DOCUMENT",
      "creationInfo": {
-        "created": "2025-02-19T07:46:56Z",
+        "created": "2025-02-19T07:48:32Z",
         "creators": [
             "Tool: spdx-maven-plugin"
         ],
         "licenseListVersion": "3.26.0"
     },
     "dataLicense": "CC0-1.0",
@goneall
Copy link
Member

goneall commented Feb 19, 2025

Thanks @jonesbusy for reporting this. The created field is required is represents the date-time when the SPDX file was generated. We could take an optional parameter to set the creation date - but to use this we would need to set it to a common date.

@david-a-wheeler - I recall discussing a similar issue in a past Open Source Summit - let me know if you have any ideas.

@jonesbusy
Copy link
Author

Thanks. I'm not 100% sure how the timestamp should behave for reproducible build (specially when stored on text file)

I just remember a PR on one plugin jenkinsci/maven-hpi-plugin@77ae644#diff-4b760e437fb48628f53050007da3915c070571629a0763c9a9b83b8d4d205a29R76-R102

@Parameter(defaultValue = "${project.build.outputTimestamp}")
private String outputTimestamp;

javadoc plugin just decide not to ouput any timestamp on files: https://github.com/apache/maven-javadoc-plugin/blob/f9d3227cd18ee61d14ea6334ddcc10d97b7e1300/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L4814-L4817

@goneall
Copy link
Member

goneall commented Feb 20, 2025

Thanks @jonesbusy for the pointer to the maven hpi plugin. Using the project.build.outputTimestamp for the creation time makes more sense then using the current time. It also gives the user the option to override the the timestamp.

I'm thinking of using the SPDX term created for the property name.

I'm not sure if changing the default itself will fix the problem or if we would need to do something in the configuration file in addition.

Removing the timestamp unfortunately isn't an option since it is a required SPDX field.

@goneall
Copy link
Member

goneall commented Feb 21, 2025

Doing a bit more research, I'm about 80% sure using the project.build.outputTimestamp as the default will resolve the issue.

Note - we'll have to support both the seconds since epoch and ISO 8601 formats.

I can create a PR with the changes.

goneall added a commit that referenced this issue Feb 21, 2025
Fixes #177

NOTE: Unit tests are currently failing - it is not picking up the
default parameter
@goneall goneall linked a pull request Feb 21, 2025 that will close this issue
@goneall
Copy link
Member

goneall commented Feb 21, 2025

@jonesbusy I attempted a fix with PR #179 - however, it isn't picking up the default value as expected.

Let me know if you see any obvious errors in the implementation. I suspect the way I am specifying the property and reading the property isn't correct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants