Thanks so much Tamas. Also Elliotte.. I agree that the checksums should
change .. but it should be possible to lock to specific artifacts with a
checksum or some other value more closely under control than the GAV
coordinates .. since they can be pointing to different artifacts.
Manfred
On 2025-12-07 15:27, Tamás Cservenák wrote:
Howdy,
Tried to gather some "bigger picture" around this topic:
https://maveniverse.eu/blog/2025/12/06/lockfiles/
Thanks
T
On Sat, Dec 6, 2025 at 1:19 PM Elliotte Rusty Harold <[email protected]> wrote:
On Fri, Dec 5, 2025 at 7:36 PM Manfred Moser <[email protected]> wrote:
I work for Chainguard and we are rebuilding artifacts from source within
our infrastructure and create completely trusted binaries with SLSA and
SBOM info and more and provide these binaries and supplementary files to
our customers. Because Maven (JAR and others) builds are often not
reproducible in terms of leading to exact same checksums (unless a
project set it up to wipe timestamps and such) our binaries do have
different checksums from the ones supplied via Maven Central.
I wouldn't expect checksums to match in a scenario like that. A
different entity is rebuilding the project with a potentially
different compiler, JDK, and chain of trust. I maybe don't want those
checksums to match.
At the moment even reproducible builds are not necessarily reproducible
when it comes to shading classes into other jars and the exact
dependencies being used when creating tarballs or whatever with JARs
inside with the assembly plugin for example.
Again, I think that's working as intended. Shading changes the binary
code that's running. It shouldn't have the same checksum.
--
Elliotte Rusty Harold
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
