Goals of this project

[aalmiray]

Starting with jvm-repo-rebuild/reproducible-central#108 (comment)

The main idea is to check artifacts not published to Maven Central which are somehow available from public resources, typically as GitHub/GitLab release assets but it could also be AWS S3 or some other online resource. Artifacts may be built with Maven, Gradle, or any other means required by their owning projects. JReleaser may be used to collect information on releasable artifacts that may be later used by the spec to verify said artifacts.

What would be needed:

• build instructions to generate local artifacts
• a collection of artifacts to be verified. Required properties are:
  • local path to the recently built artifact
  • remote URL for downloading reference artifact for comparison

A collection of artifacts to be checked is necessary as a GitHub/GitLab release may contain more artifacts than those produced by the build. This may include for example, signatures and checksum files, SLSA provenance (intoto.json), etc. As such, iterating over the list of published release assets may result in a bigger set of files, some of which may not be available in local.

To begin with, JReleaser may be used to generate a list of artifacts with their respective required properties. Given that JReleaser supports more than just Java projects it might make sense to discuss if and when reproducible-releases becomes open to other languages. GoReleaser is the preferred tool for releasing Go projects. If this project welcomes more than Java projects to be verified and if an extra file or files are needed (created or updated by JReleaser) then similar behavior would have to be ported to GoReleaser so that this project may integrated with it.

WDYT @hboutemy ?

[hboutemy]

yes, just a few details

A collection of artifacts to be checked is necessary [...] This may include for example, signatures and checksum files, SLSA provenance (intoto.json), etc.

signature, provenance and so on are not expected to be reproducible (by definition): the collection may just be an exclusion filter on a directory listing

discuss if and when reproducible-releases becomes open to other languages.

what an ambition! :)
but you're right, it's only a question of being able to specify a rebuild environment (spec) and being able to execute it: it may not be more complex for Go than for Java

[aalmiray]

signature, provenance and so on are not expected to be reproducible (by definition): the collection may just be an exclusion filter on a directory listing

Gotcha. I suppose JReleaser should compile a list of releasable artifacts that are deemed reproducible and skip every other release asset that it's not. OK.

what an ambition! :) but you're right, it's only a question of being able to specify a rebuild environment (spec) and being able to execute it: it may not be more complex for Go than for Java

😁 Indeed. Though starting with Java to flesh out ideas would be the first step.

[aalmiray]

Additional questions:

• The bare minimum properties to identify and verify an artifact are: path (local), url (remote). Do we need more?
• Should the artifact set be defined in the spec file as well?
  • if not, then as an external file with which format? properties, json, yaml, toml.