In principle +1, a PGP signature based on sha1 is not cryptographically strong.
Obviously blindly checking a PGP signature, even after importing the KEYS from https://www.apache.org/dist, that is also not any proof you got the intended release, just an artifact by someone who previously signed some ASF release. (If you are paranoid and/or work my for a three-letter government institution, then you probably want more proof of exactly which version you are downloading) I think the convenience of the old standard .sha1 and .md5 files is that they can also be included in this VOTE emails, forming a distributed evidence in list archives of which release was approved. (although I see many projects now being made more lax about this and just refer to a transient Maven step repo). In addition to being easy to check, they are also easy to inline say in a Dockerfile, so I would not get rid of those even if the .asc is improved. Are there any compatibility issues for downstream users with your proposed default change? What about for Maven deployment? I assume a newer gpg is needed; what would be the new version requirement, and how does this match what is available in typical distros and OS installs? On 18 May 2016 7:55 p.m., "Christopher" <ctubb...@apache.org> wrote: > Hi all, > > I'm not sure a better list to get feedback on, but I wanted to bring > attention to the proposal here: > https://issues.apache.org/jira/browse/MPOM-118 > > Essentially this is a suggestion to configure the maven-gpg-plugin to sign > using SHA512 as its digest algorithm in the ASF Parent POM, used by many > Maven/Java-based projects within ASF. This configuration takes affect > during software releases when this plugin is activated (typically prior to > a release candidate vote, and staging a release in Nexus for distribution > to Maven Central). > > This would only affect the hash algorithm used to generate GPG signatures > for releases, and not any separate SHA/MD hashes published separately by > any project, which can be weaker (SHA1, MD5) for convenience, and don't > convey the strong authenticity statement that digital signatures provide. > > For background, gpg uses SHA1 by default, unless the signing key or gpg > configuration has a preference to use another algorithm (as described on > https://www.apache.org/dev/openpgp). > > This proposed configuration change wouldn't force the use of SHA512 (it > could still be overridden by a project), but it would make it the default, > which helps improve the security of releases in the case where release > managers have failed to keep their configuration up-to-date with the best > recommendations for using gpg. > > Thoughts? +1s? Discuss here or on the JIRA please. > > Thank you. >
