Re: [RFC 0/2] Git-over-TLS (gits://) client side support

[Ilari Liusvaara <ilari.liusvaara@elisanet.fi>]

On Wed, Jan 13, 2010 at 08:40:50PM +0100, Andreas Krey wrote:
> On Wed, 13 Jan 2010 21:18:02 +0000, Ilari Liusvaara wrote:
> ...
> > That feature is grossly underdocumented (and also nonportable). Unix(7)
> > should document it, except that it doesn't for me (it documents that
> > SO_PASSCRED takes a boolean, except that what the server implementation
> > passes is something completely different).
> 
> Actually, I meant how you plan to map credentials (however obtained)
> into allowed actions inside git-daemon (or the hooks).

Its actually git-daemon2. And it doesn't authorize anything, only delegates
the authorization (e.g. to gitolite).
 
> ...
> > And how many (relative) use client ceritificates with SSL? Keypairs with SSH?
> > Why you think this is?
> 
> Because ssh is much more popular than ssl client auth. Obtaining client
> certificates isn't much more complicated than getting an ssh account,
> once you have scripts for the stuff ready.

SSL client certificate usability is horrible. SSH keypairs are actually
almost usable.

> But I wonder: When you want keypair auth, why not just use ssh?

IIRC, I already have told at least twice...

> I didn't quite understand the use case yet, it seems. With ssh
> I have all the infrastructure like ssh-agent in place already;
> with gits: (any kind of) it will be asked for sooner or later.

gpg-agent can be used (since client uses gpg to protect the keys
if needed).

-Ilari