incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <>
Subject Key security (Re: KEYS and releases)
Date Tue, 28 Jun 2011 10:43:24 GMT

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

Nick Kew

Available for work, contract or permanent

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

View raw message