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

--- Comment #5 from John Mark Vandenberg <[email protected]> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to