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 https://gitweb.gentoo.org/repo/gentoo.git/ 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 well. 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
