Open Stack

Zaro wrote:
> We are getting close to standing up a private gerrit instance for
> security reviews (https://bugs.launchpad.net/openstack-ci/+bug/1083101).
>  As mentioned in the bug our plan is to run a second gerrit to
> facilitate code review for embargoed patches. But we will not run an
> entire second shadow environment (too much effort for ~50 patches a year). 

That's awesome ! Thanks for working on it.

> A few of the implementation details were unclear so I would like to make
> a proposal and get feedback before continuing to work on the bug.
> 
> A few members of infra team had a discussion on the workflow and fungi
> proposed the following..
> 1. git clone from security gerrit  (review-security.o.o)
> 2. git review patch to security gerrit 
> 3. The patch is review-able by  vmt member, change owner and any
> manually added reviewer.
> 4. patch is reviewed and approved on review-security.o.o
> 5. patch is copied from security gerrit to public gerrit..  
>      a. git review -d from review-security.o.o
>      b*. git review to review.o.o
> 
> *Note - security review information (votes/notes/etc..) will not get
> copied to review.o.o
> 
> Does this seem like the right workflow for approving and integrating
> security patches?

That sounds perfectly acceptable. A few questions:

- would it be possible to reuse a classic repo clone (from git.o.o) and
add an option to git review to submit to the security gerrit ? Otherwise
we have to teach security patch developers to use specific clones from
security gerrit before they work on security patches ?

- do we have the ability to run check tests (no gate tests) ?

- could you briefly explain how you addressed the potential leaks
identified in gerrit (ability to download arbitrary changes from a
guessed review number, etc) ?

> We are also proposing that, instead of syncing accounts from public
> gerrit to security gerrit, we shoud keep the accounts independent for
> the following reasons:
> 1. It would make it a little harder to unintentionally push to the wrong
> gerrit.
> 2. Some people might want to configure their account profiles
> differently on each gerrit (something like project watches).  
> 3. It will minimize the potential for leakage.
> 4. Syncing accounts requires more management overhead.
> 
> With the above proposals we would replicate the gerrit git repository
> from review.o.o to review-security.o.o but NOT the gerrit database.  

Would that mean that everyone has to specifically create an account in
the security Gerrit (i.e. log in there once) before they can be
subscribed to an arbitrary review ? Or just that the accounts are kept
separate ? It might be inconvenient to have to ask everyone to join
first, in order to get all the right people available for review help
later...

Cheers,

-- 
Thierry Carrez (ttx)