Wikitech-l December 2008

wikitech-l@lists.wikimedia.org

89 participants
67 discussions

Code update status?
by Remember the dot 17 Dec '08

17 Dec '08

Hey, The code on Wikimedia sites hasn't been updated in about 3 weeks...any idea on when the next update will be? -- Remember the dot http://en.wikipedia.org/wiki/User:Remember_the_dot

11 21

Future of Javascript and mediaWiki
by Michael Dale 17 Dec '08

17 Dec '08

Looking to the future of mediaWiki the base set of javascipt will continue to grow as the client side applications grow in complexity to address improved usability issues and new features. To this end it will become more necessary to A) have a better system for sending out client side javascript. and B) standardize around a JavaScript helper library. A) The improved delivery mechanism is a two part issue: Code maintainability and client side performance. 1) To maintain and modularize code as the complexity of javsaciprt libraries grows, it makes a lot of sense to split JavaScript class & objects into respective files folders etc. Likewise we dont' want additional requests for language code delivery. By using a server side delivery system we can do clean dynamic addition of sets of javascript files to the page in a single request "just in time" as the user interacts with a given set of interface components. If we don't update our javascript delivery mechanisms this will result in _lots_ of little javascipt requests and less maintainable/flexible javascript code. 2) Furthermore with complex javascript libraries we want to add verbose comments, documentation, and debugging statements to the code without resulting in reduced client side performace in delays due to file size increases. Minimized javascript can strip all that unnecessary bits. I propose we implement or adopt something like: http://code.google.com/p/minify/ This will mean sets of javascript files can be grabbed in a single request, minimized, grouped, cached, and gziped (if the clients supports it). This should work fine with our reverse proxy setup resulting in a net decrease in cluster load by dealing with smaller files for the majority of the time. A user preference could request un-compressed individual files and or a url parameter like ?jsdebug=true could enable non-compressed output for debugging. A library such as minify can also minimize and group all the style sheets and minimize html output if we wanted. Although the gains are not anywhere as dramatic or as necessary for the html/css space. If we can get some community consensus about this direction that would be good. I will start looking at integrating the above mentioned library, run some tests etc. B) We should also address the convergence on a javascript library for HTML document traversing, event handling, interface improvements, maintainability, flexibility etc. All the sequencer, metavid stuff uses jQuery. jQuery is GPL/MIT licensed javascript library emerging as the "winner" in script libraires with very wide adoption (google, apple.com, digg.com, mozilla.com etc) and very small footprint. Refactoring existing mediaWiki javsacript code as jQuery javascript would result in much fewer cross browser hacks in mediaWiki javasctipt and generally shorter, more maintainable code. So seems like a good direction to me ;) peace, --michael

9 25

image backup and info on wikitech wiki
by grin 17 Dec '08

17 Dec '08

Hello, I am seeing more and more project on growing the commons media collection which raised the question (in my head, that's where) about its backup. Checking meta kindly redirected me to https://wikitech.leuksman.com/view/Backup_procedures which kind of trying to describe the backup methods, but I have a strange feeling that the page isn't very well maintained. Even if it is, the entry on image backups is highly nonspecific and contains a big warning about being seriously out of date. Now, would some kind soul either update it up to reality, or kindly point me to the actual description, or describe it and give me the right to update it. :-) Or any other way which results in: a) me knowing what's the current state of art, and b) a page where everyone can do the same. Since images cannot be retrieved - AFAIR - the question of their backup is even more important than the database, which can be (and does indeed) backed up to the whole human race. Thanks, grin

5 4

Re: [Wikitech-l] gmane need not encrypt wikimedia lists email addresses
by jidanni＠jidanni.org 17 Dec '08

17 Dec '08

In http://lists.wikimedia.org/pipermail/wikitech-l/2008-December/040652.html >>>>> "BV" == Brion Vibber <brion(a)wikimedia.org> writes: BV> jidanni(a)jidanni.org wrote: >> Can the gmane administrators have permission to turn email address >> encryption (e.g., as seen in >> http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/40… >> ) off? BV> I don't particularly care if they do or don't (whoever they are). Go BV> wild. :) BV> -- brion Ok, Gmane adminstrators, please turn off address encryption for gmane.org.wikimedia.mediawiki.* gmane.science.linguistics.wikipedia.* Thanks.

2 1

