incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <...@daniel.shahaf.name>
Subject Re: Key security (Re: KEYS and releases)
Date Tue, 28 Jun 2011 11:33:07 GMT
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
> > <bdelacretaz@apache.org> wrote:
> >> Hence the need for people to download KEYS files from an *.apache.org
> >> 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 apache.org 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 apache.org, 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 apache.org, 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]@apache.org.
> 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 id.apache.org, ???)
>   - 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 @apache.org, 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
> http://www.webthing.com/~nick/cv.html
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message