On 12/10/2014 03:18 PM, Mikaël Barbero
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 hudson.eclipse.org
is also another possible
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
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.
-committers mailing listeclipse.org-committers@xxxxxxxxxxx
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.