Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] Malicious executable content in Gerrit contributions

Le 10 déc. 2014 à 15:38, Mickael Istria <mistria@xxxxxxxxxx> a écrit :

On 12/10/2014 03:18 PM, Mikaël Barbero wrote:
Manual trigger for non whitelisted users would be a huge regression regarding the contribution workflow (see this comment
Contributing a change in a pom file that invokes "rm -rf downloads/yourProject" would end in an even bigger regression ;)

I agree, this discussion is all about avoiding that.

Having to manually promote the latest snapshot build because of low permissions on is also another possible regression.

What do you mean by snapshot? Result from the gerrit-triggered build? Do you promote the build that has been triggered by gerrit? I would consider this a bad practice. 

Turning this bad practice into a rule may be the solution. Do not allow to run gerrit jobs on standard HIPP, but only in a sandboxed HIPP with absolutely no writing rights except a local-sandboxed FS. No promotion possible, but I don't see it as a limitation.

I would rather see the HIPP to be much more isolated from the rest of the Foundation's servers like suggested in the very same comment.
Could Docker help there? Let's say by making the Gerrit triggers run in a Docker container which can be destroyed safely? Is even such container approach really safe?

Combined with the restriction on gerrit-trigerred jobs above, this could make the trick. A fresh new container should be instantiated for each new triggered job and it should be dropped after the build is done.

This issue may have already been addressed by other services. e.g., when someone sends a pull-request to a project hosted on github with a travis-ci trigger, the build is triggered and can almost do the same amount of damages that we are talking about. Does anybody know how do they cope with this?
GitHub Pull Request Builder Plugin ( ) requires a trusted person of the project, to manually approve the build of the incoming change. The process is that before kicking a build.

I was not talking about the jenkins/hudson plugin, but about another toolchain (github pull request+travis-ci). They provide a similar set of features as our gerrit trigger + hudson (ie automatic build on pullrequest/review), so I was asking if anybody knows how do they cope with such security issues.

Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets
_______________________________________________ mailing list

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.

Back to the top