https://bugzilla.wikimedia.org/show_bug.cgi?id=50344

--- Comment #5 from John Mark Vandenberg jayvdb@gmail.com --- To avoid executing malicious code, the simplest approach is to do the tests only if someone trusted uploaded or +1'd the changeset. I see that mediawiki-core has phpunit and qunit tests being run. Couldnt those tests run malicious code too?

The problems with _only_ running tests against a different mediawiki install is that a) the tests will nearly all need to be rewritten, and family files need to be built for the complex inter-language/wiki relationships, and b) it still must be isolated to prevent malicious code (using urllib2/httplib2) attacking non test servers.

Re my last post, rather than using config.actions_to_block, a HTTP proxy could be used to prevent any network traffic except whitelisted API actions. Then the 'only' problem is local/filesystem tomfoolery, and an OS-enforced sandbox will do the trick, and is quite easy.

Some tests don't depend on a server at all, and it would be good to start with just running those tests, running the tests in a sandbox which isnt allowed to use sockets and threads, or files other than those on a whitelist (and apicache/*).

textlib for example, depends on family file information, and some siteinfo which could (and probably should) be permanently stored in the family file and only refreshed periodically. At worse we could build a MockEnWpSite to run those tests against. We've just had a massive build breakage that lasted about a week because of textlib changes which were not tested against the current tests, and one of the checked in 'fixes' included changes to wikibase_tests.py that didnt compile. It would be nice if code review didnt include checking the code compiles and unit tests pass - that wastes time, and the workpit cant be used for something else while the pywiki test suite runs, for at least 15 mins.