community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: SHA512 by default for GPG sigs
Date Thu, 19 May 2016 22:49:21 GMT
On Thu, May 19, 2016 at 2:43 AM Stian Soiland-Reyes <>

> 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, 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)
Agreed. That's why folks also are encouraged to grow their web of trust.
Frankly, though, I'm generally content with any valid signature from a key
in a PMC's managed KEYS file, at least for the purposes of verifying
releases. That's because I have a reasonable confidence in the Apache
infrastructure to secure the published KEYS files, and that the release
managers are using their keys to act in the interest of their respective
PMCs (or at least, not using them to act against it by falsifying
unofficial releases).

A GPG signature doesn't attest that "content X came from entity E". It
attests that "the content whose hash is X came from entity E". So, that
attestation is only as strong as the hash algorithm. Weaker algorithms are
subject to "pre-image" attacks (maybe still a long way off for SHA-1, but
we still should avoid it).

> 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.
Agreed. I also wouldn't get rid of those. They have their own utility. This
is just about making the *.asc detached signature files stronger.

> 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:
It's possible, but I think very unlikely that this would cause any problems
for anybody. GnuPG added support for SHA512 in early 2003, and all the tags
in GnuPG's git repo seem to support it. Old versions of OpenPGP didn't
support it, but that's a dead project (AFAICT), and in any case, this is
the maven-gpg-plugin, not the maven-openpgp-plugin. All tags in the gnupg
git repo seem to support SHA512. Anything installed today should support
it. If there are concerning compatibility issues, then those issues would
already be a problem for the documented ASF advice at

This doesn't affect Maven deployments at all, except to make the signatures
emitted in the release profile's activation of maven-gpg-plugin stronger.

This really should be transparent. How rare it is to get more security
without having to trade anything of value for it... but it seems to me
that's what we have in this situation.

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