Gerrit should support private reviews for security bugs

[Thierry Carrez]

For embargoed security issues, the patch needs to be discussed in private so that we can release it with a minimal public window. Currently we use preapprovals in launchpad bugs with attached patches, then we fast-track the preapproved patches in Gerrit when the bug is public.

It would be verrrry nice to have private reviews in Gerrit to support that workflow.

[Clark Boylan (cboylan)]

Is this something that can be accomplished using the Gerrit drafts feature? When code is pushed to Gerrit using `git review -D` Gerrit will treat that push as a draft. Initially only the draft submitter can see the change in Gerrit, but other reviewers can be explicitly added. When you are ready to vote you can publish the draft (which does make it public) but by then you should be ready to fast track that voting.

http://wiki.openstack.org/GerritWorkflow#Drafts

[Thierry Carrez (ttx)]

It was suggested that "Drafts" could be used for security reviews, so I quickly investigated how secure "Drafts" actually are...
/me puts is hacker grey hat on.

Looks like it's pretty solid from Gerrit perspective... however it's pretty weak due to Git exhibiting the change.
POC: Let's say you enumerate reviews in gerrit (pretty easy, since it's sequential) and discover it 403s review number 8427:

https://review.openstack.org/#/c/8427/ -> 403

That triggers your interest. So you run:

for PROJECT in nova python-novaclient glance ... ; do echo $PROJECT; git ls-remote https://review.openstack.org/openstack/$PROJECT | grep /8427/; done

It will finally yield:

python-novaclient
1a3a9a1d73ef24584b4c20ed764fca6bd682c334 refs/changes/27/8427/1

Then you can access:

https://review.openstack.org/gitweb?p=openstack/python-novaclient.git;a=commit;h=1a3a9a1d73ef24584b4c20ed764fca6bd682c334

Oops.

[Thierry Carrez (ttx)]

Was apparently reported to Gerrit as: http://code.google.com/p/gerrit/issues/detail?id=1423
(through https://bugzilla.wikimedia.org/show_bug.cgi?id=37115)

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: openstack/2.4.1
Review: https://review.openstack.org/8622

[Thierry Carrez (ttx)]

Note that this is not gitweb-specific, since all changes seem to be replicated to github ?

git clone https://github.com/openstack/openstack-ci-puppet && cd openstack-ci-puppet
git pull https://github.com/openstack/openstack-ci-puppet refs/changes/09/8609/1

[Clark Boylan (cboylan)]

From Shawn Pearce (Gerrit Dev):
"Private changes are really hard right now in Gerrit. Its expensive to
compute branch level read access, but that is the most effective way
to do it today. The way we have handled a few of these in the past for
Gerrit itself[1] is we run a shadow gerrit-security-fixes repository
that has very selective read permission. We create a branch there,
develop a fix as necessary, make the release, and push the commits
over to the public depot.

If you make a branch for each unique security incident release, you
can open up the branch read level access after the fix is released.
This enables showing the history of that development activity after
you have reasonable assumptions that its safe to disclose this to a
wider community (e.g. after the patched binary is available for
download and installation). By using a branch for each incident that
you will make a release from, you can reduce the risk of disclosure
before the patch is completely ready. What if the fix needs 10
different changes to do the necessary work, because doing it all as a
single change is infeasible? What if those take a few weeks but you
want to submit some of it as you go along?

You mention hiding things from gitweb. This isn't possible. If the
user can call gitweb on the repository, then the user can see anything
in that repository. The only way to prevent the user from seeing such
a private change is to store the change *not* in that repository.
Which means using a shadow project like we do with the Gerrit open
source project. Or not running gitweb. Or teaching Gerrit how to
actually stitch together two different Git repositories into a single
object store so it can store the private change data in a private
shadow repository and then copy it over to the public repository when
the private change is made visible to a wider community.

FWIW, I have decided gitweb and its behavior is the problem here, and
am working on replacing it.

[1] IIRC its only be 2 in 4 years, and both are well in the past and
fixed in shipping servers. And not every installation was at risk
anyway."

https://groups.google.com/forum/?fromgroups#!topic/repo-discuss/YuLup-ELrP8