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

From: Stephen R. van den Berg <srb@cuci.nl>
Date: Aug 14, 2008, 00:10 UTC
Message-ID: <20080814001029.GA14939@cuci.nl>
In-Reply-To: <20080813180857.GH3782@spearce.org>

Shawn O. Pearce wrote:

>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

Correct.

>point it may actually be easier (and safer) for the admin to just
>handle a GnuPG or SSH public key.

If you want that, that is best handled in ssh.

>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.

Show 6 quoted lines

>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 agree, which is why I don't want to put this complexity in git proper.

>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.

I'm not trying to solve all management problems, I'm just trying to offer a simple solution for the small-user-base-central-repository case without a lot of code-bloat on the git side. If it doesn't fit ones needs, use ssh or something else; but it does have its merits for the simple centralised setups.

-- 
Sincerely,
           Stephen R. van den Berg.

"And now for something *completely* different!"