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
