Security issues when running gerrit patches on jenkins

[Itamar Heim]

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?