incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Re: Key security (Re: KEYS and releases)
Date Tue, 28 Jun 2011 12:22:55 GMT
There's another possible dimension to this, which is related to the
'Apache Key' suggestion.

The current mechanism gives a\ sophisticated/ consumer tools to get
some confidence that what they downloaded was, in fact, created by
someone in the Apache infrastructure.

If a dozen black hats create PGP keys that purport to belong to
various Apache committers, and sign each others keys, and publish them
to a key server, they could create confusion, restrained (if I have
this right) by KEYS on APache's own server.

What if the ASF stored keys, and offered a web page into which you
could post a key and get back either "(check) signed by a committer of
Apache foo, bar, and baz" or "(big red x) not a signature we
recognize". That seems more useful to me than an Apache global key.

On Tue, Jun 28, 2011 at 7:33 AM, Daniel Shahaf <> wrote:
> I'm not sure what I think of your suggestion of having an "ASF PGP key".
> How about requiring committers to specify on id.a.o not just the last
> few bytes of their key's fingerprints, but the whole fingerprint?
> Nick Kew wrote on Tue, Jun 28, 2011 at 11:43:24 +0100:
>> On 28 Jun 2011, at 09:53, Jukka Zitting wrote:
>> > Hi,
>> >
>> > On Tue, Jun 28, 2011 at 10:29 AM, Bertrand Delacretaz
>> > <> wrote:
>> >> Hence the need for people to download KEYS files from an *
>> >> domain that we do control. Putting KEYS in a distribution might cause
>> >> people to use them instead of getting them from a trusted source, and
>> >> that's bad.
>> >
>> > The keys should be included in the web of trust, so it shouldn't
>> > matter from where a user gets the keys.
>> In an ideal world that would work for everyone ...
>> > Without the web of trust, the PGP signatures are just a rather
>> > elaborate version of the MD5 and SHA1 checksums we also provide.
>> Not quite.  Keeping a KEYS file at puts an extra hurdle
>> in the way of an imposter forging a signature.
>> > Of course, without being included in the web of trust, the best a user
>> > can do is to get at least one of the keys from a trusted source.
>> Right.  How trusted is, and can we build in more security?
>> (a) Checksums provide security against things like damage in transmission
>> but have no power against forgery.  Anyone having tampered a package can
>> trivially create their own checksums.
>> (b) Checksums downloaded separately from a sufficiently trusted source
>> add security but beg the question of 'sufficiently trusted'.
>> (c) PGP helps by introducing an identity and the web of trust.  If an intruder
>> were to introduce new, forged keys and signatures at, that's
>> going to get noticed by the real owners of the identities on the forged keys.
>> The more signatures on a key, the more people will be there to flag up
>> the intruder when they check a forged signature.
>> But perhaps we can improve further on that.  What if we could introduce
>> an automated official ASF signing key whose role would be to authenticate
>> our own legitimate keys?  Obviously this key won't itself attend keysignings,
>> but it can apply rules that will improve security over the mere presence of
>> an unverified signature from [someone]
>> I'm thinking now of tests like:
>>   - don't sign any new key until it's been verified by multiple channels
>>     (exchange of email, verify a token at, ???)
>>   - only accept new keys whose WoT traces back to established keys
>>   - require releases to be signed by an ASF-trusted key
>>   - visual display highlighting ASF-verified keys in a release key's WoT.
>>   - Regular checks of all keys, and a page to highlight
>>     unverified keys and buzz their purported owners.
>> Of course nothing is perfect, but we should be able to improve on
>> unverified!  We should certainly be able to improve the surveillance
>> that leads to any bogus key getting rapidly noticed!
>> Anyone from infra reading this?  Has this kind of discussion already
>> happened?
>> --
>> Nick Kew
>> Available for work, contract or permanent
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message