community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stian Soiland-Reyes <>
Subject Re: SHA512 by default for GPG sigs
Date Thu, 19 May 2016 06:43:12 GMT
In principle +1, a PGP signature based on sha1 is not cryptographically

Obviously blindly checking a PGP signature, even after importing the KEYS
from, 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" <> wrote:

> Hi all,
> I'm not sure a better list to get feedback on, but I wanted to bring
> attention to the proposal here:
> 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
> 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.

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