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@redhat.com> To: "Eyal Edri" <eedri@redhat.com> Cc: "Robert Middleswarth" <robert@middleswarth.net>, infra@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@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
----- 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 > > 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
On 07/31/2012 01:19 PM, Eyal Edri wrote: 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.