Security issues when running gerrit patches on jenkins

[Eyal Edri]

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Eyal Edri" <eedri at redhat.com>
> Cc: "Robert Middleswarth" <robert at middleswarth.net>, infra at ovirt.org
> Sent: Wednesday, August 1, 2012 4:08:41 PM
> Subject: Re: Security issues when running gerrit patches on jenkins
> 
> On 08/01/2012 02:56 PM, Eyal Edri wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Robert Middleswarth" <robert at middleswarth.net>
> >> To: "Eyal Edri" <eedri at redhat.com>
> >> Cc: infra at ovirt.org
> >> Sent: Tuesday, July 31, 2012 8:35:25 PM
> >> Subject: Re: Security issues when running gerrit patches on
> >> jenkins
> >>
> >> On 07/31/2012 01:19 PM, Eyal Edri wrote:
> >>>
> >>> ----- Original Message -----
> >>>> From: "Robert Middleswarth" <robert at middleswarth.net>
> >>>> To: infra at ovirt.org
> >>>> Sent: Tuesday, July 31, 2012 7:55:49 PM
> >>>> Subject: Re: Security issues when running gerrit patches on
> >>>> jenkins
> >>>>
> >>>> On 07/31/2012 10:37 AM, Karsten 'quaid' Wade wrote:
> >>>>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>>> Hash: SHA1
> >>>>>
> >>>>> On 07/18/2012 04:05 AM, Eyal Edri wrote:> Hi,
> >>>>>> Following last infra meeting, i want to open for discussion
> >>>>>> the
> >>>>>> security issues that may arise if we allow Jenkins to run jobs
> >>>>>> (i.e
> >>>>>> any code) with every gerrit patch.
> >>>>>>
> >>>>>> - white-listing authors (published on ovirt.org?) ...
> >>>>> I think the consensus we are leaning toward is this:
> >>>>>
> >>>>> * Use a whitelist to identify who can have Jenkins jobs
> >>>>> triggered
> >>>>> when
> >>>>> a patch hits Gerrit.
> >>>>> * Keep the whitelist on the wiki, so it's clear who has access,
> >>>>> and
> >>>>> the list can be used by all Jenkins hosts.
> >>>> I would prefer wordpress to prevent someone from just adding
> >>>> themselves.
> >>>>> * Current whitelist is built from current committers (from git
> >>>>> log).
> >>>>> ** compare the whitelist with the current GERRIT_AUTHOR or
> >>>>> similar
> >>>>> value.
> >>>>>
> >>>>> Do we want to build-in the ability to check a blacklist, too?
> >>>>> Or
> >>>>> just
> >>>>> use "absence from whitelist"?
> >>>>>
> >>>>> For example, is there going to be a desire to have someone not
> >>>>> be
> >>>>> able
> >>>>> to automatically run a test on certain parts of the code, but
> >>>>> yes
> >>>>> on
> >>>>> others?
> >>>> That isn't a black list that is an itemized white list and at
> >>>> this
> >>>> stage
> >>>> I don't see a point to it.  What tests / jobs would your run
> >>>> diff
> >>>> from
> >>>> the kinda trusted list vs the completely untrusted list? It not
> >>>> like
> >>>> the
> >>>> list is going to be used to allow people to change Jenkins it is
> >>>> just
> >>>> going to be there to allow commit's to generate builds.  If we
> >>>> have a
> >>>> list of people we fell is safe enough to run test against how
> >>>> much
> >>>> more
> >>>> exposure will there be also allowing auto builds?  And if we do
> >>>> come
> >>>> up
> >>>> with test that we feel can be run on all commits we would run
> >>>> them
> >>>> on
> >>>> all not just a small subset of commits.
> >>>>
> >>> btw, this kind of logic might justify a jenkins plugin, or at
> >>> least
> >>> an extension to the gerrit trigger plugin.
> >>> it might interest other people as well.
> >> I haven't looked at the plug-in structure so if you can reuse the
> >> interface for the admin matrix and just let you select people from
> >> the
> >> people list that would be a great add-on.
> >
> > i was thinking on the specific use case of gerrit plugin, that will
> > allow triggering jobs only for certain email/user name.
> > i'll ask on jenkins list if this feature is something they consider
> > or we can contribute.
> 
> wouldn't it be easier to maintain the whitelist via a git repo on
> gerrit?

you mean instead of putting it on a wiki page? 
yes, make sense to maintain a .txt file per project with the whitelist in it.
>