Sam Vilain <sam@xxxxxxxxxx> wrote: ... > The key idea is to reject pushes if the PGP signature cannot be verified. ... > When heads are pushed, the signed tags that are moved from refs/heads/ > foo can be saved in an "archive" tag space, such as under refs/audit/ > KEYID/ - this will allow, in the case of a network of git servers, for > servers to synchronise from each other, even when they > don't trust each other. This is certainly interesting. It would benefit from the recursive locking scheme we were talking about for the update hook, which someone (Steven Grimm?) wanted so they could execute git-svn transparently during push and have the update hook change the ref instead of receive-pack. The downside to this is you have to tag everything before you push it, so you need some sort of wrapper around git-push. That isn't as hard as it sounds for the command line case, but it does make things more difficult for a usage from say git-gui. :) I was also thinking about using GPG to sign the command packets being sent between send-pack and receive-pack. If the GPG signature for that set of packets is good and a known key then the update is allowed to continue. This avoids the mess of needing to run git-tag locally before push, and of needing to "unwrap" the temporary tag in the receiving repository, but it adds yet another extension to the send-pack/receive-pack protocol. > This does force potential contributors to get PGP keys, and get them > signed - but that seems to me to be a reasonable barrier of entry and > may even help drive some PGP adoption. In many cases today such contributers would have been forced to get an SSH account on the server they want to push to. Getting an SSH account configured and a key installed may be more difficult than generating a PGP key pair and emailing in the public key. Of course the PGP based system is nicer in that the administrator might get a public key that has been signed by others he trusts, and thus is more readily able to verify that the contributor is who they think it is. 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. 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. -- Shawn. - 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
