[Dev] Replacing gitosis with git-shell

[Nicolás Reynolds]

On Fri, 13 Apr 2012 00:41:23 -0400, Luke T.Shumaker <lukeshu at sbcglobal.net> wrote:
> At Tue, 10 Apr 2012 00:58:33 -0300,
> Nicolás Reynolds wrote:
> > So I did a test to replace gitosis on the server, to allow push access
> > to our git repos[0]. The idea was to find a simpler way that doesn't
> > require the granularity gitosis allows, that IMO hurts our horizontal
> > approach, but it still had some degree of security...
> > 
> > For this I found git-shell, a tool that comes with the git package and
> > works as a user shell that only allows the git commands needed to push
> > into repos.
> 
> Of course, the decision is that of the doer, but other solutions I
> would consider:
>  * git-http-server: a CGI script allowing push over HTTP. Permissions
>    are handled by the web server.
>    Also: There are clones that may work better with certain setups,
>    for example, jgit-http-server for Java, or Grack for Ruby. I'm not
>    aware of any that are Python (we're running Python for parabolaweb
>    anyway).
>  * Girocco (the repo.or.cz software): a set of (mostly perl) CGI
>    scripts.
>  * Gitorious: Ruby on Rails, RESTfully designed, meaning it has an API
>    we can use to integrate it with other software and script things.

do we really need http-push?

> 
> I mention scripting and integration because it will allow us to
> automate submodule repository creation, which you are iterested in.

yeah, repo creation is something to fix... but can't it be done with a
script? gitorious would be interesting if it's relatively straight
forward to install...

> 
> It also allows the possibility of integrating with parabolaweb, but I
> wouldn't hope for that.

labs.parabola.nu already integrates one repo to one project and shows
it's commit (not very gui-friendly but you have feeds)

> 
> > I created a test user called "git2", with home /srv/git2 and shell
> > /usr/bin/git-shell. Inside this home I mirrored abslibre.git to work on,
> > and copied the .ssh from /srv/git (and cleaned up the stuff gitosis uses
> > to work).
> > 
> > This worked OK, except that you have to pass the full path of the repo to
> > push, so if you cloned git://gparabola/abslibre.git you'll have to
> > push into ssh://gparabola/srv/git2/abslibre.git
> 
> You can work around this by not giving the address in URL form, but in
> SCP form: "git2 at gparabola:abslibre.git"

so with the ssh_config aliases it would be gparabola:abslibre.git :D

> 
> > Now, we needed a method to add new SSH pubkeys in an easy way. Since
> > git2 uses git-shell I couldn't run `ssh-copy-id` unless I specifically
> > enabled it, but it still lacked the accountability I was looking for,
> > that is "X added the new hacker Y", instead of randomly saying on
> > #parabola "Hey I added Y to the repos" or "fauno, when will you add Y?".
> > 
> > I came up with this:
> > 
> > Manage the SSH pubkeys with another git repo in a way that pushing into
> > it gives immediate access to those keys to the git server. The history
> > management would also allow the kind of accountability I already
> > mentioned by using technical methods embedded on git itself ;)
> > 
> > So I did this:
> > 
> > I created a "hackers" git repo locally and added the authorized_keys
> > file and a README explaining how to work with the repo.
> > 
> > Under git2, I created "hackers.git" as a bare repo.
> > 
> > Then I cloned hackers.git into .ssh and gave it the permissions ssh
> > needs.
> 
> http://lukeshu.ath.cx/1/img/git.png
> 

hahahahaa but we were already doing this with gitosis.


> > On hackers.git I added a post-update hook that forces a checkout on
> > .ssh, so anytime someone pushes a key to the server it gets immediately
> > approved by sshd.
> 
> Or a cron job if you want to get it working quickly.

the hook is already tested and synchronic to the git-push, a cron would
introduce waiting time.

another problem would be how to do this also on repos (different
servers). you can add more than one pushing "url" to git so one push
sends to more, but this requires manual configuration.

also some security audit wouldn't be bad on ssh accesible users

-- 
libertad!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20120413/ef6dd7d5/attachment.sig>