Security issues when running gerrit patches on jenkins

Robert Middleswarth robert at middleswarth.net
Tue Jul 31 17:35:25 UTC 2012


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.
>
>> Thanks
>> Robert
>>
>>> - - Karsten
>>> - --
>>> Karsten 'quaid' Wade, Sr. Analyst - Community Growth
>>> http://TheOpenSourceWay.org  .^\  http://community.redhat.com
>>> @quaid (identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.12 (GNU/Linux)
>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>>
>>> iD8DBQFQF+2d2ZIOBq0ODEERAmxqAKDNHOfAEHwfTbQz/Yubo3iApBdUYwCePkPC
>>> D9M+eLnNAaUv2Y0+yVWA+3o=
>>> =HmZo
>>> -----END PGP SIGNATURE-----
>>> _______________________________________________
>>> Infra mailing list
>>> Infra at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/infra
>>
>> --
>> Thanks
>> Robert Middleswarth
>> @rmiddle (twitter/IRC)
>>
>> _______________________________________________
>> Infra mailing list
>> Infra at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/infra
>>


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




More information about the Infra mailing list