Re: Security issues when running gerrit patches on jenkins

From: "Itamar Heim" <iheim(a)redhat.com&gt; To: "Eyal Edri" <eedri(a)redhat.com&gt; Cc: "Robert Middleswarth" <robert(a)middleswarth.net&gt;, infra(a)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(a)middleswarth.net&gt; >> To: "Eyal Edri" <eedri(a)redhat.com&gt; >> Cc: infra(a)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(a)middleswarth.net&gt; >>>> To: infra(a)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?