CI security

[rvagg]

From what I understand, the current Jenkins set up for Node.js and libuv run by Joyent will do builds for commits and pull requests. I'm having a hard time figuring out how this can be made secure outside of the unixes with containerisation (Solaris, Linux, ... ?). The hole I see is in running builds for pull requests basically opens these boxes up to executing arbitrary code from anybody with a GitHub account which could potentially compromise the machines themselves which is a particular concern if some of these builds will end up being actual releases.

Looking for insight from people with more experience on this than me. The most common use-case for Jenkins is in-house builds rather than open source projects so I'm not sure if this comes up a whole lot.

/cc @tjfontaine @evilpacket

[bnoordhuis]

I believe it only builds PRs from people that are whitelisted, i.e. known contributors.

[rvagg]

insight in to how this whitelist is maintained would be great, if it can be automated then 👍

[bnoordhuis]

Not 100% sure but I believe it's just a text file (a rather small one) with no automation whatsoever.

Perhaps a better approach is how bors is used in the Rust project: a reviewer does a quick review of the pull request, then tells bors to build and test it (example). No doubt there's a Jenkins plugin with similar functionality. It still requires a whitelist of reviewers but that list will be fairly static.

[tjfontaine]

A small proxy sits in front of jenkins written in node, affectionately
called jankins. If routes are not for jankins they are proxied to jenkins.
It also accepts github webhooks.

Prs are only run on unicies, not windows, feature branches run on all
platforms.

New prs are compared against a whitelist managed by a SQLite db, and
automatically built if pushed by a collaborator on that list.

A chrome plugin with your jenkins API and github API key injects in pr
pages recent build information if available. You may also trigger a rebuild
of the pr

Jankins also listens for resyncs, if the pr has been previously built by
someone with credentials subsequent pushes to the pr branch will
automatically trigger a rebuild.

The jenkins job itself curls and applies the patch to the target branch so
no manual rebasing is required. It either applies or doesn't.

The first step beyond that is always to run lint.

The end of the job always notifies the proxy of it finishing, but matrix
jobs will notify for every axis completion, so the proxy needs to watch for
the build being done.

Improvements on this process could be to manage the whitelist by checking
against the github collaborator list.

Also automatic creation of jobs and management of webhooks in jankins would
be ideal.

Extending a bot to be able to trigger from irc would be great, you could
also make it listen to github comments to trigger it (github plugin does
this but in the most annoying and verbose ways)

Potentially also using a complete throw away container zone would be ideal
for sand boxing, but not enough of the platforms offer real isolation to
support that.

[rmg]

Since I had to write tooling for dealing with the 212 (and growing) jobs on our Jenkins instance, I added whitelist updating to it so that PRs are built automatically for anyone who has already landed a commit on master.

[bnoordhuis]

Closing, we're effectively using a whitelist now. If someone feels strongly about this, please reopen.