Shawn O. Pearce wrote:
quoted text
>"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?

quoted text
>> SHA1 (surprise ;-) to actually encrypt username/password/salt

quoted text
>Last time we talked about this we got off onto some tagent about
>using GnuPG public keys to authenticate users, and then how we might
...

That is the feature rich solution.  For those there is ssh/webdav
and possibly other setups.

quoted text
>Isn't there some authentication frontend that some IMAP servers
>use to handle the authentication for them?  I think last time

There is GSSAPI, which allows plugging in just about anything you like.
Nonetheless, for a lot of small projects, you have a relatively small
number of developers (typically <32) which have commitrights on one or
more source trees in a central repository.

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

There are no promises for flexibility, security, whatsoever.
The only things I'm aiming for are:
a. Simplicity (need just git).
b. No cleartext passwords over the wire.
c. No encryption.
d. Highest performance (native git protocol).

Anyone needing more is referred to webdav/ssh and assorted solutions.
This minimises the dependencies on external libs, the only thing we need
is a strong hash-function to implement (b); as it happens, we already
have SHA1..
-- 
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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html