Howdy, personally I keep these two split, for a reason: - GAV w/ checksum - tree
for a reason. Our example, the IPFS repo we talk about, locks down everything (that maven resolves during build). For example, if you look at checksums file (using permalink of current state of affairs): https://github.com/ipfs-shipyard/java-ipfs-http-client/blob/2523fb26386ad1a94bda11d5277d6f59eaca470c/.mvn/checksums/checksums-central.sha512 1) There are two commons-codec versions (do a search in the browser for "commons-codec/commons"), version 1.19.0 and 1.20.0, while the project itself does not depend on any of these. These are in fact dependencies on some plugins used in the build. 2) There are 11 ASF parent POMs! (do a search in the browser for "org/apache/apache"). Again, the project is not an ASF project, these parents are used by various ASF Maven core plugins! For case 1) that is an artifact, but again, project is not even using it (build is), for case 2), project is not even in "control", as parent POMs are pulled during model building. To look into tree, I usually use these commands (after successfully built project w/ checksums enforced -- so I know all is right and in place): https://gist.github.com/cstamas/585b21880ff1e05606bb70c97dec938a Nota bene: room for improvement, I need to pass in `-Daether.artifactResolver.postProcessor.trustedChecksums=false` to temporarily disable TC post processor (that performs checksum validation) as project configures resolver in full lock down mode, so even ad-hoc plugin invocation is impossible! In gist above there are 4 invocations: tree, tree-find, plugin-tree and plugin-tree-find With these it is easy to figure out 1), to find where is commons-codec used (where it is not used, and where it is used) For 2), as it is "meta" even in Maven (model builder "crawls" model and asks models for resolution) are not. But, they are still protected, as they also go through Resolver, as parent POM is a very nice attack vector as well. As you see, the same GAV may appear in multiple places and contexts. All in all, consequences: - if I download full TC list, I have everything I need for the build (even offline) - the TC list consolidated and made unique, to place them in tree, I use alt tools Refs: https://maveniverse.eu/docs/toolbox/plugin-documentation/plugin-info.html On Tue, Feb 10, 2026 at 4:53 PM Adam Kaplan <[email protected]> wrote: > > 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> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
