On 08/01/2012 09:31 AM, Eyal Edri wrote:
----- 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.
Actually makes a lot more since. That allows the projects the ability
to manage there own list.
--
Thanks
Robert Middleswarth
@rmiddle (twitter/IRC)
_______________________________________________
Infra mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/infra
