On 07/18/2012 03:10 PM, Eyal Edri wrote:
----- 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"...
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
-----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
