Re: MD5, SHA1, but nothing (still) safe?

[Michael Osipov]

Am 2021-10-21 um 19:11 schrieb Mykola Nikishov:

Mickael Istria  writes:


While I'm investigating into Maven code to allow re-using checksums of
Maven artifacts when "p2-ifying" them with Tycho, I noticed only .md5 and
.sha1 seems to be used by Wagon and then also noticed that Maven Central
doesn't contain a "safe" digest signature either.


[...]


Is there an issue already open to move towards sha256 or should I create a
new one?


Michael, as you know, Maven differs from Equinox's p2 approach to
resolve and download artifacts - in Maven world, closest match to what
p2 does would be a combination of Sonatype Nexus' Remote Index
(metadata) and repo.maven.apache.org (artifacts). So that Maven would
first download remote index (from an ultimately trusted source, which
provides additional information about available artifacts, including
checksums) and resolve list of dependencies to download based on that
information only. In a second step, it would download actual artifacts
using either the same repo.maven.apache.org or any other source. This
second step can then use less trusted sources (3rd-party mirrors).


Thanks, I wasn't really aware how p2 works.

How do you define a trusted source or establish trust?


This difference seems to me as root cause of the initial confusion with
your question. With this in mind, as was mentioned already, moving to
stronger checksums is not that important or useful for Maven.


You are talking about checksums now, but the title talks about 
cryptographic hashes. Those are two different things. If you need a 
strong checksum, use xxHash.



All discussion about more stronger checksums in p2 [1] was relevant only
because my goal was to enable support for peer-to-peer protocols (more
generally, any content-addressable storage AKA bittorrent, ipfs and
alike) alongside to location-addressable storage. And for this use case
support for extensible set of (cryptographically strong) checksum
algorightms is a must.


Hashes, not checksums.