MediaWiki 1.13.3, 1.12.2, 1.6.11 security update
by Tim Starling 16 Dec '08

16 Dec '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is a security release of MediaWiki 1.13.3, 1.12.1 and 1.6.11. Some of the security issues affect *all* versions of MediaWiki except the versions released today, so all site administrators are encouraged to upgrade. Users of the development (trunk) branch should upgrade to r44506 or later. David Remahl of Apple's Product Security team has identified a number of security issues in MediaWiki. Subsequent analysis by the MediaWiki development team led to further discoveries. The issues with a significant impact are as follows: * An XSS vulnerability affecting all MediaWiki installations between 1.13.0 and 1.13.2. [CVE-2008-5249] * A local script injection vulnerability affecting Internet Explorer clients for all MediaWiki installations with uploads enabled. [CVE-2008-5250] * A local script injection vulnerability affecting clients with SVG scripting capability (such as Firefox 1.5+), for all MediaWiki installations with SVG uploads enabled. [CVE-2008-5250] * A CSRF vulnerability affecting the Special:Import feature, for all MediaWiki installations since the feature was introduced in 1.3.0. [CVE-2008-5252] These four vulnerabilities are all fixed in these releases. XSS (cross-site scripting) vulnerabilities allow an attacker to steal an authorised user's login session, and to act as that user on the wiki. The authorised user must visit a web page controlled by the attacker in order to activate the attack. Intranet wikis are vulnerable if the attacker can determine the intranet URL. Local script injection vulnerabilities are like XSS vulnerabilities, except that the attacker must have an account on the local wiki, and there is no external site involved. The attacker uploads a script to the wiki, which another user is tricked into executing, with the effect that the attacker is able to act as the privileged user. CSRF vulnerabilities allow an attacker to act as an authorised user on the wiki, but unlike an XSS vulnerability, the attacker can only act as the user in a specific and restricted way. The present CSRF vulnerability allows pages to be edited, with forged revision histories. Like an XSS vulnerability, the authorised user must visit the malicious web page to activate the attack. David Remahl also reminded us of some security-related configuration issues: * Since 1.11, by default, MediaWiki stores a backup of deleted images in the images/deleted directory. If you do not want these images to be publically accessible, make sure this directory is not accessible from the web. MediaWiki takes some steps to avoid leaking these images, but these measures are not perfect. * Set display_errors=off in your php.ini to avoid path disclosure via PHP fatal errors. This is the default on most shared web hosts. * Enabling MediaWiki's debugging features, such as $wgShowExceptionDetails, may lead to path disclosure. Users of MediaWiki 1.6.x (the last branch which supported PHP 4) are strongly recommended to upgrade to PHP 5 and MediaWiki 1.13.3. It is not necessary to upgrade to 1.6.11 first, just upgrade directly to the latest version. Upgrade FAQ: http://www.mediawiki.org/wiki/Manual:FAQ#Upgrading Full release notes: http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_13_3/phase3/RELEASE-NO… http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_12_2/phase3/RELEASE-NO… http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_6_11/phase3/RELEASE-NO… ********************************************************************** MEDIAWIKI 1.13.3 ********************************************************************** Download: http://download.wikimedia.org/mediawiki/1.13/mediawiki-1.13.3.tar.gz Patch to previous version (1.13.2), without interface text: http://download.wikimedia.org/mediawiki/1.13/mediawiki-1.13.3.patch.gz Interface text changes: http://download.wikimedia.org/mediawiki/1.13/mediawiki-i18n-1.13.3.patch.gz GPG signatures: http://download.wikimedia.org/mediawiki/1.13/mediawiki-1.13.3.tar.gz.sig http://download.wikimedia.org/mediawiki/1.13/mediawiki-1.13.3.patch.gz.sig http://download.wikimedia.org/mediawiki/1.13/mediawiki-i18n-1.13.3.patch.gz… Public keys: https://secure.wikimedia.org/keys.html ********************************************************************** MEDIAWIKI 1.12.2 ********************************************************************** Download: http://download.wikimedia.org/mediawiki/1.12/mediawiki-1.12.2.tar.gz Patch to previous version (1.12.1), without interface text: http://download.wikimedia.org/mediawiki/1.12/mediawiki-1.12.2.patch.gz Interface text changes: http://download.wikimedia.org/mediawiki/1.12/mediawiki-i18n-1.12.2.patch.gz GPG signatures: http://download.wikimedia.org/mediawiki/1.12/mediawiki-1.12.2.tar.gz.sig http://download.wikimedia.org/mediawiki/1.12/mediawiki-1.12.2.patch.gz.sig http://download.wikimedia.org/mediawiki/1.12/mediawiki-i18n-1.12.2.patch.gz… Public keys: https://secure.wikimedia.org/keys.html ********************************************************************** MEDIAWIKI 1.6.11 ********************************************************************** Download: http://download.wikimedia.org/mediawiki/1.6/mediawiki-1.6.11.tar.gz Patch to previous version (1.6.10): http://download.wikimedia.org/mediawiki/1.6/mediawiki-1.6.11.patch.gz GPG signatures: http://download.wikimedia.org/mediawiki/1.6/mediawiki-1.6.11.tar.gz.sig http://download.wikimedia.org/mediawiki/1.6/mediawiki-1.6.11.patch.gz.sig Public keys: https://secure.wikimedia.org/keys.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJRjrodWgrCOij/sQRArfRAKCB2hGPDi0ykHUXndIA0kAgUdW9yACeLZm/ tRkFhqQOG7EWVcpvWDMVjLY= =zgL1 -----END PGP SIGNATURE-----

