commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [eclipse-dev] Notice that Eclipse Platform plans to no longer provide MD5 and SHA1 checksums for Neon (but still SHA512)
Date Wed, 11 May 2016 16:46:20 GMT
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 <garydgregory@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 <ctubbsii@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 <ecki@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 <sebbaz@gmail.com>
> > > To: Commons Developers List <dev@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 <britter@apache.org> wrote:
> > > > Hi Gary,
> > > >
> > > > What changes are required for this? Is this just a setting in
> > > > commons-parent?
> > > >
> > > > Benedikt
> > > >
> > > > Gary Gregory <garydgregory@gmail.com> schrieb am Di., 10. Mai 2016
> um
> > > > 02:51 Uhr:
> > > >
> > > >> Should we follow suit?
> > > >>
> > > >> Gary
> > > >>
> > > >> ---------- Forwarded message ----------
> > > >> From: David M Williams <david_williams@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message