Re: [eclipse.org-committers] Malicious executable content in Gerrit cont

[Mickael Istria <mistria@xxxxxxxxxx>]

On 12/10/2014 04:47 PM, Thanh Ha wrote:

On Wed, Dec 10, 2014 at 9:38 AM, Mickael Istria <mistria@xxxxxxxxxx> wrote:

On 12/10/2014 03:18 PM, Mikaël Barbero wrote:

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?

I think this is the assumption made with build services like Travis CI. They give you a temporary VM that disappears after ~2 hrs. I think in these cases since a "verify" job is what runs, artifacts are temporary and disappear so likely won't become an issue unless someone actually merges the bad code. This is assuming that the temporary build VM does not allow the build to push the built artifacts anywhere.

Ok, so it seems like that's what we should do for verification jobs. I believe verification jobs don't need advanced permissions or access in general and are totally fine to run in a VM or a container.
However, regular jobs, such as building the latest revision, often need ability to push to download.eclipse.org so they need stronger access to download.eclipse.org. But the code built by those jobs can be trusted, as it has been written or approved by committers.

The best usage scenario would would be that the Gerrit Hudson plugin automatically wrap the job in a container/VM, so no one would have to explicitly configure that. However, I don't know how possible it is.

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