Patrice Clement posted on Mon, 02 Nov 2015 11:28:10 +0100 as excerpted:

> By reading your answer, I'm not sure if it is clear or obvious for most
> users how the workflow between the Gentoo infra <-> Github infra
> functions so maybe we should explain it one more time: [...]

> 4) How do we merge it? We do *NOT* make use of the "Merge" button Github
> offers (and never will). Why? Changes would get lost in the wind if we
> did so, since the repository sitting on the Github infra is merely a
> mirror. Instead, we pull each PR into our own local copy of the Gentoo
> git repository hosted at and
> then merge them.

FWIW I understood the github sequence... but in this particular context 
was discussing gerrit specifically, not github.  But not everyone might 
have understood it, so it doesn't hurt repeating in any case.

> Now, with this explanation out of the way, I'm not sure what you mean by
> the "security threat" issue you've brought up your email.
> Gerrit is a code-review web platform that CAN allow commits to be
> merged, but this privilege has to be granted to specific users (like
> Github). It is really up to us and how infra want to manage merging. It
> doesn't make Gerrit less or more secure IMHO. This is a biased argument.

But... while individual gerrit-registered users get commit grants, it's 
actually the (non-hardened/non-audited java) gerrit instance controlling 
authentication and doing the merges, using the single /system/ gerrit 
user.  The authentication and merges don't go thru the well audited and 
on gentoo infra, hardened, system user authentication, it's the much 
softer (from infra's viewpoint) stack of code, both java runtime and 
gerrit java code, that's doing the merges there, with only the one actual 
system user (the one gerrit runs as) doing the merges into gerrit's copy 
of the git repo.  From the posts I've seen, they'd be far more 
comfortable if the individual commits were by individual system level 
users, authenticated via hardened system authentication, not the stack of 
gerrit/java code with who knows what vulns, running on a publicly 
accessible server where those vulns are to some degree exposed to the 
world as the same gerrit subsystem parsing potentially untrusted world-
submitted content that could trigger those vulns is doing the 
authentication as well.

Tho as I said, if no actual commits could be done via gerrit, so its copy 
of the repo is effectively one-way synced to it from the gentoo master 
repo, similar to the way github's repo copy is only one-way synced from 
the master repo and user submitted commits are pulled to local and 
committed/pushed from there, that would lessen the direct danger to some 
degree.  But that would lessen the utility/convenience to some degree as 

Meanwhile, it would still only deal with one of the two security-related 
factors that it's my understanding have gentoo infra vetoing the gerrit 
idea entirely.  The other one, that they simply don't trust java, and 
gerrit is java based, remains unaddressed, and AFAICT unaddressable.  Tho 
it's possible I read that wrong or remember it wrong.  But to verify that 
either way would have to be done directly by infra, and their attention 
resources are limited, thus my attempt to explain.

But if you look at the back list, doing a search on gerrit, you'll see 
what infra (and others) actually said, unfiltered by my admittedly 
imperfect relaying.  Perhaps that will change things, but I obviously 
don't believe so or I'd not be taking the pains to try to pass on what I 
understood to be their take on things.

OTOH, to this point the biggest gerrit booster has been a non-dev gentoo 
user.  Your boosting as a dev could improve the chances some, but it'll 
still be a pretty tough row to hoe.

The other alternative would be to get someone to donate the hardware and 
third-party administrate an instance for gentoo, bypassing infra for the 
most part as they wouldn't be controlling the hardware, but while gerrit 
is OSS and thus more GSC compliant, such an instance still wouldn't be 
gentoo controlled, and the resources available would be far lower than 
github, so the effective trade would be a small single-instance that's 
likely less longterm reliable but OSS, against the global level but 
proprietary resources of github, so while a different tradeoff, it'd 
hardly be a better or more reliable one.  Which pretty much leaves us 
exactly where we were, with gerrit/java up against a wall of infra 
opposition that's going to be hard to break down.

Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Reply via email to