I have a concern with the practicality of using client certificates over https instead of SSH.
You can tell git which key and cert to use for client cert https connections. This is done via git-config, so it can be set both globally (--global, stored in ~/.gitconfig) and per project (/path/to/ project/.git/config). Say you're using multiple Gitorious installations on a daily basis, i.e. gitorious.org, git.myserver.com, git.mycompany.com, etc. Wouldn't each Gitorious installation require a separate client cert? If so, you'd have to configure the key and cert on a per-repo basis. With SSH, you can use the same ssh keypair for all those sites, not requiring any per-repo config, since there's no ident info in the public key other than that you was logged in to gitorious.org when you added it. On Jun 24, 7:40 am, Marius Mårnes Mathiesen <[email protected]> wrote: > Anyone subscribed to this list will know that installing Gitorious is not > for the faint of heart. There are a lot of moving parts, a lot of > dependencies, and getting everything right is difficult. I really want to > change this. > > One of the things that complicates the setup is that Gitorious is not just a > web app. It's also: > - a service running on top of SSH, using key infrastructure for > authentication and authorization > - a daemon that serves Git repositories over a dedicated protocol (git://) > - a service that provides Git access over HTTP > > Historically, the only protocol that offered write access in Git was SSH. > The git protocol was mainly used because it's faster than HTTP and doesn't > require authentcation over SSH. These two things are the main reasons why > you want to run all these daemons on your server: > - SSH for push > - Git for fast, anonymous pull > > Git's HTTP support changed a lot in version 1.6.6, introducing "smart" HTTP. > It's a fairly simple concept; a modern Git client will (if supported by the > server) open a series of HTTP POST requests to the server, basically running > regular git traffic (upload-pack and receive-pack) over this connection. > This means HTTP got a lot faster, the performance is comparable to Git over > SSH. And since HTTP supports authentication (unlike the Git protocol) and > encryption (SSL), this means you can support all Git usage scenarios over a > single protocol, and stil be safe. Oh, and as a bonus, people stuck behind a > firewall can finally join the party too. > > Gitorious' current HTTP support is based on the old (aka. dumb) HTTP method > (Scott Chacon has a really good write-up on the difference between "smart" > and "dumb" HTTP athttp://progit.org/2010/03/04/smart-http.html), which is > slow, error-prone, read-only and locks up your Apache/nginx workers serving > static files. Git itself has a cgi that provides smart HTTP, but making it > work in a scenario where the incoming URL is different from the path on the > file system involves hacking Git itself. > > Christian and I have made a few experiments on implementing smart HTTP for > Gitorious, and this week we've been focusing on one of them: Mutt [1]. Mutt > is a cross breed (and also a git): > - It's written in Ruby > - It runs under JRuby > - It uses the awesome JGit library, which is an implementation of Git in > Java. JGit is used in EGit, the Git support in Eclipse, and in Gerrit, the > code review system used by the Android project > > Mutt will provide anonymous/authenticated fetch/pull and authenticated push > to your Gitorious server. It will be awesome, and it will be installed by a > single command. > > The question is: once we have an easily installed, anonymous/authenticated, > pull/push solution for Git traffic: is it time to deprecate the other > protocol handlers in Gitorious: > - The SSH handler > - The Git handler (git-daemon or git-proxy) > > Would anybody miss them? > > Discuss. > > Cheers, > - Marius > > [1]:https://gitorious.org/gitorious/muttYes, I know there's already a > program called Mutt, the name just fits really well. I promise we won't name > the binary mutt, and we won't read your .muttrc. -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected]
