Re: Security issues when running gerrit patches on jenkins

----- Original Message ----- > 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? 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.