----- Original Message ----- > From: "Itamar Heim" <[email protected]> > To: "Eyal Edri" <[email protected]> > Cc: "Robert Middleswarth" <[email protected]>, [email protected] > 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" <[email protected]> > >> To: "Eyal Edri" <[email protected]> > >> Cc: [email protected] > >> 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" <[email protected]> > >>>> To: [email protected] > >>>> 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. > _______________________________________________ Infra mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/infra
