Security issues when running gerrit patches on jenkins

[Itamar Heim]

On 08/01/2012 04:35 PM, Robert Middleswarth wrote:
> 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.

i don't think we need a per project list, we can start with one list.
was just thinking if you want a plugin, you'll need to point it to a 
file/git repo with the list, rather than to a wiki.

>