Re: [RFC] Adding a challenge-response authentication method to git://

["Shawn O. Pearce" <spearce@spearce.org>]

"Stephen R. van den Berg" <srb@cuci.nl> wrote:
> Shawn O. Pearce wrote:
> >"Stephen R. van den Berg" <srb@cuci.nl> 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.