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

[Oswald Buddenhagen]

On Tue, Feb 05, 2013 at 01:09:10PM +1300, Ben Cooksley wrote:
> On Tue, Feb 5, 2013 at 12:15 PM, Oswald Buddenhagen <ossi at kde.org> wrote:
> > i don't see how gerrit's built-in webserver should be inherently less
> > secure than all the other systems we have running.
> 
> Currently, any changes to access controls or the addition of SSH keys
> requires that they be manually synced by a Sysadmin.
> As such, our system is only accessible via SSH, which is a much
> smaller level of exposure. The master Git repositories are not web
> accessible.
> 
ok, let's assume gerrit is less secure by design (the only plausible
reason for this being that it is a monolithic java application, rather
than three separate severs running under separate unix accounts).

the data can be mirrored to a second server (anongit, if nothing else)
in realtime, including a target-side reflog. that means that no
information can be lost, no matter how destructive the attack.

the manual addition of ssh keys is a non-feature. the process can be
bypassed easily enough with some minor social engineering.
unauthorized privilege escalation can be quickly detected post-fact by
implementing watches on the relevant config files (which are stored in
git themselves) and database tables.
also, manipulating the access controls is no particularly effective way
to get something in unnoticed. and if i didn't care about being
unnoticed, i'd just get an account - we are talking about kde here,
after all.

> > there is absolutely no reason why there cannot be a web frontend for the
> > administrative functions.
> 
> You missed my point. Keyword is 'Administrator' - ie. you would have
> to ask a Sysadmin to setup even a scratch repository for you.
> 
no, you missed the point. the frontend can use a gerrit account which
has administrative rights, and impose access restrictions via its own
logic. *every* layer of security works like that.

> > in fact, i'd strongly recommend *against* allowing direct pushes (to
> > the baseline branches). [...]
> 
> If you want to implement such policy, it will have to be referred for
> extensive review on kde-core-devel, as well as other project specific
> mailing lists.  It constitutes a core change to our workflow which no
> individual or particular group within KDE has the right to impose upon
> others.
> 
sure it would need discussion. well, actually, it would need a dictate,
and appeasing the nay-sayers. as always, when something perfectly
reasonable is done which involves a change.

> Until otherwise known, the policy of direct pushes being inviolable
> remains a requirement of all repositories on git.kde.org.
> 
as usual, you are putting way too much political meaning to the current
technical implementation. the core value is the ability to get code into
all repositories easily, not the particular fact that you do that with a
direct push.

> 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).
> 
> 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.
> 
it's beyond me why svn.kde.org and git.kde.org must be the same server,
and how this not being the case is in any way confusing.