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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html