-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Simetrical wrote: Indeed, there's not a lot of organized testing, though the fuzz testing tools get pulled out from time to time to look for HTML injection bugs and other such surprises. Generally, we try to maintain safe programming practices to ensure the borders are patrolled, as it were: * Don't construct SQL by hand; use query-building abstractions which ensure proper encoding * Don't construct HTML output by hand; use wiki parser where suitable or XML-building abstractions which ensure proper encoding * Don't use $_GET, $_POST, $_REQUEST etc values straight; use abstractions which provide some basic data type validation * Don't use explicit include() or require()s with configured paths; use class autoloader (when an explicit include is needed, always precede it with a constant check to avoid remote include vulnerabilities) etc It's not always perfect, and there's going to be lazy code here and there, but working within a safe framework at input/output points is always a big help in combatting many of the traditional web app vulnerabilities. When it comes to ensuring that private data in the wiki stays private, there's perhaps less of an automatic guarantee, as you have to decide what is or isn't private and ensure that the visibility is properly restricted. - -- brion vibber (brion @ wikimedia.org)

Brion Vibber wrote: Hi Brion, thanks for your input! Sounds good that you found some suitable tools to fuzz with. Are you able to name those tools? Is there any multi-tier patch revision? The folks at Apache Tomcat do a three-person-review of patches before they get committed. Thanks -- <NO> OOXML - Say NO To Microsoft Office broken standard http://www.noooxml.org

On Thu, May 1, 2008 at 5:56 AM, Michael Osipov &lt;ossipov(a)inf.fu-berlin.de&gt; wrote: We have no formal process at the moment, except that Brion reviews everything after it's committed but before it's synced to the servers. People with commit access basically commit whatever they want, and if someone spots that it's broken or otherwise objectionable, they either revert it immediately or post a note to some development forum (this list, #mediawiki on FreeNode, etc.) asking for people's opinions on whether to revert it. In the event of a dispute, Brion resolves it as lead developer. People other than Brion can review whatever they feel like. I at least glance at all commits to core code or extensions used by Wikimedia, and sometimes look them over more closely. It's likely that most interesting commits get at least two other people looking them over. Bad changes do occasionally go live on Wikipedia (I broke it within hours of getting commit access, woo), but rarely for long. They tend to be spotted quickly by editors, and since changes go live every couple of days on average, it's easy to quickly figure out what must have caused the breakage and fix it.

Simetrical wrote: Hi, Do you think it's worth trying to contact Nick? I know that he fuzzes JAMWiki too. Seems like he's into it. Mike -- <NO> OOXML - Say NO To Microsoft Office broken standard http://www.noooxml.org