[Kde-scm-interest] Integrating Reviewboard with git branches

Thomas Koch thomas at koch.ro
Tue Feb 5 08:44:59 UTC 2013


Hi all,

Ben Cooksley:
> > there is no higher risk of screwin up the repos than with any other git
> > server.
> 
> See what happened to Github and Rails. The web frontend was
> compromised and an unauthorised person was able to push code directly
> into the Rails repository.

Are you referring to [1][2]? I don't know the current Git setup of KDE, 
whether it has any web frontend that allows to configuration. Gerrit would add 
a web frontend to configure access control and thus enlarges the attack 
surface. That is the regular trade-of between convenience and security. But I 
think that a proper risk/benefits analysis here would be in favour of gerrit.

[1] http://lwn.net/Articles/485675
[2] http://shiflett.org/blog/2012/mar/hacking-rails-and-github

> While I don't have a problem with delegating certain levels of access,
> I do have a problem with granting access to all developers to
> administer all repositories, as this would allow manipulation of the
> sysadmin/* and websites/* repositories, which are protected for very
> good reasons. I doubt Gerrit supports delegating access to create
> repositories which is limited by a regular expression (which is
> basically how Gitolite works at the moment).

From: http://gerrit-
documentation.googlecode.com/svn/Documentation/2.5.1/access-control.html

"References can have the current user name automatically included, creating 
dynamic access controls that change to match the currently logged in user. For 
example to provide a personal sandbox space to all developers, 
refs/heads/sandbox/${username}/* allowing the user joe to use 
refs/heads/sandbox/joe/foo."

So you can give a user the create-project right limited by a regular 
expression.

> Until otherwise known, the policy of direct pushes being inviolable
> remains a requirement of all repositories on git.kde.org.
The permission to push directly without reviews can be configured separately 
for each project.

> No, Gitolite detects when it is dealing with a Subversion client and
> invokes the appropriate Subversion server side components and then
> ignores everything else (ie. it performs no access control handling,
> other than that already done by SSH itself, which Gitolite assists in
> managing conveniently).
This might be a more complicate requirement and requires some thought. But I'm 
certain that we can develop a solution.

> To the best of my knowledge, the Git focused Gerrit does not support
> this at all. Having two SSH servers (as Gerrit does everything itself)
> on the same system is just asking for trouble and confusion.
Gerrits SSH server does not listen on port 22 but on port 29418 and thus 
should not interfer with any other SSH daemon on the same machine.

Please have a look at the list of Gerrit users[3], most notable the free 
software projects eclipse, libreoffice, QT and Typo3. There's a very high 
probability that this projects have similar requirements like KDE and have 
already found solutions for those. So at least this might serve as an 
encouragement to give gerrit a try and set up a test installation.

[3] http://en.wikipedia.org/wiki/Gerrit_%28software%29#Notable_Gerrit_users

Best regards,

Thomas Koch, http://www.koch.ro


More information about the Kde-scm-interest mailing list