[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#732450: please sign new apache releases only with strong keys -- trimming the KEYS file

Please remove me from this email list. Please unsubscribe me.  Thanks.

On Fri, Dec 27, 2013 at 10:49 AM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> 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  http://bugs.debian.org/732450#22 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:



Reply to: