[Wikitech-l] Clarification on unit tests requiring CR+2
Hello, We would like to clarify the reason we changed Jenkins to no longer run unit tests on patch submission. We had to defer code execution to after CR+2 for security reasons. If unit tests were ran on submission that meant anyone with a labs account could effectively get shell access on the server. Because LDAP accounts are now up for open registration (aka free Labs accounts, and by extend permission to submit patches to Gerrit), that also meant the whole world would be able to get shell access on the server (via PHP/Nodejs/ant/bash to infinity and beyond). This issue will be definitely solved by isolating tests in dedicated virtual machines for each run. We are investigating Vagrant. Restricting unit tests is simpler and faster to implement over all the Vagrant engineering. So running tests after CR+2 is a temporary measure until the implementation of Vagrant sandboxes in Jenkins builds is ready. So, in conclusion: Unit tests will be run again on patch submission once we have finished integrating Vagrant in Jenkins. -- The CI team Antoine Timo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Clarification on unit tests requiring CR+2
Sounds good to me. IMHO, if you're submitting a patch and haven't already run unit tests on that patch, you're probably doing something wrong. I've done that a few times myself, and could have avoided unnecessary patchset submissions if I had done so. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Wed, Dec 19, 2012 at 2:48 PM, Krinkle krinklem...@gmail.com wrote: Hello, We would like to clarify the reason we changed Jenkins to no longer run unit tests on patch submission. We had to defer code execution to after CR+2 for security reasons. If unit tests were ran on submission that meant anyone with a labs account could effectively get shell access on the server. Because LDAP accounts are now up for open registration (aka free Labs accounts, and by extend permission to submit patches to Gerrit), that also meant the whole world would be able to get shell access on the server (via PHP/Nodejs/ant/bash to infinity and beyond). This issue will be definitely solved by isolating tests in dedicated virtual machines for each run. We are investigating Vagrant. Restricting unit tests is simpler and faster to implement over all the Vagrant engineering. So running tests after CR+2 is a temporary measure until the implementation of Vagrant sandboxes in Jenkins builds is ready. So, in conclusion: Unit tests will be run again on patch submission once we have finished integrating Vagrant in Jenkins. -- The CI team Antoine Timo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Clarification on unit tests requiring CR+2
On Wed, Dec 19, 2012 at 11:48 AM, Krinkle krinklem...@gmail.com wrote: Hello, We would like to clarify the reason we changed Jenkins to no longer run unit tests on patch submission. Thanks for this update. Also, cross-referencing Antoine's post on the interim whitelist solution for mediawiki/core: http://lists.wikimedia.org/pipermail/wikitech-l/2012-December/065191.html From that post: There is no process to be added in the whitelist, I guess you could talk about it on IRC. If there is no obvious veto there, you could probably just amend layout.yaml in integration/zuul-config.git file and get it approved :) So if you're a trusted dev already (as determined by your peers) and would like to get your tests run automatically on each patchset, but aren't on the wihtelist yet, you can submit a patch to do so against this file: https://gerrit.wikimedia.org/r/gitweb?p=integration/zuul-config.git;a=blob;f=layout.yaml;hb=HEAD That seems like a reasonable interim solution until we've got a more secure setup, especially once the whitelist works against extensions as well. Thanks for all your hard work on improving the setup while also making things more open for new developers. Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Clarification on unit tests requiring CR+2
On 19/12/12 20:48, Krinkle wrote: This issue will be definitely solved by isolating tests in dedicated virtual machines for each run. We are investigating Vagrant. A VM seems overkill when it can be solved with standard user permissions + chroot (or even better, a bsd jail) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Clarification on unit tests requiring CR+2
(anonymous) wrote: This issue will be definitely solved by isolating tests in dedicated virtual machines for each run. We are investigating Vagrant. A VM seems overkill when it can be solved with standard user permissions + chroot (or even better, a bsd jail) With chroot you also have to spend a lot of thought into setting up (and tearing down) the (non-SQLite) databases and other auxiliary services; VMs are much easier to deal with and adapt in this regard. Travis CI is probably the most prominent example of the openness and diversity one can achieve with potentially rogue users. But whether chroot or VMs, Jenkins or whatnot, it would be very nice if WMF could finally commit some resources to this problem. The underlying security question was tabled months ago, and the solution to it isn't exactly rocket science as evidenced by the various existing services, but still hard work. Tim ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
