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