On Tue, Feb 5, 2013 at 9:44 PM, Thomas Koch <tho...@koch.ro> wrote: > 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.
That is the incident I was referring to. There is no web based configuration system in use by KDE for Gitolite. We do use generated configuration files from projects.kde.org - but the diff is reviewed prior to being made active by a Sysadmin and adding a non-developer as a repository administrator would have no effect (because their keys would not be included, as they are handled separately). The extra permissions granted to a repository administrator are trivial (namely the capability to delete branches) and are nullified as a risk to data security to a certain extent in any case (all destructive operations on git.kde.org repositories lead to the automatic creation of backup refs under refs/backups/) and repositories must be deleted by hand with Gitolite. > > [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." That is referring to repository refs - rather than the creation of actual repositories. See quickgit.kde.org for a list of scratch and clone repositories currently present. > > So you can give a user the create-project right limited by a regular > expression. >From my interpretation of the documentation, the create-project right was a global, administrative right - rather than one controlled by the "project access controls". > >> 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. The issue would lie with the client side more than the server side. We would likely have to use two hostnames at a bare minimum, otherwise people will have problems when pushing due to ~/.ssh/config entries needed to simplify interaction with Gerrit. > > 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. >From what I can tell, Gerrit expects to be the master instance of a repository, which makes testing it quite difficult without disrupting our existing systems in any form. > > [3] http://en.wikipedia.org/wiki/Gerrit_%28software%29#Notable_Gerrit_users > > Best regards, > > Thomas Koch, http://www.koch.ro Regards, Ben _______________________________________________ Kde-scm-interest mailing list Kde-scm-interest@kde.org https://mail.kde.org/mailman/listinfo/kde-scm-interest
