Bugs in Gitosis

Bugs in Gitosis

[Olsen, Alan R]

[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. (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.

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. 

2. Trees with working directories kills Gitosis

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.

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.

4. Typos are deadly.

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.

Those are the ones I can remember at the moment.  As soon as I send this I will remember more.

Hope this helps.

Re: Bugs in Gitosis

[Matthieu Moy]

"Olsen, Alan R" <alan.r.olsen@intel.com> writes:

> 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. (The list may not be complete. I may have
> forgotten something.)

For completeness (but I think you know it already): gitolite is an
alternative to gitosis, and it is maintained.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

RE: Bugs in Gitosis

[Olsen, Alan R]

>From: Matthieu Moy [mailto:Matthieu.Moy@grenoble-inp.fr] 
>Sent: Thursday, October 28, 2010 2:43 PM
>To: Olsen, Alan R
>Cc: git@vger.kernel.org
>Subject: Re: Bugs in Gitosis

>"Olsen, Alan R" <alan.r.olsen@intel.com> writes:

>> 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. (The list may not be complete. I may have
>> forgotten something.)

>For completeness (but I think you know it already): gitolite is an
>alternative to gitosis, and it is maintained.

Does gitolite play well with Gerrit? I note in the docs that it does not react well to files under its control being messed with.

Re: Bugs in Gitosis

[Sitaram Chamarty]

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

> Does gitolite play well with Gerrit? I note in the docs that it does not react well to files under its control being messed with.

For the real reason I added that into the docs, see
http://github.com/sitaramc/gitolite/commit/10289c6d6494e7aa4204dfe29afec7535c1aa1a2

If <any other software> wants to add *other* files into repos that
gitolite does not need, that is perfectly fine.  Gitolite does not
expect to be "sole control", but just "don't mess with my stuff and
we'll get along fine".

However, I wasn't aware that it is even *possible* to run gerrit and
gitolite together.  Gerrit has its own customised ssh daemon, its own
customised "git", and so on.

I also fail to understand why you need gitolite if you're using
gerrit.  I believe gerrit can do all the access control that gitolite
can do.  See http://github.com/sitaramc/gitolite/blob/pu/contrib/gerrit.mkd
for a comparision

regards

sitaram

RE: Bugs in Gitosis

[Olsen, Alan R]

>-----Original Message-----
>From: Sitaram Chamarty [mailto:sitaramc@gmail.com] 
>Sent: Thursday, October 28, 2010 5:02 PM
>To: Olsen, Alan R
>Cc: Matthieu Moy; git@vger.kernel.org
>Subject: Re: Bugs in Gitosis

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

>> Does gitolite play well with Gerrit? I note in the docs that it does not react well to files under its control being messed with.

>For the real reason I added that into the docs, see
>http://github.com/sitaramc/gitolite/commit/10289c6d6494e7aa4204dfe29afec7535c1aa1a2

>If <any other software> wants to add *other* files into repos that
>gitolite does not need, that is perfectly fine.  Gitolite does not
>expect to be "sole control", but just "don't mess with my stuff and
>we'll get along fine".

>However, I wasn't aware that it is even *possible* to run gerrit and
>gitolite together.  Gerrit has its own customised ssh daemon, its own
>customised "git", and so on.

Gerrit runs its ssh daemon on another port. If you run them both as the same user, it works fine.

>I also fail to understand why you need gitolite if you're using
>gerrit.  I believe gerrit can do all the access control that gitolite
>can do.  See http://github.com/sitaramc/gitolite/blob/pu/contrib/gerrit.mkd
>for a comparision

We use gitosis currently for back-end management.

Gerrit does not add existing projects well. Pushing the kernel project into Gerrit causes one entry to approve per commit. That swamps the server. Gerrit does not have a way of handling rebases very well.  (We have projects that have a regular consolidation on the end of the development trees.)

There are also some people (me for example) who loath the Repo command and prefer to work using git.

I am hoping we can migrate to Gitolite. I am going to set up a test server to see if I can identify problems.

Re: Bugs in Gitosis

[Shawn O. Pearce]

"Olsen, Alan R" <alan.r.olsen@intel.com> wrote:
> 
> Gerrit does not add existing projects well. Pushing the kernel
> project into Gerrit causes one entry to approve per commit. That
> swamps the server.

Don't push to refs/for/master.  Grant yourself Push Branch +1
(or +2 if you need to create the branch) and push directly to
refs/heads/master like you would with Gitolite, Gitosis or any
other Git repository.  Gerrit won't create a change record, and
thus won't be swamped.

> Gerrit does not have a way of handling rebases
> very well.  (We have projects that have a regular consolidation on
> the end of the development trees.)

I think it handles rebases about as well as any other Git tool, you
need to enable Push +3 to permit force push/rewind of the relevant
branches, and then actually do the force push.  Any pending commit
will need to be rebased.  Which is also true for just about any
workflow except the classic Linux kernel "format-patch and email"
model.  Switching to gitolite probably won't easy the rebase pain.

FWIW, the Google kernel developers have their Gerrit instance
configured to use the cherry-pick submit type on their kernel
repositories, which makes changes submittable across rebases,
because its emulating the format-patch->email->am workflow that
is traditionally used for kernel development.

> There are also some people (me for example) who loath the Repo
> command and prefer to work using git.

I'm also among those people, as are many of Google's kernel
developers.  We just use git push to talk to Gerrit... and
that is one of the primary reasons it embeds its own SSHD.

-- 
Shawn.

Re: Bugs in Gitosis

[Sitaram Chamarty]

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.

> 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

> 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.

> 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

Re: Bugs in Gitosis

[Sitaram Chamarty]

Hi Shawn,

On Fri, Oct 29, 2010 at 7:36 AM, Shawn Pearce <spearce@spearce.org> wrote:
> On Oct 28, 2010 5:02 PM, "Sitaram Chamarty" <sitaramc@gmail.com> wrote:

>> can do.  See
>> http://github.com/sitaramc/gitolite/blob/pu/contrib/gerrit.mkd
>> for a comparision
>
> There are a few inaccuracies in that document that I would like to correct.

well, updates I guess; I did update one part of it based on our IRC
conv, but if there's more I'll put those in too.

> For starters we now support regex patterns in branch access control rules.

ok; will update.

> We also now allow $(username) in a pattern to mean the current user and thus
> permit per-developer branches.

Right; gitolite uses /USER/; it's only a syntax difference but I'll
mention it somewhere.

> We don't allow per-user access rules because in the corporate world its
> usually a bad idea to have only one user with a particular set of
> permissions. What happens when the user leaves the project or is hit by a
> bus? Of course this also applies to most open projects too... :-)

You do the same thing in either case, no?  Take out the old guy's name
from somewhere, put in the new guy's name?

But yeah, I'll amend this to say this is a subjective opinion :-)

> We also allow importing a user's groups from an organization's LDAP server.
> This can be useful when there are thousands of users on a single server and
> the org wants to continue using their existing access controls.

Except in gitolite it's not an import; it's more like "give me a
program that, given a userid, returns a list of groups he belongs to"
and gitolite calls that if it's specified.

> But after that, yes, that document is a good summary of the features that
> both tools offer... and I know many companies really do salivate over the
> branch level read access rules. It is difficult to do for Git, but it also
> can be useful to have everything in a single location.

Probably.  But where that restriction exists, I may have to show the
auditors that the restriction holds, and that's a lot easier to do
when they're in separate repos to begin with.

-- 
Sitaram