On Thu, May 19, 2016 at 2:43 AM Stian Soiland-Reyes <st...@apache.org> wrote:
> 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) > > 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" <ctubb...@apache.org> 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 https://www.apache.org/dev/openpgp 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.
