And to continue on this topic... As I said, there is a _list_ of all the materials needed for the build.
But if you rebuild the project (let's use ipfs client as guinea pig) with empty repo and reverse tree tracking enabled: https://gist.github.com/cstamas/68c26d7d82ff5134eaf4c311944e28bb You will end up (with incomplete, but is better than nothing) information stored in local repo (as .tracking) why each artifact is here. So to say, with tree branches.... For example: org.jetbrains.annotations is here due https://gist.github.com/cstamas/51ef4515b79ae0fb13360ba379ed6eb6 Or java-multibase is here due: https://gist.github.com/cstamas/5cfc38c5484a86598303825eb379aa3e etc On Wed, Jan 28, 2026 at 12:59 PM Tamás Cservenák <[email protected]> wrote: > > 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]
