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

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 13 Jan 2010 21:18:02 +0200

On Wed, Jan 13, 2010 at 07:35:20PM +0100, Andreas Krey wrote:
> 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