On Wed, 13 Jan 2010 16:47:47 +0000, Ilari Liusvaara wrote:
...
> > It doesn't need to, really. stunnel sets the environment variable
> > SSL_CLIENT_DN with the distinguished name of the client certificate,
> > which can be used in the hook scripts ('update') on the server.
>
> That would be useless. Data about authenticated client needs to fed to
> authorization decisions already before invoking git.
If you don't want public read access then you need to wedge a script
between stunnel and git itself that checks whether authentication is
present, yes.
> And besides: Gits:// uses certificates as keypairs,
My gripe with this is that I would expect gits: to be the same
as git: except that there is SSL underneath. git: does not have
authentication, so there should be none in gits: except what
SSL provides. (And the auth via unix domain sockets would be
usable for plain git: as well; there is no reason to encrypt
local traffic?)
(Is the unix auth via unix domain sockets part of GnuTLS?)
> which would make DN
> data absolutely useless because it is untrustworthy. And adding PKI
> is way too complicated.
That's another story. I think that it would be possible nowadays
to implement gits:// (in both ways) via core.gitproxy and a server-side
wrapper program (stunnel or else), but that has the disadvantage of
being unable to just provide a clone url without installing special
software besides git.
...
> The authentication support for smart-http seems pretty bad (making the
> old mistake of not binding authentications).
Mind to explain 'binding authentications'?
Andreas
--
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