[OpenStack-Infra] Fwd: RFC: Workflow for gerrit security patches

Jeremy Stanley fungi at yuggoth.org
Tue Oct 8 16:54:56 UTC 2013


On 2013-10-08 08:28:28 -0700 (-0700), Clark Boylan wrote:
> It would be possible to teach git review to push to a second remote
> with an option. Personally I almost prefer having two clones so that
> you don't have to remember to use a special option (just thinking
> about preventing accidental pushes to the public gerrit). Curious to
> hear what Fungi thinks about an option like this for git review.

As Jim points out later in the thread, this is already doable with
-r but I agree that I'll be more likely to have a separate
"security" clone with manually updated git remotes and then git
review -r public instead (just so I don't accidentally publish an
embargoed change while rebasing it or something).

> At the Portland summit I think we decided that adding shadow test
> infra would be too much work, so no check tests.

Yes, in short, we really don't have a good way to secretly test
these in an automated fashion, since we'd need to have zuul not
display them on its public status, build a non-publicly-accessible
Jenkins master which would have its own dedicated slaves and
nodepool target, set up a secured alternate location for the logs
and so on.

> The reason we have potential leaks here is we allow Anonymous users
> read access to our repositories. On the secure Gerrit we would give
> the VMT group read access by default then for each project expand that
> to a project specific group. This doesn't completely eliminate the
> potential for leaks but limits them to people we in theory already
> trust for a given project.

We'd also disable gitweb, which was the other main leak.
-- 
Jeremy Stanley



More information about the OpenStack-Infra mailing list