Re: Security issues when running gerrit patches on jenkins

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