[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=423715


I think this is deceiving becase this still says nothing about a trust 
without a key.



The sole purpose is Resolver of checksums is to detect bitrot 
(integrity). Authenticity is established with signatures, therefore 
everyone on Maven Central must sign each file. MD5 and SHA-1 where just 
there through MessageDigest, but I believe that it was a bad decision 
back then.


M

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: MD5, SHA1, but nothing (still) safe?

[Mykola Nikishov]

Mickael Istria  writes:

> While I'm investigating into Maven code to allow re-using checksums of
> Maven artifacts when "p2-ifying" them with Tycho, I noticed only .md5 and
> .sha1 seems to be used by Wagon and then also noticed that Maven Central
> doesn't contain a "safe" digest signature either.

[...]

> Is there an issue already open to move towards sha256 or should I create a
> new one?

Michael, as you know, Maven differs from Equinox's p2 approach to
resolve and download artifacts - in Maven world, closest match to what
p2 does would be a combination of Sonatype Nexus' Remote Index
(metadata) and repo.maven.apache.org (artifacts). So that Maven would
first download remote index (from an ultimately trusted source, which
provides additional information about available artifacts, including
checksums) and resolve list of dependencies to download based on that
information only. In a second step, it would download actual artifacts
using either the same repo.maven.apache.org or any other source. This
second step can then use less trusted sources (3rd-party mirrors).

This difference seems to me as root cause of the initial confusion with
your question. With this in mind, as was mentioned already, moving to
stronger checksums is not that important or useful for Maven.

All discussion about more stronger checksums in p2 [1] was relevant only
because my goal was to enable support for peer-to-peer protocols (more
generally, any content-addressable storage AKA bittorrent, ipfs and
alike) alongside to location-addressable storage. And for this use case
support for extensible set of (cryptographically strong) checksum
algorightms is a must.

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=423715

-- 
Mykola

Libre/Free Java Software Developer
https://manandbytes.gitlab.io/


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: MD5, SHA1, but nothing (still) safe?

[Bernd Eckenfels]

If you use trusted checksum catalogs, shoes, reference hashes or stuff this can 
be used for integrity protection (if the checksum catalogs are integrity 
protected), and for this you indeed have to use strong hashes. However this is 
not directly related to the maven artifact hash files and deployer. (You better 
not generate the trusted lists from the untrusted repository hash files).

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Mickael Istria 
Gesendet: Thursday, October 14, 2021 9:56:04 AM
An: Maven Developers List 
Betreff: Re: MD5, SHA1, but nothing (still) safe?

On Wed, Oct 13, 2021 at 8:41 PM Bernd Eckenfels 
wrote:

> There is no Security risk with weaker checksums since the checksums are
> not used for security. An attacker who messes with your binaries can also
> mess with the checksum files.


In our case, we have the checksum files that are served from a "trusted"
place, but the artifacts can come from less trusted mirrors. And we want to
ensure the artifact we get is the one we expect whichever server does serve
it. Checksums can do that, and broken checksums algorithms such as md5 or
sha1 can allow a mirror to forge a malicious artifact with the same
checksums and thus let a malicious artifact be installed in place of a good
one; while strong checksums algorithms don't allow that.


> Only the signatures are relevant here (and they depend on the PGP settings
> if they use strong hashes).
>

I disagree that from a security perspective signatures have any stronger
impact on securing the transfer than a good checksum. Signatures are here
to create a concept of "trust delegation" (I trust this artifact because X
has signed they trust it), it's basically meant for human decision, not for
automated artifact transfer verification.

And even the broken/short/fast md5 would be strong enough to detect bit
> errors, especially considering TLS is now mandatory.
>

See my point above; it's not only a bit error, it can be malicious
artifacts coming from another source (mirror) and pretending to be the
correct ones because md5 is weak enough to allow to do it.

Re: MD5, SHA1, but nothing (still) safe?

[Michael Osipov]

Am 2021-10-13 um 16:19 schrieb Mickael Istria:

On Wed, Oct 13, 2021 at 2:10 PM Michael Osipov  wrote:


Hi Mickael,



Hi Michael,



this is an overly complex topic I'd like to explain.
First of all Wagon is not involved in this. It does the physical
transport. The payload is opaque. SHA, MD5 aren't verifying any
signatures, it is just calculating a cryptographic hash. For signatures
we have GPG and it should be clear that those checksums are for bitrot
only. Checksums can be faked by anyone, signatures not.



Sorry for being confusing. I really mean checksums and verifying data
integrity in the transfer (bitrot).

A couple of months ago I have added SHA-2 to Maven Resolver, users

complained (see users@, Dan Tran) that the additional roundtrips (HTTP
requests) and calculation of checksums consume too much time. I had to
take this back.



I couldn't find this discussion; I probably miss something. Is it buried in
another thread? Ideally, do you think you could share a link?
I'm surprised about those extra HTTP requests and calculation of checksums
being a too big issue compared to the security risk.


See the vote (discussion) on Maven Resolver 1.6.0.


Maven Central first: Brian
Fox said that this is in investigation, but as you know yourself the
entire ecosystem needs to prepare itself for this.



OK thanks for the info.

As for the checksum algorithms: SHA-x, compared to other cryptographic

algorithms, performs horribly, SHA-2 worse than SHA-1. If you are
downloading thousands of artifacts this does matter, actually.



Sure, SHA-256 is more expansive, but now SHA-1 has been broken for some
time already and isn't worth much in term of security. Keeping reliance on
MD5 and SHA1 seems quite insecure.


For security, yes. But as said, we don't need security here. Just integrity.



Why do
we need a cryptographic hash at all? We don't for bitrot. It is a waste
of cycles.



What do you use for bitrot then? Unsecure algorithms?
p2 has mirror capabilities, one does fetch the p2 metadata from a trusted
location (eg https://download.eclipse.org) and this metadata contains the
artifacts with checksums, size and other info. This metadata can also
include a lit of mirrors to use in place of the main server; those mirrors
can use unsafe protocols or even be malicious themselves. Having checksums
in a trusted locations does prevent mirrors from injecting malicious
artifacts; and also allows to keep using "unsafe" protocols in a safer way.


Well, checksums don't create trust. If you are talking about trust you 
are back to signatures. Providing checksums upfront just tell you that 
there is no bitrot in-between which you want to avoid. You still cannot 
verify who provided this artifact with this.


We had a very extensive talk about this in our monthly Apéro and we only 
agreed that it is very hard to make signature checking right for the 
masses and it would only apply to Maven Central. What happens with in 
house repos: no idea.


You basically want:
* https://issues.apache.org/jira/browse/MRESOLVER-218
* https://issues.apache.org/jira/browse/MNG-6026
* https://issues.apache.org/jira/browse/MNG-5814

M


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: MD5, SHA1, but nothing (still) safe?

[Pavel Horal]

Hello,

i see two mixed topics in this discussion - verifying artifact transfer
integrity and verifying that the downloaded artifact is really the one
expected from the security perspective. The latter does not have anything
to do with Maven Central or any other repository. Checksums in repositories
(used by Wagon) can only be used for verifying transfer integrity.
Verifying artifact via secure checksum that is obtained from a trusted
source (e.g. local file like package-lock.json in NodeJS) and having some
sort of lock file in the project is a different topic that is for example
being addressed by checksum-maven-plugin. I think it would be awesome if
Maven itself can support this use case... I would love to be sure that a
specific JAR downloaded a year ago is exactly the same as JAR with the same
coordinates downloaded today.

Pavel

On Thu, 14 Oct 2021 at 10:47, Mickael Istria  wrote:

> On Thu, Oct 14, 2021 at 10:36 AM Romain Manni-Bucau  >
> wrote:
>
> > I agree with Bernd, checksums are there to validate the consistency of
> the
> > artifact, nothing linked to security.
> >
>
> Ensuring user gets a consistent artifact as desired -and not a malicious
> forged one- is 1 aspect of security.
>
> On central the security side is provided by the asc file which is
> > sufficient if you trust only allowed releasers keys in practise,
> pretending
> > you are a releaser will be quite hard so this is likely the best security
> > you can setup as of today and no checksum algorithm can make it stronger
> > (it is 1-1 in terms of security).
> >
>
> That is as far as I understand another aspect of security, which is more
> about authenticating provenance of the artifact when publishing it to the
> repo and verifying the author. I can be used as an alternative to checksums
> as well because the signature contains a form of hash, but -correct me if
> I'm wrong- if the only goal is to verify consistency, then signatures are
> overkill and will perform worse than checksum algorithms anyway.
>

Re: MD5, SHA1, but nothing (still) safe?

[Mickael Istria]

On Thu, Oct 14, 2021 at 10:36 AM Romain Manni-Bucau 
wrote:

> I agree with Bernd, checksums are there to validate the consistency of the
> artifact, nothing linked to security.
>

Ensuring user gets a consistent artifact as desired -and not a malicious
forged one- is 1 aspect of security.

On central the security side is provided by the asc file which is
> sufficient if you trust only allowed releasers keys in practise, pretending
> you are a releaser will be quite hard so this is likely the best security
> you can setup as of today and no checksum algorithm can make it stronger
> (it is 1-1 in terms of security).
>

That is as far as I understand another aspect of security, which is more
about authenticating provenance of the artifact when publishing it to the
repo and verifying the author. I can be used as an alternative to checksums
as well because the signature contains a form of hash, but -correct me if
I'm wrong- if the only goal is to verify consistency, then signatures are
overkill and will perform worse than checksum algorithms anyway.

Re: MD5, SHA1, but nothing (still) safe?

[Romain Manni-Bucau]

Hi,

I agree with Bernd, checksums are there to validate the consistency of the
artifact, nothing linked to security.
On central the security side is provided by the asc file which is
sufficient if you trust only allowed releasers keys in practise, pretending
you are a releaser will be quite hard so this is likely the best security
you can setup as of today and no checksum algorithm can make it stronger
(it is 1-1 in terms of security).

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 14 oct. 2021 à 09:56, Mickael Istria  a écrit :

> On Wed, Oct 13, 2021 at 8:41 PM Bernd Eckenfels 
> wrote:
>
> > There is no Security risk with weaker checksums since the checksums are
> > not used for security. An attacker who messes with your binaries can also
> > mess with the checksum files.
>
>
> In our case, we have the checksum files that are served from a "trusted"
> place, but the artifacts can come from less trusted mirrors. And we want to
> ensure the artifact we get is the one we expect whichever server does serve
> it. Checksums can do that, and broken checksums algorithms such as md5 or
> sha1 can allow a mirror to forge a malicious artifact with the same
> checksums and thus let a malicious artifact be installed in place of a good
> one; while strong checksums algorithms don't allow that.
>
>
> > Only the signatures are relevant here (and they depend on the PGP
> settings
> > if they use strong hashes).
> >
>
> I disagree that from a security perspective signatures have any stronger
> impact on securing the transfer than a good checksum. Signatures are here
> to create a concept of "trust delegation" (I trust this artifact because X
> has signed they trust it), it's basically meant for human decision, not for
> automated artifact transfer verification.
>
> And even the broken/short/fast md5 would be strong enough to detect bit
> > errors, especially considering TLS is now mandatory.
> >
>
> See my point above; it's not only a bit error, it can be malicious
> artifacts coming from another source (mirror) and pretending to be the
> correct ones because md5 is weak enough to allow to do it.
>

Re: MD5, SHA1, but nothing (still) safe?

[Mickael Istria]

On Wed, Oct 13, 2021 at 8:41 PM Bernd Eckenfels 
wrote:

> There is no Security risk with weaker checksums since the checksums are
> not used for security. An attacker who messes with your binaries can also
> mess with the checksum files.


In our case, we have the checksum files that are served from a "trusted"
place, but the artifacts can come from less trusted mirrors. And we want to
ensure the artifact we get is the one we expect whichever server does serve
it. Checksums can do that, and broken checksums algorithms such as md5 or
sha1 can allow a mirror to forge a malicious artifact with the same
checksums and thus let a malicious artifact be installed in place of a good
one; while strong checksums algorithms don't allow that.


> Only the signatures are relevant here (and they depend on the PGP settings
> if they use strong hashes).
>

I disagree that from a security perspective signatures have any stronger
impact on securing the transfer than a good checksum. Signatures are here
to create a concept of "trust delegation" (I trust this artifact because X
has signed they trust it), it's basically meant for human decision, not for
automated artifact transfer verification.

And even the broken/short/fast md5 would be strong enough to detect bit
> errors, especially considering TLS is now mandatory.
>

See my point above; it's not only a bit error, it can be malicious
artifacts coming from another source (mirror) and pretending to be the
correct ones because md5 is weak enough to allow to do it.

Re: MD5, SHA1, but nothing (still) safe?

[Bernd Eckenfels]

There is no Security risk with weaker checksums since the checksums are not 
used for security. An attacker who messes with your binaries can also mess with 
the checksum files. Only the signatures are relevant here (and they depend on 
the PGP settings if they use strong hashes).

And even the broken/short/fast md5 would be strong enough to detect bit errors, 
especially considering TLS is now mandatory.

Having said that, I guess the policy should come from maven central what’s 
required for new uploads.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Mickael Istria 
Gesendet: Wednesday, October 13, 2021 4:19:09 PM
An: Maven Developers List 
Betreff: Re: MD5, SHA1, but nothing (still) safe?

On Wed, Oct 13, 2021 at 2:10 PM Michael Osipov  wrote:

> Hi Mickael,
>

Hi Michael,

>
> this is an overly complex topic I'd like to explain.
> First of all Wagon is not involved in this. It does the physical
> transport. The payload is opaque. SHA, MD5 aren't verifying any
> signatures, it is just calculating a cryptographic hash. For signatures
> we have GPG and it should be clear that those checksums are for bitrot
> only. Checksums can be faked by anyone, signatures not.
>

Sorry for being confusing. I really mean checksums and verifying data
integrity in the transfer (bitrot).

A couple of months ago I have added SHA-2 to Maven Resolver, users
> complained (see users@, Dan Tran) that the additional roundtrips (HTTP
> requests) and calculation of checksums consume too much time. I had to
> take this back.


I couldn't find this discussion; I probably miss something. Is it buried in
another thread? Ideally, do you think you could share a link?
I'm surprised about those extra HTTP requests and calculation of checksums
being a too big issue compared to the security risk.


> Maven Central first: Brian
> Fox said that this is in investigation, but as you know yourself the
> entire ecosystem needs to prepare itself for this.
>

OK thanks for the info.

As for the checksum algorithms: SHA-x, compared to other cryptographic
> algorithms, performs horribly, SHA-2 worse than SHA-1. If you are
> downloading thousands of artifacts this does matter, actually.


Sure, SHA-256 is more expansive, but now SHA-1 has been broken for some
time already and isn't worth much in term of security. Keeping reliance on
MD5 and SHA1 seems quite insecure.


> Why do
> we need a cryptographic hash at all? We don't for bitrot. It is a waste
> of cycles.


What do you use for bitrot then? Unsecure algorithms?
p2 has mirror capabilities, one does fetch the p2 metadata from a trusted
location (eg https://download.eclipse.org) and this metadata contains the
artifacts with checksums, size and other info. This metadata can also
include a lit of mirrors to use in place of the main server; those mirrors
can use unsafe protocols or even be malicious themselves. Having checksums
in a trusted locations does prevent mirrors from injecting malicious
artifacts; and also allows to keep using "unsafe" protocols in a safer way.


> Also keep in mind when this stuff has been designed, when HTTP was used
> throughout. TLS hash hashing builtin. I think the previous bitrot case
> should be much much rarer.


As mentioned above, things like mirroring make it still very relevant.

Re: MD5, SHA1, but nothing (still) safe?

[Mickael Istria]

On Wed, Oct 13, 2021 at 2:10 PM Michael Osipov  wrote:

> Hi Mickael,
>

Hi Michael,

>
> this is an overly complex topic I'd like to explain.
> First of all Wagon is not involved in this. It does the physical
> transport. The payload is opaque. SHA, MD5 aren't verifying any
> signatures, it is just calculating a cryptographic hash. For signatures
> we have GPG and it should be clear that those checksums are for bitrot
> only. Checksums can be faked by anyone, signatures not.
>

Sorry for being confusing. I really mean checksums and verifying data
integrity in the transfer (bitrot).

A couple of months ago I have added SHA-2 to Maven Resolver, users
> complained (see users@, Dan Tran) that the additional roundtrips (HTTP
> requests) and calculation of checksums consume too much time. I had to
> take this back.


I couldn't find this discussion; I probably miss something. Is it buried in
another thread? Ideally, do you think you could share a link?
I'm surprised about those extra HTTP requests and calculation of checksums
being a too big issue compared to the security risk.


> Maven Central first: Brian
> Fox said that this is in investigation, but as you know yourself the
> entire ecosystem needs to prepare itself for this.
>

OK thanks for the info.

As for the checksum algorithms: SHA-x, compared to other cryptographic
> algorithms, performs horribly, SHA-2 worse than SHA-1. If you are
> downloading thousands of artifacts this does matter, actually.


Sure, SHA-256 is more expansive, but now SHA-1 has been broken for some
time already and isn't worth much in term of security. Keeping reliance on
MD5 and SHA1 seems quite insecure.


> Why do
> we need a cryptographic hash at all? We don't for bitrot. It is a waste
> of cycles.


What do you use for bitrot then? Unsecure algorithms?
p2 has mirror capabilities, one does fetch the p2 metadata from a trusted
location (eg https://download.eclipse.org) and this metadata contains the
artifacts with checksums, size and other info. This metadata can also
include a lit of mirrors to use in place of the main server; those mirrors
can use unsafe protocols or even be malicious themselves. Having checksums
in a trusted locations does prevent mirrors from injecting malicious
artifacts; and also allows to keep using "unsafe" protocols in a safer way.


> Also keep in mind when this stuff has been designed, when HTTP was used
> throughout. TLS hash hashing builtin. I think the previous bitrot case
> should be much much rarer.


As mentioned above, things like mirroring make it still very relevant.

Re: MD5, SHA1, but nothing (still) safe?

[Michael Osipov]

Am 2021-10-13 um 12:10 schrieb Mickael Istria:

Hi all,

While I'm investigating into Maven code to allow re-using checksums of
Maven artifacts when "p2-ifying" them with Tycho, I noticed only .md5 and
.sha1 seems to be used by Wagon and then also noticed that Maven Central
doesn't contain a "safe" digest signature either.
In this world of supply chain attacks, it could be important to use
stronger algorithms.
Sure, there is PGP signature, but PGP is not intended to verify the
transfer, it's more meant to allow delegating a trust decision from the
artifact to the signer; using it to verify transfer seems overkill, so we'd
rather avoid having to rely on it for transfer verification.
I tried to look on Jira and couldn't see an issue that seems dedicated to
this topic. As the concerns about md5 and sha1 are relatively old, I may
have missed something.
Is there an issue already open to move towards sha256 or should I create a
new one?


Hi Mickael,

this is an overly complex topic I'd like to explain.
First of all Wagon is not involved in this. It does the physical 
transport. The payload is opaque. SHA, MD5 aren't verifying any 
signatures, it is just calculating a cryptographic hash. For signatures 
we have GPG and it should be clear that those checksums are for bitrot 
only. Checksums can be faked by anyone, signatures not.
A couple of months ago I have added SHA-2 to Maven Resolver, users 
complained (see users@, Dan Tran) that the additional roundtrips (HTTP 
requests) and calculation of checksums consume too much time. I had to 
take this back. Then I started to investigate about checksum algorithms 
in general and its usage in Maven Central. Maven Central first: Brian 
Fox said that this is in investigation, but as you know yourself the 
entire ecosystem needs to prepare itself for this. We are talking about 
millions of consumers. A hard nut to crack.
As for the checksum algorithms: SHA-x, compared to other cryptographic 
algorithms, performs horribly, SHA-2 worse than SHA-1. If you are 
downloading thousands of artifacts this does matter, actually. Even 
Blake2/Blake3 do a much better job than SHA-x. Another question: Why do 
we need a cryptographic hash at all? We don't for bitrot. It is a waste 
of cycles. Looking at MurmurHash or xxHash makes SHA-2 just look ridiculous.


My personal opinion: Unless Oracle/OpenJDK adds non-crypto hash algos to 
MessageDigest SPI the overhead of SHA-2 might neutralize its benefit. 
Also keep in mind when this stuff has been designed, when HTTP was used 
throughout. TLS hash hashing builtin. I think the previous bitrot case 
should be much much rarer.


Michael

PS: I am not a security expect, just sharing my findings in this context.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: MD5, SHA1, but nothing (still) safe?

[Delany]

Might be helpful:
https://checksum-maven-plugin.nicoulaj.net/examples/using-custom-checksum-algorithms.html
Delany

On Wed, 13 Oct 2021 at 12:10, Mickael Istria  wrote:

> Hi all,
>
> While I'm investigating into Maven code to allow re-using checksums of
> Maven artifacts when "p2-ifying" them with Tycho, I noticed only .md5 and
> .sha1 seems to be used by Wagon and then also noticed that Maven Central
> doesn't contain a "safe" digest signature either.
> In this world of supply chain attacks, it could be important to use
> stronger algorithms.
> Sure, there is PGP signature, but PGP is not intended to verify the
> transfer, it's more meant to allow delegating a trust decision from the
> artifact to the signer; using it to verify transfer seems overkill, so we'd
> rather avoid having to rely on it for transfer verification.
> I tried to look on Jira and couldn't see an issue that seems dedicated to
> this topic. As the concerns about md5 and sha1 are relatively old, I may
> have missed something.
> Is there an issue already open to move towards sha256 or should I create a
> new one?
>
> Thanks in advance
>
> --
> Mickael Istria
> Eclipse IDE  developer, for Red Hat
> Developers 
>

MD5, SHA1, but nothing (still) safe?

[Mickael Istria]

Hi all,

While I'm investigating into Maven code to allow re-using checksums of
Maven artifacts when "p2-ifying" them with Tycho, I noticed only .md5 and
.sha1 seems to be used by Wagon and then also noticed that Maven Central
doesn't contain a "safe" digest signature either.
In this world of supply chain attacks, it could be important to use
stronger algorithms.
Sure, there is PGP signature, but PGP is not intended to verify the
transfer, it's more meant to allow delegating a trust decision from the
artifact to the signer; using it to verify transfer seems overkill, so we'd
rather avoid having to rely on it for transfer verification.
I tried to look on Jira and couldn't see an issue that seems dedicated to
this topic. As the concerns about md5 and sha1 are relatively old, I may
have missed something.
Is there an issue already open to move towards sha256 or should I create a
new one?

Thanks in advance

-- 
Mickael Istria
Eclipse IDE  developer, for Red Hat
Developers