Re: Bugs in Gitosis

From: Sitaram Chamarty <sitaramc@gmail.com>
Date: Oct 28, 2010, 23:54 UTC
Message-ID: <AANLkTi=pdSyjd5ACu8D_Yio5KX68W2n0e=LXXeTw70mS@mail.gmail.com>
In-Reply-To: <26E9B811E137AB4B95200FD4C950886BA9665D70@orsmsx507.amr.corp.intel.com>

I can't speak for gitosis -- I thank my stars every day that the gitosis author did not reply to my emails back then, because otherwise there may not have been a gitolite.

But I will try and address a couple of points which strike me as important, especially ones that affect gitolite also, just for completeness.

On Fri, Oct 29, 2010 at 2:28 AM, Olsen, Alan R <alan.r.olsen@intel.com> wrote:

> [Sorry this has taken so long. Work was been eating my time.]

> Here is my list of current outstanding issues with
> Gitosis.  I do not have fixes for these at the moment, but
> people and web indexes should be aware of the problems.
> The author of Gitosis seems to have been taken off-line.

<wink, wink> I think that is the first issue ;-)

> (The list may not be complete. I may have forgotten
> something.)

> 1. Multiple duplicate keys parsing problem

> This can happen when you have multiple people
> administering a repository. (Especially when those people
> are responsible for separate projects on the same server.

Show 7 quoted lines

> You have a.pub and b.pub. These are both the public key
> for "Bob". (The same exact key in two files.)  Any group
> that a.pub is added to Bob will have access to. Any group
> that b.pub is added to that does not contain a.pub Bob
> will not have access to.  (It seems to sort the keys and
> only sees the first occurrence of the key, not all
> occurrences.

Gitolite will do the same thing. This is an artifact of the fact that neither of them is looking *inside* the key and comparing with others, coupled with the fact that sshd does a linear scan, and when it finds a match it goes with it.

I can tell you that in gitolite, I have no intention of adding that check by comparing the contents of the keys.

However, gitolite does have "sshkeys-lint" which will catch the problem and tell you that second key will be ignored by sshd. You have to run this manually though.

> 2. Trees with working directories kills Gitosis

Show 7 quoted lines

> If any of the repositories in the repository have a
> working directory, Gitosis will fail on a push to
> gitosis-admin with a bunch of Python barfage.  (I don't
> have an example at hand, but if you look at the code, it
> is looking at ".git".) This usually happens when someone
> tries to shortcut the process by cloning code into the
> repo on the local machine.

Good. A server side repo has no business having a working tree ;-)

Gitolite was modelled after gitosis, although it's hard to imagine that now, seeing how far apart they are today.

Server side repos == bare repos. Bare repos == .git suffix as a convention in git-land. This convention becomes "standard" in gitolite.

"cloning code into the repo on the local machine" -- if I assume git clone, just add --bare maybe?

> 3. Gitosis needs to have access to everything.

> If your mount point for the repository is /repo you have
> to create a directory under this, else /repo/lost+found
> prevents Gitosis for initializing correctly. It is a
> permissions issue.

Gitolite will only care about directories ending in ".git".

> 4. Typos are deadly.

Show 8 quoted lines

> If you push a gitosis.conf file to gitosis-admin that has
> a non-parseable typo, gitosis will have problems. The
> immediate effect is that the authorized-keys file does not
> get updated. (New keys do not get added to the file, but
> existing ones work up except for the typo areas.) The only
> way to fix this is to hand-correct the copy on the server.
> Rerunning the gitosis-init script on the server will fix a
> lot of problems and does not overwrite existing configs.

What I found more problematic was it would silently ignore typos such as "member" instead of "members".

Gitolite will show you lots of errors.

You can still push up a botched-config (syntactically correct but you managed to lock yourself out by typoing your own name!), but you don't have to throw in the towel -- there is "gl-dont-panic" (written 2 months after "towel day", to my eternal regret ;-)

Sitaram