Consolidating a bit of the discussion in this thread. On the topic of Java modules being a solution:
Looking at Maven configuration would be needed > only if, after building the dependency tree, we want complementary > information such as version numbers (when not declared in the > `module-info`) and from which repository the dependency was downloaded. This is precisely what is needed to produce an accurate software bill of materials (SBOM). Java modules do not appear to provide this information alone, which means any tool that scans a JAR will not get quality information out of the module metadata. On the challenges of trusted checksums (thanks Tamás!): 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. This alludes to what John was getting at in his first email on the thread. The broader ecosystem is not aware of the Trusted Checksums feature and thus has not adopted it. GitHub's Dependabot would need to implement its own logic to detect the presence of trusted checksum files and run appropriate maven commands to get those checksum files updated (is there a standard/consistent way to do this?). The same would go for other tools like Renovate, which does not run any post-update commands for Maven [1]. The last thing I want to add with respect to trusted checksums vs. a lockfile is that the maven-lockfile we're currently working on provides a context tree for dependencies. Trusted checksums provide a flat tree of dependencies that can provide completeness, but additional analysis would be needed to determine the context of the dependency. Ex: is the dependency reachable at runtime? Does it potentially participate in the build process? Software teams need this context to determine if a dependency vulnerability has real impact and should be patched, or conversely is safe to keep as-is. [1] https://docs.renovatebot.com/configuration-options/#postupdateoptions On Wed, Jan 28, 2026 at 7:51 AM Tamás Cservenák <[email protected]> wrote: > And one more thing... > > Toolbox has two mojos, tree (the usual "tree" - project deps) but also > plugin-tree (if unfiltered, will have multiple roots, one for each > plugin) > https://gist.github.com/cstamas/794d055a9dcd5ffe99b92bdcb4520686 > > Of course, these trees do NOT contain "dynamically resolved" things > you mentioned. > > T > > On Wed, Jan 28, 2026 at 1:29 PM Tamás Cservenák <[email protected]> > wrote: > > > > 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] > > -- Adam Kaplan He/Him Senior Principal Software Engineer Red Hat <https://www.redhat.com> 100 E. Davie Street [email protected] <https://www.redhat.com>
