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

From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Date: Jan 13, 2010, 20:47 UTC
Message-ID: <20100113204732.GB8383@Knoppix>
In-Reply-To: <20100113194050.GA11688@inner.home.ulmdo.de>

On Wed, Jan 13, 2010 at 08:40:50PM +0100, Andreas Krey wrote:

Show 9 quoted lines

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

Show 7 quoted lines

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