2 1

gmane need not encrypt wikimedia lists email addresses
by jidanni＠jidanni.org 15 Dec '08

15 Dec '08

Can the gmane administrators have permission to turn email address encryption (e.g., as seen in http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/40… ) off? In http://permalink.gmane.org/gmane.discuss/12058 >>>>> "j" == jidanni <jidanni(a)jidanni.org> writes: >>>>> "WS" == Wolfgang Schnerring <wosc+gmane(a)wosc.de> writes: WS> * jidanni(a)jidanni.org [2008-11-28 05:24]: >>> If you look in e.g., >>> http://lists.wikimedia.org/pipermail/mediawiki-l/2008-November.txt.gz >>> you'll see they also use weak encryption ("at"). Therefore could you >>> also turn off the encryption of >>> gmane.org.wikimedia.mediawiki.* >>> gmane.science.linguistics.wikipedia.* WS> updated. j> gmane.org.wikimedia.mediawiki j> gmane.science.linguistics.wikipedia.technical j> and maybe others are still encrypted. Please turn encryption off. In http://permalink.gmane.org/gmane.discuss/12062 >>>>> "LMI" == Lars Magne Ingebrigtsen <larsi(a)gnus.org> writes: LMI> jidanni(a)jidanni.org writes: >> gmane.org.wikimedia.mediawiki >> gmane.science.linguistics.wikipedia.technical >> and maybe others are still encrypted. Please turn encryption off. LMI> No, don't. Just because there are non-encrypted archives out there LMI> doesn't mean that Gmane's messages should be non-encrypted. This is up LMI> to the list admin to decide, and if a list has started out as encrypted, LMI> only a request from the list admin should result in encryption being LMI> switched off.

5 6

Bugzilla Weekly Report
by reporter＠isidore.wikimedia.org 15 Dec '08

15 Dec '08

MediaWiki Bugzilla Report for December 08, 2008 - December 15, 2008 Status changes this week Bugs NEW : 90 Bugs ASSIGNED : 8 Bugs REOPENED : 16 Bugs RESOLVED : 93 Total bugs still open: 3196 Resolutions for the week: Bugs marked FIXED : 58 Bugs marked REMIND : 0 Bugs marked INVALID : 12 Bugs marked DUPLICATE : 15 Bugs marked WONTFIX : 5 Bugs marked WORKSFORME : 4 Bugs marked LATER : 0 Bugs marked MOVED : 0 Specific Product/Component Resolutions & User Metrics New Bugs Per Component General/Unknown 4 Site requests 3 CodeReview 3 General/Unknown 3 User interface 2 New Bugs Per Product MediaWiki 15 Wikimedia 9 MediaWiki extensions 10 Top 5 Bug Resolvers brion [AT] wikimedia.org 13 JSchulz_4587 [AT] msn.com 12 roan.kattouw [AT] home.nl 8 innocentkiller [AT] gmail.com 8 nospam [AT] vyznev.net 7

1 0

Some Ideas About Technical Stuff/Community Relations Improvements
by Eugene Zelenko 12 Dec '08

12 Dec '08

