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 <d...@daniel.shahaf.name> 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 >> > <bdelacre...@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-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
