Security issues when running gerrit patches on jenkins

[Robert Middleswarth]

On 08/01/2012 09:31 AM, Eyal Edri wrote:
>
> ----- 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.

Actually makes a lot more since.  That allows the projects the ability 
to manage there own list.

-- 
Thanks
Robert Middleswarth
@rmiddle (twitter/IRC)