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]
