-
Notifications
You must be signed in to change notification settings - Fork 166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Security: please pay careful attention to code running through CI #1070
Comments
@rvagg has there been any instance of abuse in the past? Do you think running automated tools to analyze code before it's run on the CI is justified? |
EOL machines (not supported and won't be receiving security updates):
Adding this to build-agenda so we can discuss during the next meeting |
@benjamingr nothing major, no. Re removing old machines: Ubuntu 12.04 is in extended support and I'm hoping to convince canonical to comp us a subscription. Regarding CentOS 5 we need it for Node 4, although I might try and reach out to Red Hat (a member of the NF) to try and get a RHEL subscription to extend that, I'm not sure where we'd run a VM, however. Either way we're stuck with it for now. Regarding Fedora, refer to that discussion, they're holding on because "if we can continue to test older distros and have the capacity to do so then we may as well" is the policy we have at the moment. I'm meh on that policy so I'd be happy to ditch older Fedora to clean up but we'll have to discuss amongst Build. |
Let Rod PR change in for Fedora, and then remove. |
Many of the EOL machines have been removed from the cluster, closing this for now. CentOS5 is still needed for older Node version releases. |
Dear @nodejs/collaborators, in light of the recent news about the devastating CPU security flaws discovered by Google's Project Zero, I'd to remind you that we rely on you to review and take responsibility for code submitted to the shared CI system we use for Node.js, libuv and other projects. There is a checkbox you have to click that acknowledges this when requesting a build. Allowing arbitrary code to be run in our CI system opens us up to potential subversion of the integrity of our build, test and benchmark infrastructure so it's vital that you have a good knowledge of the code changes that you are sending through Jenkins. Don't tick that box lightly.
We keep our release infrastructure separate to help mitigate security problems, but, we run a significant amount of infrastructure and having to clean up after even a trivial breach in our test infrastructure could be quite costly on our time and resources and we'd really rather not have to go through that.
The text was updated successfully, but these errors were encountered: