Wikitech-l June 2006

wikitech-l@lists.wikimedia.org

122 participants
168 discussions

Re: [Wikitech-l] User-specified JavaScript execution Vuln with two specific extensions
by Nick Jenkins 02 Jun '06

02 Jun '06

> > There is a mouseover user-specified JavaScript execution vulnerability > > affecting MediaWiki 1.6.6 when running with two specific extensions. > > Specifically this is with the experimental <sort> extension. Nobody should be > using that one just yet, as it's still under development. Superficially, yes, that's correct. However, on a deeper level *maybe* it misses something. Specifically, this problem wasn't found by automated testing. Rather, it was found by noticing the automated testing was finding problems with nested extension calls, and then suspecting that there was a deeper problem with the interaction between nested extension calls. The fact that such a problem was then found by hand leads me to wonder whether this hypothesis is correct. In other words, this seems like it *might* be systemic in nested extension calls, rather than a one-off. For example, suppose a site has extensions A and B installed. Now suppose a user does something like this: <a><b arg="something"></a> (i.e. Makes a nested call to extension B inside extension A.) or this: <a><a arg="something"></a> (i.e. makes a nested call to extension A instead extension A.) Calls to extensions inside wiki text are special, and from the Parser output it's clear they're treated specially, in that they seem to have different precedence. Currently extension A has to do lots of checking of the input to prevent this kind of thing from being a problem. Example: http://nickj.org/MediaWiki/Parser26 which abused a call to the ref extension inside a call to the ref extension. Your fix is here: http://mail.wikipedia.org/pipermail/mediawiki-cvs/2006-May/015379.html ; But the potentially worrying bit was that it only addresses that specific extension. So that was Ref + Ref. Besides this problem, there are others: http://nickj.org/MediaWiki/Parser31 , which is Inputbox + Math. http://nickj.org/MediaWiki/Parser28-variant1 , which is Sort + Math. And of course this one, which is Sort + something. *Maybe* (and this goes back to the thing of formally specifying what's allowed in wiki text) nested calls to extensions should be ignored by the parser. Or, failing that, maybe the inner call should have to complete, and then the outer should be called - whereas I suspect *maybe* sometimes the outer is called first, and then the inner is called second, which potentially is where some of these things are coming from. Either option would allow extension authors have to worry less about bad input (by making it more the Parser's problem than the extension's problem). Of course, I could be wrong. All the best, Nick.

3 4

Live mirrors of de.wikipedia
by Peter Jacobi 01 Jun '06

01 Jun '06

These popup-infested warts mirror de.wikipedia by live inclusion of content: http://www.nachgeschlagen.com/wiki/Hauptseite http://www.easy-lexikon.de/wiki/Hauptseite http://www.web01.de/wiki/Hauptseite compare: http://de.wikipedia.org/wiki/Hauptseite The third one does something creative but wrong, and sometimes gets English instead of German pages. Regards, Peter Jacobi [[User:Pjacobi]] -- Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer! Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer

2 1

Re: [Wikitech-l] Distributed bzip2
by mdd4696＠gmail.com 01 Jun '06

01 Jun '06

> Many times, but that's not necessarily clear or simple. The generic > delta-generation tools we've tried in the past just choke on our files; note > that the full-history dump of English Wikipedia -- the one we're most concerned > about having archival copies of available -- is over 350 gigabytes uncompressed. Actually, I just downloaded enwiki-20060518-pages-meta-history.xml.7z and when I did a "7za l enwiki-20060518-pages-meta-history.xml.7z" it said that the archive would be 692686106434 bytes (645 GB) uncompressed. Is that inaccurate? ~MDD4696

2 1

Threads: any plans
by Uwe Brauer 01 Jun '06

01 Jun '06

Hello I asked sometime ago about the possibilities to add some Thread functionality to the discussion pages and I was pointed out that there exists http://meta.wikimedia.org/wiki/Talk:LiquidThreads. However it seems to me not a very vivid project. Are there any other plans to add such a functionality? Thanks Uwe Brauer

9 17

Distributed bzip2
by Brion Vibber 01 Jun '06

01 Jun '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Between other things I've been working on a distributed bzip2 compression tool which could help speed up generation of data dumps. By trading LAN bandwidth for idle CPU elsewhere in the server cluster, an order-of-magnitude improvement in throughput seems reasonably practical; this could cut bzip2 compression time for the large English Wikipedia history dumps by a full day. Status/documentation: http://www.mediawiki.org/wiki/dbzip2 Source: http://svn.wikimedia.org/viewvc/mediawiki/trunk/dbzip2 Updates on my (*blush*) development blog: http://leuksman.com/ I'm hoping something similar can be accomplished with 7zip as well... - -- brion vibber (brion @ pobox.com) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEfVkSwRnhpk1wk44RAv/wAJ9JJghnGX6wmPvVz8lX6WLa+sfeZwCg1wex ZcadcVpBCsZP866C4gdG7/M= =SpCq -----END PGP SIGNATURE-----

3 3

Error when using MediaWiki search functionality
by thomas Armstrong 01 Jun '06

01 Jun '06

Hi. Using MediaWiki v1.4.rc1 with mySQL 3.23.58, I get this error message when trying to search any word with MediaWiki search functionality: ----------- A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: SELECT cur_id, cur_namespace, cur_title, cur_text FROM `cur`,`searchindex` WHERE cur_id=si_page AND MATCH(si_title) AGAINST('+foo' IN BOOLEAN MODE) AND cur_namespace IN (0) LIMIT 0,20 from within function "". MySQL returned error "1064: You have an error in your SQL syntax near 'BOOLEAN MODE) AND cur_namespace IN (0) LIMIT 0,20 ' at line 1 (localhost)". ------------------ Any similar experience?

2 1

MediaWiki automated test run failure 2006-06-01
by brion＠pobox.com 01 Jun '06

01 Jun '06

An automated run of parserTests.php showed the following failures: Running test Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)... FAILED! Running test Link containing double-single-quotes '' (bug 4598)... FAILED! Running test BUG 1887, part 2: A <math> with a thumbnail- math enabled... FAILED! Running test Language converter: output gets cut off unexpectedly (bug 5757)... FAILED! Running test HTML bullet list, unclosed tags (bug 5497)... FAILED! Running test HTML ordered list, closed tags (bug 5497)... FAILED! Running test HTML ordered list, unclosed tags (bug 5497)... FAILED! Running test HTML nested bullet list, open tags (bug 5497)... FAILED! Running test HTML nested ordered list, closed tags (bug 5497)... FAILED! Running test HTML nested ordered list, open tags (bug 5497)... FAILED! Passed 324 of 334 tests (97.01%) FAILED!

1 0

User-specified JavaScript execution Vuln with two specific extensions
by Nick Jenkins 01 Jun '06

01 Jun '06

Hi All, There is a mouseover user-specified JavaScript execution vulnerability affecting MediaWiki 1.6.6 when running with two specific extensions. One of those extension is installed on the Wikipedia, but the other is not. Therefore the Wikipedia (and most MediaWiki installations) are not affected. Details have been provided to security(a)wikimedia.org as per the instructions at: http://www.mediawiki.org/wiki/Security , and will be made public in due course at: http://nickj.org/MediaWiki All the best, Nick.

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l June 2006