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 > >
