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