Hi! There are many signs of miscommunications between technical side of WMF operations and outside worlds (users, administrators, external projects): periodical rattling on Planet Wikimedia, frustrations on TranslateWiki, almost impermanently growing number of bug reports in Bugzilla. Typical example may include: 1) There is approved project X which still not created for Y days 2) Why new translations are not propagated to project X 3) Bug reports with opened years ago with several duplications Definitely technical stuff members are limited resource. And even trivial fixes or problems may took much more time then expected. Code changes reviewing require efforts. But outside world don't know what is going on and could only make uneducated guesses and in best case scenario perceive technical stuff as black box I think will be good idea to introduce some kind of technical stuff reporting and future planning (may be located on WMF site). It'll provide approximate answer for question 1; explain clearly situation with 2 (like "rXYZ introduced database scheme changes, currently updating WMF servers"). This will also highlight and communicate priorities to general public. This is not about control over developers but about development process transparency, which I believe, will improve understanding and appreciation of job done from outside. Think how CodeReview improve transparency of MediaWiki code base maintaining. Also development road map for next quarter/year may be considered. Possible solution for problem 3: * WMF may consider to allocate some part of development budget to outside developers. It may be in form of bug fixing bounties, gifts or sponsoring travel/accommodation for participation in Wikimania/MediaWiki developers conference. * Advertisement of "Google Summer of Code" jobs on WMF projects. Eugene. PS Disclaimers: I write weekly reports on work and don't think is most interesting part of it. I don't believe that reports are best reflection of working process.

4 4

[pmwx-dev] Purple MediaWiki (PMWX) Extension now released into beta - 2008.12.09
by viral gupta 12 Dec '08

12 Dec '08

To commemorate the 40th anniversary of the 9-Dec-1968 NLS demo[1], we take pleasure in announcing the release of the Purple MediaWiki (PMWX) Extension into beta today (9-Dec-2008) as free and open source software (under the GNU GPL v2 license.) "Purple Numbers" have their root in the NLS system. They allow web content to be addressed at a fine granular level (for example you can point people to a particular paragraph in a web document, rather than just to a web page) and open up possibilities of improved navigation, communication, reference, search, semantics and knowledge support. PMWX enables "Purple Numbers" in MediaWiki and Semantic MediaWiki implementations, and provides that fine-grained addressability to wiki contents. Please refer to details about the Purple MediaWiki (PMWX) Extension and this release at: o the PMWX project homepage: http://project.cim3.net/wiki/PMWX o the PMWX Release Notes: http://project.cim3.net/wiki/PMWX_Release_Notes o the MediaWiki extensions catalog: http://www.mediawiki.org/wiki/Extension:Purple_MediaWiki We invite you to install, try and make use of PMWX, and would love to get your feedback! Best regards. =ppy for the key members of the PMWX project team who have contributed to this release, Northeastern University - CCIS Dept. Ken Baclawski Viral Gupta Tejas Parikh CIM Engineering, Inc. ("CIM3") Jonathan Cheyer Peter P. Yim P.S. [1] the oNLineSystem demo made by Doug Engelbart and his team, which exposed the world to the possibility of mouse, windows, hypertext, distributed collaboration ... more widely know as the "Mother of All Demos" - see: http://en.wikipedia.org/wiki/The_Mother_of_All_Demos & http://www.sri.com/engelbart-event.html [2] we will be making a presentation on PMWX as part of the SemanticWiki mini-series session-3 panel on the Ontolog Forum. Do join us at that virtual event if you can. Refer to details at: http://ontolog.cim3.net/cgi-bin/wiki.pl?ConferenceCall_2008_12_11 _________________________________________________________________ Message Archives: http://project.cim3.net/forum/pmwx-dev/ Shared Files: http://project.cim3.net/file/work/project/pmwx/ Community Wiki: http://project.cim3.net/wiki/PMWX -- Thanks n Regards Viral Gupta When a man knows what he wants, the world steps aside to make way for him.

2 2

Altering main page title via Pagetitle-view-mainpage property
by Peter Adams 11 Dec '08

11 Dec '08

How does one change the page title template used for main page? I saw that the latest version of mediawiki release notes mentioned a property called 'Mediawiki:Pagetitle-view-mainpage', however editing that alone doesn't seem to do the trick. I'd prefer not to hack the template class/files if possible. thanks, -P-

5 9

2025

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 December 2008