Fixing Code Reviews

[Laszlo Papp]

> From the Ben's email:
> "- Gerrit operates with the assumption it has permission to push to the
> master repositories, providing a security vulnerability to our
> infrastructure."
>
> Could someone please ellaborate on that a little bit more ? I am
> unsure what "master repositories" means, but:

Let me answer my question after a bit of discussion with Ben. :-)

"master repositories" means the canonical copy on git.kde.org
(original and central versions).

There are a couple of workflow related things I have been really
enjoying since contributing to Qt via Gerrit:

1) I can use "git push" and the patch is instantly under review. I can
even assign reviewers while pushing, but that operation is also very
simple via the web interface to add further reviewers.
2) It is very simple to update a change in most cases; it is just the
matter of "git commit --amend," and then "git push" again.
3) I can fetch the change for testing on a variety of platforms and
circumstances as a reviewer for instance by using "git fetch" with the
given link on the page, and then either "git apply" or "git am".
4) The change can be put into staging state (staging branches) so that
there is a proper testing procedure before integrating a change
(proper CI).
5) I can merge or stage the change via the webinterface, simply a
button for this goal, right after saying "Ship it!".

There might be other benefits I have not discovered yet, but these are
already handy and very useful. Meanwhile 1-4 would not mean any
"security holes", there is a bit of doubt amongst people about the
fifth point. Merging the change from the webinterface would mean that
we trust Gerrit because Gerrit would have to possess write access to
the master repositories. Those are normally read-only, and only people
with KDE Developer Accounts can have write access for pushing. I
believe the thoughts might be shared whether or not it is a valid
reason to deny that functionality of gerrit in comparison with the
usefulness of the operation in question (especially because there are
many unused KDE Developer Accounts out there with ssh keys on a
non-encrypted filesystem, etc).

Just for making sure it is clear enough: it is not only a KDE
Infrastructure "security hole", but more or less for any projects
using Gerrit: Qt5, Mer and so forth. It seems to me that, some people
are more worried about the security in here than in other projects. To
make myself clear: I am not saying it is bad or good! I am just
providing facts. I am not about to judge these opinions!

At any rate, a compromised gerrit would be a good base for
experimenting: first three functionalities, no fourth-fifth at this
point. As I have been told there are certain people establishing this
environment for their subprojects in KDE, so we will see the results.
Unfortunately, not much work has been done recently about this
procedure, but it is at least in plans.

I am personally looking forward to seeing the results and opinions
once the reduced gerrit functionality set is tested.

Best Regards,
Laszlo Papp