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

From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Date: Jan 13, 2010, 19:18 UTC
Message-ID: <20100113191802.GA8110@Knoppix>
In-Reply-To: <20100113183520.GA23674@inner.home.ulmdo.de>

On Wed, Jan 13, 2010 at 07:35:20PM +0100, Andreas Krey wrote:

Show 5 quoted lines

> On Wed, 13 Jan 2010 19:36:10 +0000, Ilari Liusvaara wrote:
> 
> Ok, then I'll be really interested in the server-side support and
> the man pages on the whole stuff. Especially in how this is going
> to be different from what ssh:// does or can do.

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

I found the intformation about how to forcibly get peer UID on Linux from one secure programming HOWTO.

One other software that I know uses similar stuff is D-BUS. AFAIK, SSH can't do it.

Essentially, it involves asking the kernel about UID the socket peer
runs as (with local sockets, kernel knows that information).

> Please consider my objections revoked, other than the claim that
> it could be done with stunnel, however ugly that would be.

Only if you don't care about complexity introducing PKI would bring (yes, I read those manuals).

> I don't see how that would endanger the standard certificate auth in ssl
> (client or server).

It doesn't, but...

> Of course, you have another problem in that case...also I'd personally
> like to rely on ssl client certificates when using https.

And how many (relative) use client ceritificates with SSL? Keypairs with SSH? Why you think this is?

-Ilari