You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Gregory <ga...@gmail.com> on 2016/05/10 00:51:45 UTC
Fwd: [eclipse-dev] Notice that Eclipse Platform plans to no longer
provide MD5 and SHA1 checksums for Neon (but still SHA512)
Should we follow suit?
Gary
---------- Forwarded message ----------
From: David M Williams <da...@us.ibm.com>
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: eclipse-dev@eclipse.org, equinox-dev@eclipse.org,
cross-project-issues-dev@eclipse.org
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
http://www.eclipse.org/downloads-- 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*
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=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*
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=454784>. If the removal of
the MD5 and SHA1 checksums would unduly burden anyone, please say so in
that *Bug 454784* <https://bugs.eclipse.org/bugs/show_bug.cgi?id=454784> and
we would be happy to accommodate.
I will soon be updating our wiki on *How to verify a download*
<http://wiki.eclipse.org/Platform-releng/How_to_check_integrity_of_downloads>
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
eclipse-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [eclipse-dev] Notice that Eclipse Platform plans to no longer
provide MD5 and SHA1 checksums for Neon (but still SHA512)
Posted by Christopher <ct...@apache.org>.
I filed MPOM-118 so maybe we can have this ASF-wide.
I wouldn't even know how to make gpg generate multiple signatures with
different algorithms from the command-line, so yeah, setting this option
would just do SHA512 for the algorithm used in the signature. The separate
non-GPG hashes (.md5, .sha1) are generated by an entirely different part of
Maven, AFAIK.
On Wed, May 11, 2016 at 11:58 AM Gary Gregory <ga...@gmail.com>
wrote:
> and for KISS, can we make it generate only SHA512 (not MD5, not SHA1)?
>
> Gary
>
> On Wed, May 11, 2016 at 8:03 AM, Christopher <ct...@apache.org> wrote:
>
> > maven-gpg-plugin simply does a pass-through to the underlying gpg
> > command-line, with something like the following options:
> > gpg -a --detach-sign filename
> >
> > So, it's normally using whatever the user's personal settings are for the
> > digest algorithm. Hopefully that's the best available (SHA512), but it
> > depends on their configuration.
> >
> > You could add something like:
> >
> > <gpgArguments>
> > <arg>--digest-algo=SHA512</arg>
> > </gpgArguments>
> >
> >
> > That way, you don't have to rely on individual user settings, and you can
> > be assured you're signatures are good. Of course, that won't prevent
> users
> > from using weak private keys.
> >
> > I'm actually going to open an issue against MPOM to suggest adding this
> the
> > ASF Parent POM.
> >
> > On Tue, May 10, 2016 at 4:02 PM <ec...@zusammenkunft.net> wrote:
> >
> > > Hello,
> > >
> > > 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).
> > >
> > > Gruss
> > > Bernd
> > > --
> > > http://bernd.eckenfels.net
> > >
> > > -----Original Message-----
> > > From: sebb <se...@gmail.com>
> > > To: Commons Developers List <de...@commons.apache.org>
> > > 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 <br...@apache.org> wrote:
> > > > Hi Gary,
> > > >
> > > > What changes are required for this? Is this just a setting in
> > > > commons-parent?
> > > >
> > > > Benedikt
> > > >
> > > > Gary Gregory <ga...@gmail.com> schrieb am Di., 10. Mai 2016
> um
> > > > 02:51 Uhr:
> > > >
> > > >> Should we follow suit?
> > > >>
> > > >> Gary
> > > >>
> > > >> ---------- Forwarded message ----------
> > > >> From: David M Williams <da...@us.ibm.com>
> > > >> 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: eclipse-dev@eclipse.org, equinox-dev@eclipse.org,
> > > >> cross-project-issues-dev@eclipse.org
> > > >>
> > > >>
> > > >> 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
> > > >> http://www.eclipse.org/downloads-- 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*
> > > >> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=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*
> > > >> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=454784>. If the
> > removal
> > > of
> > > >> the MD5 and SHA1 checksums would unduly burden anyone, please say so
> > in
> > > >> that *Bug 454784* <
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=454784
> > > >
> > > >> and
> > > >> we would be happy to accommodate.
> > > >>
> > > >> I will soon be updating our wiki on *How to verify a download*
> > > >> <
> > > >>
> > >
> >
> http://wiki.eclipse.org/Platform-releng/How_to_check_integrity_of_downloads
> > > >> >
> > > >> 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
> > > >> eclipse-dev@eclipse.org
> > > >> To change your delivery options, retrieve your password, or
> > unsubscribe
> > > >> from this list, visit
> > > >> https://dev.eclipse.org/mailman/listinfo/eclipse-dev
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > > >> Java Persistence with Hibernate, Second Edition
> > > >> <http://www.manning.com/bauer3/>
> > > >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > > >> Spring Batch in Action <http://www.manning.com/templier/>
> > > >> Blog: http://garygregory.wordpress.com
> > > >> Home: http://garygregory.com/
> > > >> Tweet! http://twitter.com/GaryGregory
> > > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
Re: [eclipse-dev] Notice that Eclipse Platform plans to no longer
provide MD5 and SHA1 checksums for Neon (but still SHA512)
Posted by Gary Gregory <ga...@gmail.com>.
and for KISS, can we make it generate only SHA512 (not MD5, not SHA1)?
Gary
On Wed, May 11, 2016 at 8:03 AM, Christopher <ct...@apache.org> wrote:
> maven-gpg-plugin simply does a pass-through to the underlying gpg
> command-line, with something like the following options:
> gpg -a --detach-sign filename
>
> So, it's normally using whatever the user's personal settings are for the
> digest algorithm. Hopefully that's the best available (SHA512), but it
> depends on their configuration.
>
> You could add something like:
>
> <gpgArguments>
> <arg>--digest-algo=SHA512</arg>
> </gpgArguments>
>
>
> That way, you don't have to rely on individual user settings, and you can
> be assured you're signatures are good. Of course, that won't prevent users
> from using weak private keys.
>
> I'm actually going to open an issue against MPOM to suggest adding this the
> ASF Parent POM.
>
> On Tue, May 10, 2016 at 4:02 PM <ec...@zusammenkunft.net> wrote:
>
> > Hello,
> >
> > 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).
> >
> > Gruss
> > Bernd
> > --
> > http://bernd.eckenfels.net
> >
> > -----Original Message-----
> > From: sebb <se...@gmail.com>
> > To: Commons Developers List <de...@commons.apache.org>
> > 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 <br...@apache.org> wrote:
> > > Hi Gary,
> > >
> > > What changes are required for this? Is this just a setting in
> > > commons-parent?
> > >
> > > Benedikt
> > >
> > > Gary Gregory <ga...@gmail.com> schrieb am Di., 10. Mai 2016 um
> > > 02:51 Uhr:
> > >
> > >> Should we follow suit?
> > >>
> > >> Gary
> > >>
> > >> ---------- Forwarded message ----------
> > >> From: David M Williams <da...@us.ibm.com>
> > >> 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: eclipse-dev@eclipse.org, equinox-dev@eclipse.org,
> > >> cross-project-issues-dev@eclipse.org
> > >>
> > >>
> > >> 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
> > >> http://www.eclipse.org/downloads-- 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*
> > >> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=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*
> > >> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=454784>. If the
> removal
> > of
> > >> the MD5 and SHA1 checksums would unduly burden anyone, please say so
> in
> > >> that *Bug 454784* <
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=454784
> > >
> > >> and
> > >> we would be happy to accommodate.
> > >>
> > >> I will soon be updating our wiki on *How to verify a download*
> > >> <
> > >>
> >
> http://wiki.eclipse.org/Platform-releng/How_to_check_integrity_of_downloads
> > >> >
> > >> 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
> > >> eclipse-dev@eclipse.org
> > >> To change your delivery options, retrieve your password, or
> unsubscribe
> > >> from this list, visit
> > >> https://dev.eclipse.org/mailman/listinfo/eclipse-dev
> > >>
> > >>
> > >>
> > >> --
> > >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > >> Java Persistence with Hibernate, Second Edition
> > >> <http://www.manning.com/bauer3/>
> > >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > >> Spring Batch in Action <http://www.manning.com/templier/>
> > >> Blog: http://garygregory.wordpress.com
> > >> Home: http://garygregory.com/
> > >> Tweet! http://twitter.com/GaryGregory
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [eclipse-dev] Notice that Eclipse Platform plans to no longer
provide MD5 and SHA1 checksums for Neon (but still SHA512)
Posted by Christopher <ct...@apache.org>.
maven-gpg-plugin simply does a pass-through to the underlying gpg
command-line, with something like the following options:
gpg -a --detach-sign filename
So, it's normally using whatever the user's personal settings are for the
digest algorithm. Hopefully that's the best available (SHA512), but it
depends on their configuration.
You could add something like:
<gpgArguments>
<arg>--digest-algo=SHA512</arg>
</gpgArguments>
That way, you don't have to rely on individual user settings, and you can
be assured you're signatures are good. Of course, that won't prevent users
from using weak private keys.
I'm actually going to open an issue against MPOM to suggest adding this the
ASF Parent POM.
On Tue, May 10, 2016 at 4:02 PM <ec...@zusammenkunft.net> wrote:
> Hello,
>
> 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).
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
>
> -----Original Message-----
> From: sebb <se...@gmail.com>
> To: Commons Developers List <de...@commons.apache.org>
> 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 <br...@apache.org> wrote:
> > Hi Gary,
> >
> > What changes are required for this? Is this just a setting in
> > commons-parent?
> >
> > Benedikt
> >
> > Gary Gregory <ga...@gmail.com> schrieb am Di., 10. Mai 2016 um
> > 02:51 Uhr:
> >
> >> Should we follow suit?
> >>
> >> Gary
> >>
> >> ---------- Forwarded message ----------
> >> From: David M Williams <da...@us.ibm.com>
> >> 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: eclipse-dev@eclipse.org, equinox-dev@eclipse.org,
> >> cross-project-issues-dev@eclipse.org
> >>
> >>
> >> 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
> >> http://www.eclipse.org/downloads-- 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*
> >> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=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*
> >> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=454784>. If the removal
> of
> >> the MD5 and SHA1 checksums would unduly burden anyone, please say so in
> >> that *Bug 454784* <https://bugs.eclipse.org/bugs/show_bug.cgi?id=454784
> >
> >> and
> >> we would be happy to accommodate.
> >>
> >> I will soon be updating our wiki on *How to verify a download*
> >> <
> >>
> http://wiki.eclipse.org/Platform-releng/How_to_check_integrity_of_downloads
> >> >
> >> 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
> >> eclipse-dev@eclipse.org
> >> To change your delivery options, retrieve your password, or unsubscribe
> >> from this list, visit
> >> https://dev.eclipse.org/mailman/listinfo/eclipse-dev
> >>
> >>
> >>
> >> --
> >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> Java Persistence with Hibernate, Second Edition
> >> <http://www.manning.com/bauer3/>
> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> >> Spring Batch in Action <http://www.manning.com/templier/>
> >> Blog: http://garygregory.wordpress.com
> >> Home: http://garygregory.com/
> >> Tweet! http://twitter.com/GaryGregory
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [eclipse-dev] Notice that Eclipse Platform plans to no longer
provide MD5 and SHA1 checksums for Neon (but still SHA512)
Posted by ec...@zusammenkunft.net.
Hello,
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).
Gruss
Bernd
--
http://bernd.eckenfels.net
-----Original Message-----
From: sebb <se...@gmail.com>
To: Commons Developers List <de...@commons.apache.org>
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 <br...@apache.org> wrote:
> Hi Gary,
>
> What changes are required for this? Is this just a setting in
> commons-parent?
>
> Benedikt
>
> Gary Gregory <ga...@gmail.com> schrieb am Di., 10. Mai 2016 um
> 02:51 Uhr:
>
>> Should we follow suit?
>>
>> Gary
>>
>> ---------- Forwarded message ----------
>> From: David M Williams <da...@us.ibm.com>
>> 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: eclipse-dev@eclipse.org, equinox-dev@eclipse.org,
>> cross-project-issues-dev@eclipse.org
>>
>>
>> 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
>> http://www.eclipse.org/downloads-- 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*
>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=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*
>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=454784>. If the removal of
>> the MD5 and SHA1 checksums would unduly burden anyone, please say so in
>> that *Bug 454784* <https://bugs.eclipse.org/bugs/show_bug.cgi?id=454784>
>> and
>> we would be happy to accommodate.
>>
>> I will soon be updating our wiki on *How to verify a download*
>> <
>> http://wiki.eclipse.org/Platform-releng/How_to_check_integrity_of_downloads
>> >
>> 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
>> eclipse-dev@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/eclipse-dev
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [eclipse-dev] Notice that Eclipse Platform plans to no longer
provide MD5 and SHA1 checksums for Neon (but still SHA512)
Posted by sebb <se...@gmail.com>.
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 <br...@apache.org> wrote:
> Hi Gary,
>
> What changes are required for this? Is this just a setting in
> commons-parent?
>
> Benedikt
>
> Gary Gregory <ga...@gmail.com> schrieb am Di., 10. Mai 2016 um
> 02:51 Uhr:
>
>> Should we follow suit?
>>
>> Gary
>>
>> ---------- Forwarded message ----------
>> From: David M Williams <da...@us.ibm.com>
>> 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: eclipse-dev@eclipse.org, equinox-dev@eclipse.org,
>> cross-project-issues-dev@eclipse.org
>>
>>
>> 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
>> http://www.eclipse.org/downloads-- 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*
>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=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*
>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=454784>. If the removal of
>> the MD5 and SHA1 checksums would unduly burden anyone, please say so in
>> that *Bug 454784* <https://bugs.eclipse.org/bugs/show_bug.cgi?id=454784>
>> and
>> we would be happy to accommodate.
>>
>> I will soon be updating our wiki on *How to verify a download*
>> <
>> http://wiki.eclipse.org/Platform-releng/How_to_check_integrity_of_downloads
>> >
>> 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
>> eclipse-dev@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/eclipse-dev
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [eclipse-dev] Notice that Eclipse Platform plans to no longer
provide MD5 and SHA1 checksums for Neon (but still SHA512)
Posted by Matt Sicker <bo...@gmail.com>.
As long as all the required PGP keys are in the KEYS file, falling back to
only .asc signatures would be ok with me. However, if the required public
keys are missing from KEYS, that makes it very hard to automate
verification of artifacts.
On 10 May 2016 at 05:42, Gary Gregory <ga...@gmail.com> wrote:
> I've not looked into it...
> On May 10, 2016 2:30 AM, "Benedikt Ritter" <br...@apache.org> wrote:
>
> > Hi Gary,
> >
> > What changes are required for this? Is this just a setting in
> > commons-parent?
> >
> > Benedikt
> >
> > Gary Gregory <ga...@gmail.com> schrieb am Di., 10. Mai 2016 um
> > 02:51 Uhr:
> >
> > > Should we follow suit?
> > >
> > > Gary
> > >
> > > ---------- Forwarded message ----------
> > > From: David M Williams <da...@us.ibm.com>
> > > 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: eclipse-dev@eclipse.org, equinox-dev@eclipse.org,
> > > cross-project-issues-dev@eclipse.org
> > >
> > >
> > > 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
> > > http://www.eclipse.org/downloads-- 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*
> > > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=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*
> > > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=454784>. If the removal
> > of
> > > the MD5 and SHA1 checksums would unduly burden anyone, please say so in
> > > that *Bug 454784* <
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=454784>
> > > and
> > > we would be happy to accommodate.
> > >
> > > I will soon be updating our wiki on *How to verify a download*
> > > <
> > >
> >
> http://wiki.eclipse.org/Platform-releng/How_to_check_integrity_of_downloads
> > > >
> > > 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
> > > eclipse-dev@eclipse.org
> > > To change your delivery options, retrieve your password, or unsubscribe
> > > from this list, visit
> > > https://dev.eclipse.org/mailman/listinfo/eclipse-dev
> > >
> > >
> > >
> > > --
> > > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > > Java Persistence with Hibernate, Second Edition
> > > <http://www.manning.com/bauer3/>
> > > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > > Spring Batch in Action <http://www.manning.com/templier/>
> > > Blog: http://garygregory.wordpress.com
> > > Home: http://garygregory.com/
> > > Tweet! http://twitter.com/GaryGregory
> > >
> >
>
--
Matt Sicker <bo...@gmail.com>
Re: [eclipse-dev] Notice that Eclipse Platform plans to no longer
provide MD5 and SHA1 checksums for Neon (but still SHA512)
Posted by Gary Gregory <ga...@gmail.com>.
I've not looked into it...
On May 10, 2016 2:30 AM, "Benedikt Ritter" <br...@apache.org> wrote:
> Hi Gary,
>
> What changes are required for this? Is this just a setting in
> commons-parent?
>
> Benedikt
>
> Gary Gregory <ga...@gmail.com> schrieb am Di., 10. Mai 2016 um
> 02:51 Uhr:
>
> > Should we follow suit?
> >
> > Gary
> >
> > ---------- Forwarded message ----------
> > From: David M Williams <da...@us.ibm.com>
> > 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: eclipse-dev@eclipse.org, equinox-dev@eclipse.org,
> > cross-project-issues-dev@eclipse.org
> >
> >
> > 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
> > http://www.eclipse.org/downloads-- 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*
> > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=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*
> > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=454784>. If the removal
> of
> > the MD5 and SHA1 checksums would unduly burden anyone, please say so in
> > that *Bug 454784* <https://bugs.eclipse.org/bugs/show_bug.cgi?id=454784>
> > and
> > we would be happy to accommodate.
> >
> > I will soon be updating our wiki on *How to verify a download*
> > <
> >
> http://wiki.eclipse.org/Platform-releng/How_to_check_integrity_of_downloads
> > >
> > 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
> > eclipse-dev@eclipse.org
> > To change your delivery options, retrieve your password, or unsubscribe
> > from this list, visit
> > https://dev.eclipse.org/mailman/listinfo/eclipse-dev
> >
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > Java Persistence with Hibernate, Second Edition
> > <http://www.manning.com/bauer3/>
> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > Spring Batch in Action <http://www.manning.com/templier/>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
> >
>
Re: [eclipse-dev] Notice that Eclipse Platform plans to no longer
provide MD5 and SHA1 checksums for Neon (but still SHA512)
Posted by Benedikt Ritter <br...@apache.org>.
Hi Gary,
What changes are required for this? Is this just a setting in
commons-parent?
Benedikt
Gary Gregory <ga...@gmail.com> schrieb am Di., 10. Mai 2016 um
02:51 Uhr:
> Should we follow suit?
>
> Gary
>
> ---------- Forwarded message ----------
> From: David M Williams <da...@us.ibm.com>
> 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: eclipse-dev@eclipse.org, equinox-dev@eclipse.org,
> cross-project-issues-dev@eclipse.org
>
>
> 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
> http://www.eclipse.org/downloads-- 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*
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=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*
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=454784>. If the removal of
> the MD5 and SHA1 checksums would unduly burden anyone, please say so in
> that *Bug 454784* <https://bugs.eclipse.org/bugs/show_bug.cgi?id=454784>
> and
> we would be happy to accommodate.
>
> I will soon be updating our wiki on *How to verify a download*
> <
> http://wiki.eclipse.org/Platform-releng/How_to_check_integrity_of_downloads
> >
> 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
> eclipse-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/eclipse-dev
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
Re: [eclipse-dev] Notice that Eclipse Platform plans to no longer provide MD5 and SHA1 checksums for Neon (but still SHA512)
Posted by Ralph Goers <ra...@dslextreme.com>.
I am not even sure how you would do this. Maven does this automatically when you deploy. In Log4j I only do it manually when I zip the web site and archive it.
Ralph
> On May 9, 2016, at 5:51 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> Should we follow suit?
>
> Gary
>
> ---------- Forwarded message ----------
> From: David M Williams <da...@us.ibm.com>
> 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: eclipse-dev@eclipse.org, equinox-dev@eclipse.org,
> cross-project-issues-dev@eclipse.org
>
>
> 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
> http://www.eclipse.org/downloads-- 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*
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=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*
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=454784>. If the removal of
> the MD5 and SHA1 checksums would unduly burden anyone, please say so in
> that *Bug 454784* <https://bugs.eclipse.org/bugs/show_bug.cgi?id=454784> and
> we would be happy to accommodate.
>
> I will soon be updating our wiki on *How to verify a download*
> <http://wiki.eclipse.org/Platform-releng/How_to_check_integrity_of_downloads>
> 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
> eclipse-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/eclipse-dev
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org