"Stephen R. van den Berg" <srb@xxxxxxx> wrote: > Shawn O. Pearce wrote: > >"Stephen R. van den Berg" <srb@xxxxxxx> wrote: > >> What are the opinions on adding a basic challenge-response type > >> authentication mechanism to the native git protocol? > > In order to aid them in setting up a simple accesslist, git would do > just fine by simply offering a flat-file like list. Forcing those > setups to use anything more complicated makes adoption of git for those > kind of projects unreasonably more complicated (IMO). Well, anytime you get into a flat-file access list you get into management of that list. How do users change their own password? How does an admin add/remove a user, or reset a password? What defines an admin? Can you do these things remotely? Can you keep the password encrypted on the remote side so an admin cannot see a user's (common) password and maybe gain access to unrelated sites? If you are going to keep it "really simple" you may be tempted to say that all user additions/deletions/password changes should be done by the admin directly editing the password list. At which point it may actually be easier (and safer) for the admin to just handle a GnuPG or SSH public key. This is why we tend to rely on SSH. It neatly solves all of this for us, and does it in a way that UNIX administrators are familiar with managing. This is also why the last discussion on this topic went down the road of using GnuPG to handle the authentication portion of the protocol. Unfortunately dealing with the server side keychain is a little bit more complex then I'd like it to be out of the box, and the client side I think is lacking something as common as ssh-agent for caching the decrypted key. I can see how it would be pretty simple to add authentication to git-daemon based upon a shared secret, but such schemes always cause management problems on both sides. -- 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
