Security issues when running gerrit patches on jenkins

[Eyal Edri]

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Robert Middleswarth" <robert at middleswarth.net>
> Cc: infra at ovirt.org
> Sent: Wednesday, August 1, 2012 5:01:10 PM
> Subject: Re: Security issues when running gerrit patches on jenkins
> 
> On 08/01/2012 04:56 PM, Robert Middleswarth wrote:
> > On 08/01/2012 09:50 AM, Ewoud Kohl van Wijngaarden wrote:
> >> On Wed, Aug 01, 2012 at 09:35:39AM -0400, Robert Middleswarth
> >> wrote:
> >>> On 08/01/2012 09:31 AM, Eyal Edri wrote:
> >>>> Itamar Heim wrote:
> >>>>> 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.
> >> Can't we extract this from an authors file? Looking at
> >> vdsm/AUTHORS[1]
> >> it looks fairly easy.
> > That would be a bad idea.  All someone would need to do is add
> > themselves to that list?
> >>
> 
> lets start with something... worst case someone will send a patch
> without jenkins auto reviewing it once or twice - important thing is
> it
> will get 99.9% of the patches reviewed by jenkins

OK. i opened a feature request for it here [1] 
for now i imagine we can implement it with some bash code in a jenkins job,
and we can also try to send a patch for it to the gerrit trigger plugin [2]

[1] https://issues.jenkins-ci.org/browse/JENKINS-14655
[2] https://github.com/jenkinsci/gerrit-trigger-plugin
> 
> >> Another thing I can imagine is that someone is not whitelisted but
> >> his/her patch receives recieves a +1 from a whitelisted reviewer
> >> it can
> >> be built as well. It would be built anyway if it gets accepted and
> >> now
> >> jenkins can give -1 if it fails unit tests. Maybe at +2, but that
> >> leaves
> >> very little time to actually build it because often it will get
> >> merged
> >> straight away.
> > That does sound useful once someone not on the white list gets a +1
> > it
> > auto test as we can assume anyone reviewing is trusted enough to
> > not +1
> > a dangerous patch.  Of curse this adds even more complexity in a
> > plug-in.  Although not specific enough to make the plug-in not
> > reusable.
> >> [1]:
> >> http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob;f=AUTHORS;hb=HEAD
> >> _______________________________________________
> >> Infra mailing list
> >> Infra at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/infra
> >
> >
> 
> 
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>