commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [eclipse-dev] Notice that Eclipse Platform plans to no longer provide MD5 and SHA1 checksums for Neon (but still SHA512)
Date Tue, 10 May 2016 20:02:28 GMT

Fully agree for checksum files no stronger hashes are needed. For the pgp signatures we should
however avoid md5/sha1. The advantage isnthat this is pretty transparent (alg encoded in .asc
file). It only breaks for some very old invoked pgp binaries. (Theoretically we can add multiple
signatures using sha1+sha2 but that might break even more pgp implementations anf the maven/gnupg-plugin
does not support it afaik).


-----Original Message-----
From: sebb <>
To: Commons Developers List <>
Sent: Di., 10 Mai 2016 11:53
Subject: Re: [eclipse-dev] Notice that Eclipse Platform plans to no longer provide MD5 and
SHA1 checksums for Neon (but still SHA512)

Why bother changing?

Checksums/hashes are only intended for checking that a download has
completed OK.

They don't provide any authentication as anyone can generate them.
AFAICT the strength of the hash has no bearing on its utility.

People should use the sigs instead.

Switching to a stronger hash might give the impression that the hash
is intended for authentication.

Note that any change ought to be run past Infra, because the release
distribution policy might need to be updated.

On 10 May 2016 at 10:30, Benedikt Ritter <> wrote:
> Hi Gary,
> What changes are required for this? Is this just a setting in
> commons-parent?
> Benedikt
> Gary Gregory <> schrieb am Di., 10. Mai 2016 um
> 02:51 Uhr:
>> Should we follow suit?
>> Gary
>> ---------- Forwarded message ----------
>> From: David M Williams <>
>> Date: Mon, May 9, 2016 at 5:37 PM
>> Subject: [eclipse-dev] Notice that Eclipse Platform plans to no longer
>> provide MD5 and SHA1 checksums for Neon (but still SHA512)
>> To:,,
>> The topic of this note is about the downloads and checksums obtained
>> directly from the the Eclipse Project. It does not involve the checksums
>> from the "select a mirror" page -- that is controlled by the Eclipse
>> Foundation -- nor any of the packages downloaded from
>> also controlled by the Eclipse
>> Foundation.  My intuition is that few "casual users" use our checksums but
>> some adopters or committers might use them in automated scripts or builds.
>> If any of you do get checksums directly from
>> .../eclipse/downloads/drops4/<buildid>/checksum/... then this note is for
>> you.
>> We announced in Luna we would "stop producing MD5 and SHA1 checksums" after
>> Luna's release (*Bug 423714*
>> <>)... and I am just
>> now getting around to it. Since it has been a long time since that
>> announcement, and since we are late in this cycle, I am cross-posting to 3
>> lists to be sure those that might be impacted will be notified.
>> We will continue to provide SHA512 checksums and I recently decided to also
>> provide SHA256 checksums since SHA256 seems to be popular "in the
>> industry".
>> This RC1 effort is documented in *Bug 454784*
>> <>. If the removal of
>> the MD5 and SHA1 checksums would unduly burden anyone, please say so in
>> that *Bug 454784* <>
>> and
>> we would be happy to accommodate.
>> I will soon be updating our wiki on *How to verify a download*
>> <
>> >
>> to contain accurate information for Neon, but wanted to get this notice out
>> now so if you are negatively impacted you would have time to say so.
>> Thank you,
>> _______________________________________________
>> eclipse-dev mailing list
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> --
>> E-Mail: |
>> Java Persistence with Hibernate, Second Edition
>> <>
>> JUnit in Action, Second Edition <>
>> Spring Batch in Action <>
>> Blog:
>> Home:
>> Tweet!

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message