Hi, You are all fundamentally correct:
Just printing the checksums is of course insufficient. For large projects, it would just be noise. The aim would be for the hashes to be consumed by downstream systems. `maven-dependency-plugin` seemed to me one of the more natural places to provide this functionality. That said, yes -- `dependency:tree` and `dependency:list` would probably not be the correct home as they do not resolve the artifacts -- just the project files. Although I believe `dependency:resolve` (as you'd expect) does -- so resolving the artifacts is not outside the scope of `maven-dependency-plugin`. Indeed, proof of provenance is what I really want -- but that's a significantly larger piece of work. In the shorter term tooling to report the hashes for resolved artifacts seems a suitable starting point for other tooling to then build on top of. "Trusted Checksums" is good to know about -- I had missed that. Thanks Calum On Fri, Jul 11, 2025 at 1:12 PM Tamás Cservenák <ta...@cservenak.net> wrote: > Howdy, > > The proposal is kinda wrong, for starters as dependency:tree collects > dependencies but does not resolve them. > Without resolution, the artifacts in question may not be even present > on disk, so what gives? > > But, as a counter "proposal", I toyed with the Toolbox project, which > already was able to do something like that. > > Note: make sure you use version 0.11.5 or newer of Toolbox. > > Toolbox already had the mojo `toolbox:resolve-transitive` that already > did this: it resolved current project dependencies and transitive > ones. > This mojo follows the generic abstraction of artifactSource (project > dependencies, in this case) => artifactSink (ingests them). > > The mojo by default uses `null()` sink (so nothing happens with > resolved artifacts) but also wraps it with `stats(true)` sink as well. > This "stat" sink was emitting JPMS info only so far (and sizes etc), > and is not improved to emit checksums as well (currently SHA1 and > SHA512, but could be easily made configurable as well). > > For test take Toolbox project itself: > https://github.com/maveniverse/toolbox > > Here is an example of tree and resolve-transitive with new info: > > Tree > https://gist.github.com/cstamas/c42107f72c08bd2abff0ed33a7de5cd2 > > The stat > https://gist.github.com/cstamas/ca5e0545b41618f860c7a0974313c7e9 > > The stats _inspects the artifact file_, so these checksums are _always > calculated against the resolved file_, and does not rely on repository > metadata. > > Note: this change was done only to showcase the versatility of > Toolbox, and as I said, checksums are currently fixed (always > defaulted to SHA-1 and SHA-512), but a simple change can make that > configurable, and all Resolver supported checksum is supported, see > https://maven.apache.org/resolver/about-checksums.html > > Thanks > T > > On Fri, Jul 11, 2025 at 10:08 AM Slawomir Jaranowski > <s.jaranow...@gmail.com> wrote: > > > > Hi, > > > > There is a "Trusted Checksums" > > https://maven.apache.org/resolver/expected-checksums.html > > > > We can store / record checksums in the project file and use it next time. > > > > Here is a demo project with "Trusted Checksums" > > https://github.com/cstamas/tc-demo > > > > > > > > > > On Fri, 11 Jul 2025 at 00:55, Elliotte Rusty Harold <elh...@ibiblio.org> > wrote: > > > > > > Personal opinion only: displaying checksums, even optionally, is > > > unlikely to be helpful. No one pays attention to these or verifies > > > them. Recently I actually went to the trouble of verifying the > > > checksums for a major Apache project and discovered the KEYS file was > > > borked. No one had noticed for years. Checksums need to be verified > > > automatically. Adding code to support manual verification is security > > > theater and a waste of time. > > > > > > > > > > > > On Thu, Jul 10, 2025 at 6:18 PM Calum Harrison > > > <calum.harri...@snyk.io.invalid> wrote: > > > > > > > > Hi dev list, > > > > > > > > I'd like to propose a small enhancement to the > maven-dependency-plugin. > > > > From a Software Composition Analysis (SCA) and security perspective, > it's > > > > crucial to verify the exact artifact that has been resolved during a > build. > > > > Private or third-party repositories may provide artifacts that have > been > > > > patched or altered but retain the same GAV (GroupId, ArtifactId, > Version) > > > > coordinates. This makes identifying the specific artifact provenance > a > > > > challenge. > > > > > > > > Would the team consider adding an optional flag (e.g., > -DshowChecksums) to > > > > commands like dependency:tree and dependency:list that would display > the > > > > SHA-1 hash of the resolved artifact? > > > > This would provide a simple, standardized way to verify artifact > integrity > > > > without relying on third-party plugins, which are often restricted in > > > > corporate environments. > > > > > > > > Is this functionality something that would be within the scope of the > > > > maven-dependency-plugin, or would it be better suited for another > plugin or > > > > Maven core itself? > > > > > > > > Thanks, > > > > Calum > > > > > > > > > > > > -- > > > Elliotte Rusty Harold > > > elh...@ibiblio.org > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > -- > > Sławomir Jaranowski > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
