On 7/23/08, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > On 22-Jul-08, at 8:55 PM, Brett Porter wrote: > >> >> 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. > > From my understanding using role keys is a good thing because you can > partition use. If one partition is compromised you don't have to go > invalidate everything you've ever signed. +1 It should be possible to distribute trust meta-data at the organization level partitioned by group ID. Users could download this directly from the master site.
Robert > >> >> >>> >>> >>>> 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] >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > jason at sonatype dot com > ---------------------------------------------------------- > > People develop abstractions by generalizing from concrete examples. > Every attempt to determine the correct abstraction on paper without > actually developing a running system is doomed to failure. No one > is that smart. A framework is a resuable design, so you develop it by > looking at the things it is supposed to be a design of. The more > examples > you look at, the more general your framework will be. > > -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
