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