Security issues when running gerrit patches on jenkins

[Itamar Heim]

On 07/18/2012 11:47 PM, Karsten 'quaid' Wade wrote:
> -----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.

I wouldn't view infra as a single project, rather several sub projects, 
each with their own set of skills as each service requires expertise 
with a different technology.