"Stephen R. van den Berg" <srb@cuci.nl> wrote:
quoted text
> What are the opinions on adding a basic challenge-response type
> authentication mechanism to the native git protocol?
> I.e. the authentication would be a simple one, which uses
> SHA1 (surprise ;-) to actually encrypt username/password/salt
> and authenticate the user.
> 
> I'm willing to do the work, if there are no objections.

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
store the public keys in a keyring and log pushes (changes to refs)
so that one could replicate the log on another server and come up
with the same result.  Hence not just the current source code but
also the "how we got here" could be verified externally.

Username/password management is always ugly.  Some admins will want
you to plug into PAM, others just want a flat file that is unique
to the service, others want LDAP.  And then you get into people
wanting Kerberos support because they already have everything else
in their domain supporting it.  Tons of complexity for our project.

Isn't there some authentication frontend that some IMAP servers
use to handle the authentication for them?  I think last time
I setup bincimap it used checkpassword.  We might want to do the
same if we are going down this road...

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