A bit late on this thread, but I felt compelled to respond as one of the contributors to such a "Maven Lockfile" plugin [1]. I also work for Red Hat, where we too rebuild artifacts published on Maven Central.
Tamas touches on one of the features of a lockfile - checksums - which many package ecosystems also implement. The trusted checksums demo [2] implements similar functionality as the Go programming language's `go.sum` file, and I agree that the checksum problem is "solved" at the aether resolver level. It's less clear to me if this feature set will be exposed through a direct Maven configuration option in 4.x - is this on the roadmap? That said, from my perspective the listing and validation of checksums is a small feature of a build lockfile. The more important feature of any lockfile is a transparent and complete dependency tree that can be validated at build time. These dependency trees, in turn, can be used to generate an accurate software bill of materials (SBOM). Hermetic (“offline”) builds that pre-fetch the dependencies in lockfiles can further validate the completeness of any generated SBOM. This is the philosophy of the Hermeto project, which I am also involved in [3]. Unfortunately obtaining a complete dependency tree a-priori in Maven is exceptionally hard, and perhaps impossible in the general case. Many plugins dynamically fetch dependencies for the sake of developer convenience - even the Surefire plugin does this as a feature [4]! In today's era of open source software supply chain attacks and regulatory requirements for accurate SBOMs, I think any plugin feature that dynamically obtains dependencies needs to be reconsidered. Unfortunately there is no way to roll back such behavior without causing enormous disruption to the Java ecosystem at large. [1] https://github.com/chains-project/maven-lockfile [2] https://github.com/cstamas/tc-demo [3] https://hermetoproject.github.io/hermeto/ [4] https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit.html On Sun, Dec 7, 2025 at 6:37 PM Tamás Cservenák <[email protected]> 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] > > -- Adam Kaplan He/Him Senior Principal Software Engineer Red Hat <https://www.redhat.com> 100 E. Davie Street [email protected] <https://www.redhat.com>
