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 <garydgreg...@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 <ctubb...@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 <e...@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 <seb...@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 <brit...@apache.org> wrote: > > > > Hi Gary, > > > > > > > > What changes are required for this? Is this just a setting in > > > > commons-parent? > > > > > > > > Benedikt > > > > > > > > Gary Gregory <garydgreg...@gmail.com> schrieb am Di., 10. Mai 2016 > um > > > > 02:51 Uhr: > > > > > > > >> Should we follow suit? > > > >> > > > >> Gary > > > >> > > > >> ---------- Forwarded message ---------- > > > >> From: David M Williams <david_willi...@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-...@eclipse.org, equinox-...@eclipse.org, > > > >> cross-project-issues-...@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-...@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: garydgreg...@gmail.com | ggreg...@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-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@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 >
