On 23/07/2008, at 4:23 AM, Robert Burrell Donkin wrote:
On Fri, Jul 11, 2008 at 5:42 PM, Brett Porter <[EMAIL PROTECTED]>
wrote:
Hi,
I've wanted to pick up my work on this for some time and was
prodded by the
[EMAIL PROTECTED] threads to take another crack at this.
http://docs.codehaus.org/display/MAVEN/Repository+Security (the
issue and
related branches are linked)
(sorry for picking this up late)
in general, definitely worth implementing and a big improvement
there are some weaknesses in a single set of trusted keys: it's a very
coursely grained trust model. i may trust B1313DE2 to sign commons and
JAMES releases but not maven ones. the owner of B1313DE2 may be
expelled from apache.org but there is no way for an organisation to
automatically inform the user that this key is not longer to be
trusted for their releases. signed meta-data is one way to approach
this problem.
Right. I do have a section at the bottom where you can trust only
certain people for certain keys that you've picked up below, but it
was rightly pointed out that might be overkill.
We do need a specific answer to your described story, and it also
applies in the other direction - you don't want to have to load every
Apache committers key to say you trust everything from Apache. I
haven't fully investigated the security implications of using role
keys to sign others.
Per-artifact settings
By default, all keys in the user's keyring will be accepted.
However, to strengthen a requirement,
a project may require that the key be a particular one, or signed
by a particular key. The key
provided might be either an email address or the key ID.
identifier used:
a. definitely shouldn't be the email address since this is trivial
to fake
b. collisions are possible between Key IDs and (given an ID) it may
be possible to construct a colliding key though this would be
definitely non-trivial
c. recommended that the fingerprint is used (the Key ID is derivable
from it)
These are all intended to be a user convenience for specifying them,
and it's the users responsibility to get the right key into their
keyring for the given identifier.
Certainly any mechanism that helps retrieve a key to add to the
keyring should be verifying the fingerprint.
Do keyrings support adding multiple keys with the same ID but
different fingerprints? I didn't know that was an issue.
Web of Trust
Initially, the user will be required to explicitly add keys to
their keyring that they accept.
this may need a little more thought. adding keys to the rings only
allows a signature to be verified. only signed keys are trusted and
this is a separate action. checking signatures is worthwhile even if
the singature is untrusted: though a valid untrusted signature does
not allow for positive validation, if the signature is invalid even
when the signature is untrusted this indicates an attack of some kind.
in general, i think that automatic download is very important for
usability. in my experience, users often have problems understanding
key servers.
I agree this area needs more thought (and it's similar to your first
point).
WoT won't be sufficient on it's own as most users have never had
contact with other signers. However it does need to be used for
automatically downloading keys (which does make it much easier to use,
for certain).
The key should be downloaded from a trusted keyserver or KEYS file
(as specified in settings.xml above), not from the repository that
the artifact is being downloaded from.
this may need more thought. these distribution mechanisms are
typically intended to just distribute keys without gaurantees.
I think getting KEYS (not automatically) from the original web server
should be satisfactory to most users in terms of trustworthiness. It
was poorly worded in that it looked like that might be a transparent
action where it's not though.
another weakness when not using keyservers is how revocation
certificates can be distributed.
This is true.
Thanks for the feedback!
Cheers,
Brett
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
