Howdy, Nice to hear from you Adam!
I was recently involved in a project where PO wanted "fully locked down" build, and he got it: https://github.com/ipfs-shipyard/java-ipfs-http-client (this project depends on a handful of small other projects, and we had a "release spree" to modularize those too -- not much important). But this "fully locked" (using TC feature) showed two interesting side-effects: First is obvious: https://github.com/ipfs-shipyard/java-ipfs-http-client/pull/273 Dependabot generated PR must have human assistance (as by def they fail, as expected, since checksums drift with update). Hence, a subsequent human made (and verified) commit is a must to make it mergeable. Second was less obvious and more a surprise (due "black box" nature of service they use for releases -- I am pushing them toward Central publishing): https://jitpack.io/#ipfs-shipyard/java-ipfs-http-client The release 1.5.0 _failed_ with this in log: https://jitpack.io/com/github/ipfs-shipyard/java-ipfs-http-client/1.5.0/build.log (my release attempt comments may be tracked here https://github.com/ipfs-shipyard/java-ipfs-http-client/issues/271) In short: fully locked down build in this way _refuses_ to resolve ANYTHING not in checksums. As can be seen, Jitpack seems to have tried to invoke (undocumented, I did not find anything about this in their doco, nor I have idea why they use ancient plugin version from 2014) exec-maven-plugin, and resolver refused to resolve it. In fact, with this project fully locked down, the only way to invoke ad-hoc plugins on them is possible only if you lax TC, like this: https://gist.github.com/cstamas/e21cfe67a35dab4c07f6ca7e3fc1419d But, the consequence, and on tangent to what you say, checksums file must list everything that is getting resolved via Resolver, hence, even the surefire dynamically resolved JAR (check it out, it is there too). In other words, these files list _everyting_ you need for the build: https://github.com/ipfs-shipyard/java-ipfs-http-client/tree/master/.mvn/checksums We for sure need to work on this more... (and ideas welcome!) For start, latest resolver will have this: https://github.com/apache/maven-resolver/commit/645cb05b068dd17121c09e374cde69eefd7aca70 As today, TC are "all or nothing" (as can be seen on example project above; even plugins and ad-hoc plugin invocations are subjected to it). The idea here is to limit TC to "project dependencies" only... we have members questioning this, as plugins can be targeted by supply chain attack just like dependencies can, but the intent here is to leave some leeway to users. Happy to continue on this topic! PS: No, Maven4 in this regard received no substantial change (yet) On Wed, Jan 28, 2026 at 12:34 AM Adam Kaplan <[email protected]> wrote: > > 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> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
