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. > 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) > 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. > 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. another weakness when not using keyservers is how revocation certificates can be distributed. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]