httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frederick Miller <>
Subject Re: please sign new apache releases only with strong keys -- trimming the KEYS file
Date Fri, 27 Dec 2013 15:53:23 GMT
Please remove me from this email list. Please unsubscribe me.  Thanks.

On Fri, Dec 27, 2013 at 10:49 AM, Daniel Kahn Gillmor <
> wrote:

> On 12/26/2013 06:18 PM, Nick Kew wrote:
> > You're ahead of us.  Individual Apache folks like Jim have taken
> > responsibility and moved to 4096-bit keys, but we haven't as a
> > community had the discussion that might lead to pruning KEYS.
> > My inclination is to say NO to requiring anyone to remove old keys,
> > but YES to encouraging strong keys to sign all releases.
> Thanks for considering this, Nick.
> At the moment, some of your downstreams have the impression that KEYS
> indicates all of the keys that apache might use to sign releases.  For
> example, in Arno Töll writes:
> >> Therefore, I thought a more complete patch would be a keyring which
> >> includes all signatures of people allowed to sign and release code on
> >> behalf of the httpd project.
> Maybe you could update the preamble of KEYS to indicate that only strong
> keys (and please clearly define "strong" if y'all are making this
> policy) will be used to sign releases?
> Nick again:
> > That may be an issue for some Apache folks.  For myself, my newer
> > (4096-bit) key has fewer sigs than my old 1024-bit[1], though not
> > catastrophically so.  What is perhaps more of an issue is that hardly
> > any of the signatures on the new key are from Apache folks, as I have
> > (alas) not made it to Apachecon for a couple of years now.  Others may
> > have a range of reasons for retaining older keys.
> Your 4096-bit key (0x3CE3BAC2EB7BBC624D1D22D8F3B9D88CB87F79A9) appears
> to be certified by nearly 60 other keys -- including at least a couple
> debian developers and Nikos Mavrogiannopolous (the lead GnuTLS
> developer).  I can't speak for all of debian, but i think a strong key
> connected by a few paths to other established free software developers
> is more reliable than a weak key connected by dozens of paths.
> The keys themselves should not be the weak point in our cryptosystems.
> > [1] Key IDs 40581837 and B87F79A9
> (i recommend using full fingerprints instead of keyids if you have to
> communicate about a specific key:
> Regards,
>         --dkg

View raw message