To detect is TC active, all I can come up with is this hack (should work with both, mvn3 and mvn4): https://gist.github.com/cstamas/9ca48a5f1979abeb756e2224966c6745
Still, I hope we will enhance these "hidden" features in the future. Thanks T On Thu, Feb 12, 2026 at 6:08 PM Tamás Cservenák <[email protected]> wrote: > > Adam, > > sorry, I completely missed one of your very important questions. > > So, here is an update PR: > https://github.com/ipfs-shipyard/java-ipfs-http-client/pull/282 > > Steps I created it with are recorded in this gist: > https://gist.github.com/cstamas/be4e45d3e1704e317b8182d433d8649c > > Thanks > T > > On Wed, Feb 11, 2026 at 6:32 PM Tamás Cservenák <[email protected]> wrote: > > > > Howdy, > > > > And one more thing: Started an email, and realized we have no doco for > > it, so I tried to document "how resolver works" (high level, but also > > to align lingo, so we all know what we talk about) here: > > https://github.com/apache/maven-resolver/pull/1794 > > > > But it is still WIP. But in short, the "resolve" process is series of > > steps like: > > 1- collect GAV: GAV => "depNode dirty graph" (may have cycles, is not > > a tree) -- two collector implementations exists since maven 3.9+, the > > old DepthFirst and new BreadthFirst (default in mvn4). This step also > > implicitly invokes step 4 to get needed POMs to build eff models to > > "crawl" upon. > > 2- conflict resolution (selects "winners", removes cycles, makes graph > > a tree): "depNode dirty graph" => "depNode tree" (no cycles) -- two > > conflict resolvers exists in Maven 4 ("legacy" and new "path based") > > 3- flatten tree (in 3 possible ways: pre-order, post-order and level > > order) "depNode tree" => "RGAV list" > > 4- resolve artifacts "RGAV list" => files (usually pointing to local > > repo) -- this is where JARs are downloaded (if needed) <- TC hooks > > into here, so everything, JAR, POM that "goes thru" resolver is > > enforced (latest resolver 1/2 has "scope" support, so may enforce all > > as today, or only "project deps") > > > > Note 1: step 1, 2 and 3 operates on _models_ only (not only POMs, but > > effective models built out of POMs, hence parents, imports, etc), no > > JAR is pulled/used in any of these steps. Also, Maven lingo calls > > steps 1 and 2 "collect/collecting" and steps 3, 4 "resolving" (same if > > all steps 1,2,3,4 happens as one call, as Repository System has > > several entrypoints, some do 1-2, some do 3-4 and some do 1-2-3-4 as > > one call). > > Note 2: step 3 produces also "classpath order" of artifacts, and for > > example this is where Maven 3 and Maven 4 differ: Maven used > > historically pre-order, but Maven 4 uses level order (nodes closer to > > tree root are closer to resulting list head). > > Note 3: step 2 also supports different strategies for winner > > selection, maven3 used "nearest" (closest to root), while maven 4 > > supports "highest" (as per comparable Version for same GA) strategy as > > well > > Note 4: ongoing experiment with "dependency management": they are > > historically black/white (managed or not managed, managed == > > enforced), ongoing experiment is adding "management advice" > > https://github.com/apache/maven-resolver/pull/1613 (so making it tri > > valued: unmanaged, advised, managed), adding a "middle ground" value > > between values existing today > > Note 5: once "advise" is in place, next logical step is to provide > > "platform support", with initial idea is that resolver may (partially > > or completely) repeat steps 1-2, if conflict resolver deems it > > necessary (work is heavily cached, so doing that would not introduce > > huge performance penalty) > > Note 6: the mentioned missing piece from lockfile support blog, > > ranges, should be covered by platform as well (as again, platform as > > such may be "enforced" or "advised" or "aligning" etc -- brainstorming > > still) > > > > As you see, we are currently focusing quite a lot on this aspect of > > resolver. But, due our own strict backward compatibility policy (see > > https://maven.apache.org/resolver/upgrading-resolver.html and > > https://maven.apache.org/resolver/api-compatibility.html for our > > promises) all these may not happen in Maven 4 (or 4.1+) as features > > may require some changes not being aligned with Maven 3/Resolver 1 > > APIs, while Maven 4 must remain compatible with Maven 3 (be able to > > run Maven 3 plugins). > > > > Thanks > > T > > > > > > > > > > > > On Wed, Feb 11, 2026 at 11:26 AM Tamás Cservenák <[email protected]> > > wrote: > > > > > > And one more thing, > > > there is also "stat" sink used by default on some toolbox mojos, for > > > example: > > > https://gist.github.com/cstamas/428ed903b000eb23fd0910be42141be0 > > > > > > Thanks > > > T > > > > > > On Wed, Feb 11, 2026 at 11:02 AM Tamás Cservenák <[email protected]> > > > wrote: > > > > > > > > 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]
