incubator-general mailing list archives

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.s@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
>> > <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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org