On 08/01/2012 02:56 PM, Eyal Edri wrote:
----- Original Message -----
From: "Robert Middleswarth" <robert@middleswarth.net> To: "Eyal Edri" <eedri@redhat.com> Cc: infra@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@middleswarth.net> To: infra@ovirt.org Sent: Tuesday, July 31, 2012 7:55:49 PM Subject: Re: Security issues when running gerrit patches on jenkins
-----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
* 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
On 07/31/2012 10:37 AM, Karsten 'quaid' Wade wrote: themselves. 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?