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

["Stephen R. van den Berg" <srb@cuci.nl>]

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.

>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!"