Excellent news on the trusted checksums feature! As this appears to be
provided by Maven itself (in 3.9 onward?), is this the recommended way for
teams to version Maven checksums in git? If so, is more documentation
planned/needed?
Perhaps what is missing in maven-dependency-plugin is machine-read
And one more thing:
On a related note (globally, not TC related directly), in Maven 4
(Resolver 2) we have much greater control over connectors, see
https://github.com/apache/maven-resolver/issues/1361
And as the issue shows, "signature checking" connector is about to
arrive soon(ish).
And this a
Howdy,
Yes, sadly we (project) are very bad at "advertising" and "properly
documenting" things. Sorry about that.
Trusted checksums is in fact SPI and one can plug in various sources
(while resolver contains some "basic" implementations). This is a very
similar setup as with Remote Repository Fi
On 7/11/25 7:26 AM, Calum Harrison wrote:
"Trusted Checksums" is good to know about -- I had missed that.
It's very easy to miss!
I came across it accidentally myself rather recently. I was
participating in this issue:
[MNG-6026] Extend the Project Object Model (POM) with trust information
cd2
>
> 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
case 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, J
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 re
V (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 wou
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
ncy: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
ted by maven-resolver, which supports SHA-512 since
>> version 1.5.0 ( https://issues.apache.org/jira/browse/MRESOLVER-56 ).
>> If I remember correctly maven-resolver 1.5+ is included since Maven 3.8.1.
>> So you would have to update your Maven to 3.8.1 and `
>> -Daether.ch
Thank you, for the generous response.
The file hashes are created by maven-resolver, which supports SHA-512 since
> version 1.5.0 ( https://issues.apache.org/jira/browse/MRESOLVER-56 ).
> If I remember correctly maven-resolver 1.5+ is included since Maven 3.8.1.
> So you would have to up
Am 2021-05-26 um 09:14 schrieb Janardhan:
Hi Maven team,
TL;DR: Can we sign (SHA-512) artifacts with gpg plugin and how?. Thanks.
This is not signing, this is just a checksum for transport bitrot.
If you need SHA-2 hashes use Resolver's new property for
Hi Janardhan,
The maven-gpg-plugin is only responsible for creating the "asc" files which
contain the PGP signature.
The file hashes are created by maven-resolver, which supports SHA-512 since
version 1.5.0 ( https://issues.apache.org/jira/browse/MRESOLVER-56 ).
If I remember corre
Hi Maven team,
TL;DR: Can we sign (SHA-512) artifacts with gpg plugin and how?. Thanks.
1. We are trying to sign Apache SystemDS[0] release artifacts with
gpg-plugin,
we are only receiving the `.md5` and `.sha1` without the
`-Daether.checksums.algorithms=SHA-512` flag as per [1][4].
2. With
Brian Fox wrote:
Oleg Gusakov wrote:
fyi:
- maven password encryption uses SHA-256 and switching to SHA-512
could be done using optional encrypted string attributes to ensure
decryption of the existing passwords. SHA-256 is already SHA2 family
and has not been cracked yet, so we can
Oleg Gusakov wrote:
fyi:
- maven password encryption uses SHA-256 and switching to SHA-512
could be done using optional encrypted string attributes to ensure
decryption of the existing passwords. SHA-256 is already SHA2 family
and has not been cracked yet, so we can wait. Main question was
fyi:
- maven password encryption uses SHA-256 and switching to SHA-512 could
be done using optional encrypted string attributes to ensure decryption
of the existing passwords. SHA-256 is already SHA2 family and has not
been cracked yet, so we can wait. Main question was availability of
SHA
On Wed, May 6, 2009 at 7:27 AM, Brett Porter wrote:
> For artifact checksums? They are not a security measure, so I don't think
> increasing their length is of benefit.
>
> Having read the same mail I'm guessing you did, it made me reflect and we
> probably should have kept using md5 for efficienc
For artifact checksums? They are not a security measure, so I don't
think increasing their length is of benefit.
Having read the same mail I'm guessing you did, it made me reflect and
we probably should have kept using md5 for efficiency TBH.
Cheers,
Brett
On 06/05/2009, at 4:11 PM, Robert
just a heads up that maven may need to switch from SHA1 to SHA512 (or
higher). not sure how difficult that will be.
- robert
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@mav
21 matches
Mail list logo
