On Wed, Jul 18, 2012 at 07:05:16AM -0400, 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. > > The problem: > > In theory, any user that is registered to gerrit might send a > patch to any ovirt project. That code might contain malicious > code, malware, harmfull or just not-related ovirt code that he > wants to use our resources for it. Even though we use limited > sudo on hosts, we can't be sure an exploit will be used against > one of the jenkins slaves. > > > The proposed solutions: > > - black-listing authors (published on ovirt.org?) - white-listing > authors (published on ovirt.org?) - auto approve patch via > comparing to lastest commits - check if author recent patches > were approved in the past? > > adding dan since he raised this issue when we wanted to add vdsm > gerrit tests. In my opinion, we can trust anyone who has already contributed code to the relevant project. We can even say: someone who contributed more than 3 commits over a month ago.

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFQBsrp2ZIOBq0ODEERAlfyAKDiJCl6RLXVQluAw9hsX9Uc4ftzMgCgjH6G 0Ejk6rXviSMbc+oiKVTjMUs= =3Hf2 -----END PGP SIGNATURE-----

From: "Robert Middleswarth" <robert(a)middleswarth.net&gt; To: infra(a)ovirt.org Sent: Wednesday, July 18, 2012 8:00:44 PM Subject: Re: Security issues when running gerrit patches on jenkins On 07/18/2012 10:40 AM, Karsten 'quaid' Wade wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/18/2012 06:20 AM, Dan Kenigsberg wrote: >> On Wed, Jul 18, 2012 at 07:05:16AM -0400, 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. >>> >>> The problem: >>> >>> In theory, any user that is registered to gerrit might send a >>> patch to any ovirt project. That code might contain malicious >>> code, malware, harmfull or just not-related ovirt code that he >>> wants to use our resources for it. Even though we use limited >>> sudo on hosts, we can't be sure an exploit will be used against >>> one of the jenkins slaves. >>> >>> >>> The proposed solutions: >>> >>> - black-listing authors (published on ovirt.org?) - white-listing >>> authors (published on ovirt.org?) - auto approve patch via >>> comparing to lastest commits - check if author recent patches >>> were approved in the past? >>> >>> adding dan since he raised this issue when we wanted to add vdsm >>> gerrit tests. >> In my opinion, we can trust anyone who has already contributed >> code >> to the relevant project. We can even say: someone who contributed >> more than 3 commits over a month ago. > This seems like a reasonable approach. Trust people first, and it's > fine to have a method to untrust people if the need arises. That > shouldn't surprise or disappoint anyone - it's just simple sanity. > > The alternatives are to build untrust in to the process from the > start, which becomes a barrier to getting things done, and > perpetuates > a culture of untrust. > > I just remind myself, if someone is going to worm their way in to > our > trust to run malicious code on our Jenkins instances, there is so > much > more damage they can do with that trust. > > Trust is like fertilizer, water, and sunshine in the garden - it > makes > amazing things grow. :) I am on the opposite side of this issue. Maybe I have been attacked by 1 to many bot's or been a manager when someone I know and trusted stole from the company. I need trust to be earned so I +1 on whitelist. With that said I think getting on the whitelist should be pretty easy. We are not talking about blocking there commit's we are talking about should the automated system run test/code against there patch. I am still learning Jekins when using a whitelist is there a way to flag commits for users not in the list? I wonder if there is some way to create a list that someone can go though and whitelist the user or reject the user for commits not in the whitelist?

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 > > > _______________________________________________ > Infra mailing list > Infra(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra _______________________________________________ Infra mailing list Infra(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/infra

From: "Mike Burns" <mburns(a)redhat.com&gt; To: "Eyal Edri" <eedri(a)redhat.com&gt; Cc: "Robert Middleswarth" <robert(a)middleswarth.net&gt;, infra(a)ovirt.org Sent: Wednesday, July 18, 2012 8:45:05 PM Subject: Re: Security issues when running gerrit patches on jenkins On Wed, 2012-07-18 at 13:03 -0400, Eyal Edri wrote: > > ----- Original Message ----- > > From: "Robert Middleswarth" <robert(a)middleswarth.net&gt; > > To: infra(a)ovirt.org > > Sent: Wednesday, July 18, 2012 8:00:44 PM > > Subject: Re: Security issues when running gerrit patches on > > jenkins > > > > On 07/18/2012 10:40 AM, Karsten 'quaid' Wade wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > On 07/18/2012 06:20 AM, Dan Kenigsberg wrote: > > >> On Wed, Jul 18, 2012 at 07:05:16AM -0400, 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. > > >>> > > >>> The problem: > > >>> > > >>> In theory, any user that is registered to gerrit might send a > > >>> patch to any ovirt project. That code might contain malicious > > >>> code, malware, harmfull or just not-related ovirt code that > > >>> he > > >>> wants to use our resources for it. Even though we use limited > > >>> sudo on hosts, we can't be sure an exploit will be used > > >>> against > > >>> one of the jenkins slaves. > > >>> > > >>> > > >>> The proposed solutions: > > >>> > > >>> - black-listing authors (published on ovirt.org?) - > > >>> white-listing > > >>> authors (published on ovirt.org?) - auto approve patch via > > >>> comparing to lastest commits - check if author recent patches > > >>> were approved in the past? > > >>> > > >>> adding dan since he raised this issue when we wanted to add > > >>> vdsm > > >>> gerrit tests. > > >> In my opinion, we can trust anyone who has already contributed > > >> code > > >> to the relevant project. We can even say: someone who > > >> contributed > > >> more than 3 commits over a month ago. > > > This seems like a reasonable approach. Trust people first, and > > > it's > > > fine to have a method to untrust people if the need arises. > > > That > > > shouldn't surprise or disappoint anyone - it's just simple > > > sanity. > > > > > > The alternatives are to build untrust in to the process from > > > the > > > start, which becomes a barrier to getting things done, and > > > perpetuates > > > a culture of untrust. > > > > > > I just remind myself, if someone is going to worm their way in > > > to > > > our > > > trust to run malicious code on our Jenkins instances, there is > > > so > > > much > > > more damage they can do with that trust. > > > > > > Trust is like fertilizer, water, and sunshine in the garden - > > > it > > > makes > > > amazing things grow. :) > > I am on the opposite side of this issue. Maybe I have been > > attacked > > by > > 1 to many bot's or been a manager when someone I know and trusted > > stole > > from the company. I need trust to be earned so I +1 on > > whitelist. > > With > > that said I think getting on the whitelist should be pretty easy. > > We > > are not talking about blocking there commit's we are talking > > about > > should the automated system run test/code against there patch. I > > am > > still learning Jekins when using a whitelist is there a way to > > flag > > commits for users not in the list? I wonder if there is some way > > to > > create a list that someone can go though and whitelist the user > > or > > reject the user for commits not in the whitelist? > > > > i've never done this in the past. > i assume we'll need to read the author email/name from the gerrit > patch (before running the code) > wget the whitelist page from ovirt.org and match it.. > > or alternatively run git log and search it there... > > if there isn't a match, fail the job before running any code. No, I don't think we want to have failures in the main build job. What about a separate job that verifies the patch submitter, then triggers the build job. Would probably need to pass the GERRIT_REFSPEC variable between the 2 builds somehow.

Mike > > > 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 > > > > > > > > > _______________________________________________ > > > Infra mailing list > > > Infra(a)ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/infra > > > > _______________________________________________ > > Infra mailing list > > Infra(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > _______________________________________________ > Infra mailing list > Infra(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra

From: "Robert Middleswarth" <robert(a)middleswarth.net&gt; To: "Eyal Edri" <eedri(a)redhat.com&gt; Cc: "Mike Burns" <mburns(a)redhat.com&gt;, infra(a)ovirt.org Sent: Wednesday, July 18, 2012 10:17:36 PM Subject: Re: Security issues when running gerrit patches on jenkins On 07/18/2012 03:10 PM, Eyal Edri wrote: > > ----- Original Message ----- >> From: "Mike Burns" <mburns(a)redhat.com&gt; >> To: "Eyal Edri" <eedri(a)redhat.com&gt; >> Cc: "Robert Middleswarth" <robert(a)middleswarth.net&gt;, >> infra(a)ovirt.org >> Sent: Wednesday, July 18, 2012 8:45:05 PM >> Subject: Re: Security issues when running gerrit patches on >> jenkins >> >> On Wed, 2012-07-18 at 13:03 -0400, Eyal Edri wrote: >>> ----- Original Message ----- >>>> From: "Robert Middleswarth" <robert(a)middleswarth.net&gt; >>>> To: infra(a)ovirt.org >>>> Sent: Wednesday, July 18, 2012 8:00:44 PM >>>> Subject: Re: Security issues when running gerrit patches on >>>> jenkins >>>> >>>> On 07/18/2012 10:40 AM, Karsten 'quaid' Wade wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> On 07/18/2012 06:20 AM, Dan Kenigsberg wrote: >>>>>> On Wed, Jul 18, 2012 at 07:05:16AM -0400, 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. >>>>>>> >>>>>>> The problem: >>>>>>> >>>>>>> In theory, any user that is registered to gerrit might send a >>>>>>> patch to any ovirt project. That code might contain malicious >>>>>>> code, malware, harmfull or just not-related ovirt code that >>>>>>> he >>>>>>> wants to use our resources for it. Even though we use limited >>>>>>> sudo on hosts, we can't be sure an exploit will be used >>>>>>> against >>>>>>> one of the jenkins slaves. >>>>>>> >>>>>>> >>>>>>> The proposed solutions: >>>>>>> >>>>>>> - black-listing authors (published on ovirt.org?) - >>>>>>> white-listing >>>>>>> authors (published on ovirt.org?) - auto approve patch via >>>>>>> comparing to lastest commits - check if author recent patches >>>>>>> were approved in the past? >>>>>>> >>>>>>> adding dan since he raised this issue when we wanted to add >>>>>>> vdsm >>>>>>> gerrit tests. >>>>>> In my opinion, we can trust anyone who has already contributed >>>>>> code >>>>>> to the relevant project. We can even say: someone who >>>>>> contributed >>>>>> more than 3 commits over a month ago. >>>>> This seems like a reasonable approach. Trust people first, and >>>>> it's >>>>> fine to have a method to untrust people if the need arises. >>>>> That >>>>> shouldn't surprise or disappoint anyone - it's just simple >>>>> sanity. >>>>> >>>>> The alternatives are to build untrust in to the process from >>>>> the >>>>> start, which becomes a barrier to getting things done, and >>>>> perpetuates >>>>> a culture of untrust. >>>>> >>>>> I just remind myself, if someone is going to worm their way in >>>>> to >>>>> our >>>>> trust to run malicious code on our Jenkins instances, there is >>>>> so >>>>> much >>>>> more damage they can do with that trust. >>>>> >>>>> Trust is like fertilizer, water, and sunshine in the garden - >>>>> it >>>>> makes >>>>> amazing things grow. :) >>>> I am on the opposite side of this issue. Maybe I have been >>>> attacked >>>> by >>>> 1 to many bot's or been a manager when someone I know and >>>> trusted >>>> stole >>>> from the company. I need trust to be earned so I +1 on >>>> whitelist. >>>> With >>>> that said I think getting on the whitelist should be pretty >>>> easy. >>>> We >>>> are not talking about blocking there commit's we are talking >>>> about >>>> should the automated system run test/code against there patch. >>>> I >>>> am >>>> still learning Jekins when using a whitelist is there a way to >>>> flag >>>> commits for users not in the list? I wonder if there is some >>>> way >>>> to >>>> create a list that someone can go though and whitelist the user >>>> or >>>> reject the user for commits not in the whitelist? >>>> >>> i've never done this in the past. >>> i assume we'll need to read the author email/name from the gerrit >>> patch (before running the code) >>> wget the whitelist page from ovirt.org and match it.. >>> >>> or alternatively run git log and search it there... >>> >>> if there isn't a match, fail the job before running any code. >> No, I don't think we want to have failures in the main build job. >> What >> about a separate job that verifies the patch submitter, then >> triggers >> the build job. Would probably need to pass the GERRIT_REFSPEC >> variable >> between the 2 builds somehow. > of course, the main job won't be touched. > i was talking about a new job that will only be used with gerrit > patches. > and it can fail and give '-1' if the submitter is not authorized. > i need to check if we can add an 'error msg' to the user with > something like > "Sorry, but you're not authorized to send patch to xxxx project, > please send a request to infra/devel list"... I think the idea was to not run until someone can take a look at the patch. Not reject the patch.

Thanks Robert > > >> Mike >> >>>> 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Infra mailing list >>>>> Infra(a)ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/infra >>>> _______________________________________________ >>>> Infra mailing list >>>> Infra(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/infra >>>> >>> _______________________________________________ >>> Infra mailing list >>> Infra(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/infra >> >>

Am 18.07.2012 um 13:00 schrieb Robert Middleswarth: > I need trust to be earned so I +1 on whitelist. With that said I think getting on the whitelist should be pretty easy. Isn't that what you usually do on projects - have the first few commits not directly go to master but being reviewed by an existing committer and then giving full commit access to a new user? So I think that fits in and fits with what new committers are used to. Many of them actually would be scared if they got commit access from day 1.

Heiko _______________________________________________ Infra mailing list Infra(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/infra

That would match the pattern of not automatically running every submission directly on gerrit until they have proven that they know what they are doing.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/18/2012 10:00 AM, Robert Middleswarth wrote: >> I am on the opposite side of this issue. Maybe I have been >> attacked by 1 to many bot's or been a manager when someone I >> know and trusted stole from the company. I need trust to be >> earned so I +1 on whitelist. With that said I think getting on >> the whitelist should be pretty easy. We are not talking about >> blocking there commit's we are talking about should the >> automated system run test/code against there patch. I am still >> learning Jekins when using a whitelist is there a way to flag >> commits for users not in the list? I wonder if there is some way >> to create a list that someone can go though and whitelist the >> user or reject the user for commits not in the whitelist? Perhaps this is just an example of my limited dimensional thinking around SCMs. I tend to think by default, "There should be a well described pathway to committer status. Once achieved, you can commit, that's it." Old school thinking. :) However, I get that more complex infrastructure may have other considerations. In Fedora, for example, things went from a wide open SCM where anyone could commit to any package, to a more segregated system with the idea of an over-packager status that one can attain, which provides the now rare ability to commit to any package. Similarly here, oVirt may say, "Fine, you can commit code to the main git repo, but you have to earn Level Q to be able to kick-off automated testing." I just want us to be careful how we contextualize, too. While trust is one reason we don't give root to everyone, another reason is we want to be sure they know how to be safe and sane in that position. People may need e.g. training or testing that they are not going to accidentally do something that makes Jenkins fall down and cry.

-----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.

* 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?

- - Karsten - -- Karsten 'quaid' Wade, Sr. Analyst - Community Growth http://TheOpenSourceWay.org .^\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 _______________________________________________ Infra mailing list Infra(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/infra

----- Original Message ----- > From: "Robert Middleswarth" <robert(a)middleswarth.net&gt; > To: infra(a)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.

> 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 >> _______________________________________________ >> Infra mailing list >> Infra(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/infra > > -- > Thanks > Robert Middleswarth > @rmiddle (twitter/IRC) > > _______________________________________________ > Infra mailing list > Infra(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra >

----- Original Message ----- > From: "Robert Middleswarth" <robert(a)middleswarth.net&gt; > To: "Eyal Edri" <eedri(a)redhat.com&gt; > Cc: infra(a)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(a)middleswarth.net&gt; >>> To: infra(a)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.

----- Original Message ----- > From: "Itamar Heim" <iheim(a)redhat.com&gt; > To: "Eyal Edri" <eedri(a)redhat.com&gt; > Cc: "Robert Middleswarth" <robert(a)middleswarth.net&gt;, infra(a)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(a)middleswarth.net&gt; >>> To: "Eyal Edri" <eedri(a)redhat.com&gt; >>> Cc: infra(a)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(a)middleswarth.net&gt; >>>>> To: infra(a)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.

On 08/01/2012 09:31 AM, Eyal Edri wrote: > Itamar Heim wrote: >> 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.

On Wed, Aug 01, 2012 at 09:35:39AM -0400, Robert Middleswarth wrote: > On 08/01/2012 09:31 AM, Eyal Edri wrote: >> Itamar Heim wrote: >>> 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. Can't we extract this from an authors file? Looking at vdsm/AUTHORS[1] it looks fairly easy.

Another thing I can imagine is that someone is not whitelisted but his/her patch receives recieves a +1 from a whitelisted reviewer it can be built as well. It would be built anyway if it gets accepted and now jenkins can give -1 if it fails unit tests. Maybe at +2, but that leaves very little time to actually build it because often it will get merged straight away.

[1]: http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob;f=AUTHORS;hb=HEAD _______________________________________________ Infra mailing list Infra(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/infra

From: "Itamar Heim" <iheim(a)redhat.com&gt; To: "Robert Middleswarth" <robert(a)middleswarth.net&gt; Cc: infra(a)ovirt.org Sent: Wednesday, August 1, 2012 5:01:10 PM Subject: Re: Security issues when running gerrit patches on jenkins On 08/01/2012 04:56 PM, Robert Middleswarth wrote: > On 08/01/2012 09:50 AM, Ewoud Kohl van Wijngaarden wrote: >> On Wed, Aug 01, 2012 at 09:35:39AM -0400, Robert Middleswarth >> wrote: >>> On 08/01/2012 09:31 AM, Eyal Edri wrote: >>>> Itamar Heim wrote: >>>>> 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. >> Can't we extract this from an authors file? Looking at >> vdsm/AUTHORS[1] >> it looks fairly easy. > That would be a bad idea. All someone would need to do is add > themselves to that list? >> lets start with something... worst case someone will send a patch without jenkins auto reviewing it once or twice - important thing is it will get 99.9% of the patches reviewed by jenkins

>> Another thing I can imagine is that someone is not whitelisted but >> his/her patch receives recieves a +1 from a whitelisted reviewer >> it can >> be built as well. It would be built anyway if it gets accepted and >> now >> jenkins can give -1 if it fails unit tests. Maybe at +2, but that >> leaves >> very little time to actually build it because often it will get >> merged >> straight away. > That does sound useful once someone not on the white list gets a +1 > it > auto test as we can assume anyone reviewing is trusted enough to > not +1 > a dangerous patch. Of curse this adds even more complexity in a > plug-in. Although not specific enough to make the plug-in not > reusable. >> [1]: >> http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob;f=AUTHORS;hb=HEAD >> _______________________________________________ >> Infra mailing list >> Infra(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/infra > > _______________________________________________ Infra mailing list Infra(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/infra