Shawn O. Pearce wrote: > To be perfectly honest, in a wide open source community I think > the truely distributed nature of development like the linux kernel > or git itself uses works very well. Development schedules aren't > organized into "next 30 minutes", "next 4 hours", and "next week". > > Peer review and community acceptance of changes is a very important > concept. Blindly accepting changes into a tree because of a PGP > signature/SSL certificate/SSH key isn't really the norm, and is > far from the best solution. We've all posted cr**p^Wless-than- > the-best-code to this list before, and yet many of us would have > "committer access" to the git tree under a centralized model. > > I'm happy my changes aren't accepted just because I signed them. > Its better that Linus/Nico/Dscho/Junio/you/et.al. have looked at > them and also felt they were worthwhile. I agree wholeheartedly - hence my comment about "mob" branches. What I was implying is that you could model it conceptually off repo.or.cz. That is, when you start a project, you "own" a namespace. Everyone else has to pick a fork name, and the first push they make to "forks/forkname/*" registers that fork name to that key. This could support fully distributed access control over the namespaces. What it means for access control to be distributed is that any node can check the log of tags that granted permission to people, and assuming that they processed the same grants in the same order they will arrive at the same access control result. To describe this with an example, say Linus decides that Junio can push to any ref on the project, he can note in a tag; "From this release forward, Junio Hamano <KEYID> will be authorized to push to any reference, and grant access to others under the reference space 'refs/heads/topics/'". Or, preferably something more automatically parsable. Anyway, the presence of a signed document is a hint for the audit program to try to reach Junio's key from Linus' key (like this would: http://pgp.cs.uu.nl/mk_path.cgi?FROM=76E21CBB&TO=F3119B9A&PATHS=trust+paths) if it can, and then add the signing key to the ACL's PGP keyring. The ACL state could be a branch in a funny refspace with a directory for the keyring, and a place to keep copies of any tags it removed because they were there just for the push. And yes, it would need a simple interface. > But in a smaller business type setting, where there's under 100 > employees working, odds are you've already created the user account > on systems, and physically passed the initial password via a sticky > note after checking the person's government issued IDs. In such a > setting having yet another authentication system (PGP keys) is just > yet more work for the already over worked/under appreciated IT staff. Agreed - again I'd personally consider allowing receive-pack with reflogs in those environments if setting up PGP or SSH keys was a hassle. Sam. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
