Wikitech-l August 2012

wikitech-l@lists.wikimedia.org

157 participants
164 discussions

MediaWiki 1.19.0beta2
by Sam Reed 09 May '14

09 May '14

I'm happy to announce the availability of the second beta release of the new MediaWiki 1.19 release series. Please try it out and let us know what you think. Don't run it on any wikis that you really care about, unless you are both very brave and very confident in your MediaWiki administration skills. MediaWiki 1.19 is a large release that contains many new features and bug fixes. This is a summary of the major changes of interest to users. You can consult the RELEASE-NOTES-1.19 file for the full list of changes in this version. Five security issues were discovered. It was discovered that the api had a cross-site request forgery (CSRF) vulnerability in the block/unblock modules. It was possible for a user account with the block privileges to block or unblock another user without providing a token. For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=34212 It was discovered that the resource loader can leak certain kinds of private data across domain origin boundaries, by providing the data as an executable JavaScript file. In MediaWiki 1.18 and later, this includes the leaking of CSRF protection tokens. This allows compromise of the wiki's user accounts, say by changing the user's email address and then requesting a password reset. For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=34907 Jan Schejbal of Hatforce.com discovered a cross-site request forgery (CSRF) vulnerability in Special:Upload. Modern browsers (since at least as early as December 2010) are able to post file uploads without user interaction, violating previous security assumptions within MediaWiki. Depending on the wiki's configuration, this vulnerability could lead to further compromise, especially on private wikis where the set of allowed file types is broader than on public wikis. Note that CSRF allows compromise of a wiki from an external website even if the wiki is behind a firewall. For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35317 George Argyros and Aggelos Kiayias reported that the method used to generate password reset tokens is not sufficiently secure. Instead we use various more secure random number generators, depending on what is available on the platform. Windows users are strongly advised to install either the openssl extension or the mcrypt extension for PHP so that MediaWiki can take advantage of the cryptographic random number facility provided by Windows. Any extension developers using mt_rand() to generate random numbers in contexts where security is required are encouraged to instead make use of the MWCryptRand class introduced with this release. For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35078 A long-standing bug in the wikitext parser (bug 22555) was discovered to have security implications. In the presence of the popular CharInsert extension, it leads to cross-site scripting (XSS). XSS may be possible with other extensions or perhaps even the MediaWiki core alone, although this is not confirmed at this time. A denial-of-service attack (infinite loop) is also possible regardless of configuration. For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35315 ********************************************************************* What's new? ********************************************************************* MediaWiki 1.19 brings the usual host of various bugfixes and new features. Comprehensive list of what's new is in the release notes. * Bumped MySQL version requirement to 5.0.2. * Disable the partial HTML and MathML rendering options for Math, and render as PNG by default. * MathML mode was so incomplete most people thought it simply didn't work. * New skins/common/*.css files usable by skins instead of having to copy piles of generic styles from MonoBook or Vector's css. * The default user signature now contains a talk link in addition to the user link. * Searching blocked usernames in block log is now clearer. * Better timezone recognition in user preferences. * Extensions can now participate in the extraction of titles from URL paths. * The command-line installer supports various RDBMSes better. * The interwiki links table can now be accessed also when the interwiki cache is used (used in the API and the Interwiki extension). Internationalization - -------------------- * More gender support (for instance in user lists). * Add languages: Canadian English. * Language converter improved, e.g. it now works depending on the page content language. * Time and number-formatting magic words also now depend on the page content language. * Bidirectional support further improved after 1.18. Release notes - ------------- Full release notes: https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob_plain;f=RE LEASE-NOTES-1.19;hb=1.19.0beta2 https://www.mediawiki.org/wiki/Release_notes/1.19 Co-inciding with these security releases, the MediaWiki source code repository has moved from SVN (at https://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3) to Git (https://gerrit.wikimedia.org/gitweb/mediawiki/core.git). So the relevant commits for these releases will not be appearing in our SVN repository. If you use SVN checkouts of MediaWiki for version control, you need to migrate these to Git. If you up are using tarballs, there should be no change in the process for you. Please note that any WMF-deployed extensions have also been migrated to Git also, along with some other non WMF-maintained ones. Please bear with us, some of the Git related links for this release may not work instantly, but should later on. To do a simple Git clone, the command is: git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git More information is available at https://www.mediawiki.org/wiki/Git For more help, please visit the #mediawiki IRC channel on freenode.net irc://irc.freenode.net/mediawiki or email The MediaWiki-l mailing list at mediawiki-l(a)lists.wikimedia.org. ********************************************************************** Download: http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.tar.gz Patch to previous version (1.19.0beta1), without interface text: http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.patch.gz Interface text changes: http://download.wikimedia.org/mediawiki/1.19/mediawiki-i18n-1.19.0beta2.patc h.gz GPG signatures: http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.tar.gz.si g http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.patch.gz. sig http://download.wikimedia.org/mediawiki/1.19/mediawiki-i18n-1.19.0beta2.patc h.gz.sig Public keys: https://secure.wikimedia.org/keys.html

5 5

bot activity in #mediawiki on freenode
by btb 14 May '13

14 May '13

hi- i'm hopeful this is the appropriate venue for this topic - i recently had occasion to visit #mediawiki on freenode, looking for help. i found myself a bit frustrated by the amount of bot activity there and wondered if there might be value in some consideration for this. it seems to frequently drown out/dilute those asking for help, which can be a bit discouraging/frustrating. additionally, from the perspective of those who might help [based on my experience in this role in other channels], constant activity can sometimes engender disinterest [e.g. the irc client shows activity in the channel, but i'm less inclined to look as it's probably just a bot]. to offer one possibility - i know there are a number of mediawiki and/or wikimedia related channels - might there be one in which bot activity might be better suited, in the context of less contention between the two audiences [those seeking help vs. those interested in development, etc]? one nomenclature convention that seems to be at least somewhat of a defacto standard is #project for general help, and #project-dev[el] for development topics. a few examples of this i've seen are android, libreoffice, python, and asterisk. adding yet another channel to this list might not be terribly welcome, but maybe the distinction would be worth the addition? as i'm writing this, i see another thread has begun wrt freenode, and i also see a bug filed that relates at least to some degree [https://bugzilla.wikimedia.org/show_bug.cgi?id=35427], so i may just be repeating an existing sentiment, but i wanted to at least offer a brief perspective. regards -ben

18 47

Revoking +2 (Re: who can merge into core/master?)
by Rob Lanphier 26 Feb '13

26 Feb '13

On Fri, Jun 15, 2012 at 8:48 AM, Sumana Harihareswara <sumanah(a)wikimedia.org> wrote: > If you merge into mediawiki/core.git, your change is considered safe for > inclusion in a wmf branch. The wmf branch is just branched out of > master and then deployed. We don't review it again. Because we're > deploying more frequently to WMF sites, the code review for merging into > MediaWiki's core.git needs to be more like deployment/shell-level > review, and so we gave merge access to people who already had deployment > access. We have since added some more people. The current list: > https://gerrit.wikimedia.org/r/#/admin/groups/11,members Let me elaborate on this. As unclear as our process is for giving access, it's even less clear what our policy is for taking it away. If we can settle on a policy for taking access away/suspending access, it'll make it much easier to loosen up about giving access. Here's the situation we want to avoid: we give access to someone who probably shouldn't have it. They continually introduce deployment blockers into the code, making us need to slow down our frequent deployment process. Two hour deploy windows become six hour deploy windows as we need time to fix up breakage introduced during the window. Even with the group we have, there are times where things that really shouldn't slip through do. It's manageable now, but adding more people is going to multiply this problem as we get back into a situation where poorly conceived changes become core dependencies. We haven't had a culture of making a big deal about the case when someone introduces a breaking change or does something that brings the db to its knees or introduces a massive security hole or whatever. That means that if the situation were to arise that we needed to revoke someones access, we have to wait until it gets egregious and awful, and even then the person is likely to be shocked that their rights are being revoked (if we even do it then). To be less conservative about giving access, we also need to figure out how to be less conservative about taking it away. We also want to be as reasonably objective about it. It's always going to be somewhat subjective, and we don't want to completely eliminate the role of common sense. It would also be nice if we didn't have to resort to the nuclear option to get the point across. One low-stakes way we can use to make sure people are more careful is to have some sort of rotating "oops" award. At one former job I had, we had a Ghostbusters Stay Puft doll named "Buster" that was handed out when someone broke the build that they had to prominently display in their office. At another job, it was a pair of Shrek ears that people had to wear when they messed something up in production. In both cases, it was something you had to wear until someone else came along. Perhaps we should institute something similar (maybe as simple as asking people to append "OOPS" to their IRC nicks when they botch something). Rob

16 20

Please help MediaWiki I18n/L10n improve
by Niklas Laxström 09 Dec '12

09 Dec '12

tl;dr: Please help in getting https://bugzilla.wikimedia.org/38638 resolved and ensure that your code doesn't cause additional issues for translators. At translatewiki.net we have an [ask question] button for translators, and they have really used it to report various kinds of issues with the messages they are translating. In fact, we barely have time to sort those things into correct places, let alone poking developers to act on them. We are experimenting with different ways to improve this process – the last experiment is using Semantic MediaWiki to track open issues, see [1]. Basically the backlog is growing, and we need some help to reverse the direction. We have tried filing bugs and poking developers on IRC and via email, but that is not scaling anymore, moreover bugs and pokes are sometimes ignored[2]. There are many ways you can help: 1. Follow the best i18n practices like documenting new messages as they are added [4]. Some of you may have noticed that we have started to review any i18n and L10n changes more closely. This is not to annoy you. This is to help you write code that can be translated better and without too many questions from translators. 2. Have a look at [1] and act on issues. 3. Have a look at [1] and poke someone else to act on issues. 4. We need maintainers for [[Support]] [3] to sort stuff into the correct places. 5. When committing code which has i18n changes, add Nikerabbit (me) or Siebrand to reviewers. 6. Ideas on how to improve this process are welcome. We think that we are all responsible for providing them with the information they need. We feel it's our (translatewiki.net staff's) obligation to make sure translators can do their work without too many distractions and wasted efforts. [1] https://translatewiki.net/wiki/Support/Open_requests [2] https://bugzilla.wikimedia.org/38638 [3] https://translatewiki.net/wiki/Support [4] https://www.mediawiki.org/wiki/Localisation -- Niklas Laxström Siebrand Mazeland Raimond Spekking Federico Leva Amir E. Aharoni

2 1

GSoC Project Update (ConventionExtension)
by akshay chugh 21 Nov '12

21 Nov '12

Hello everyone, This is one of my major updates regarding my GSoC project (named ConventionExtension), which I have been working on for about three months now. This project has come a long way and it has reached a point where a lot about it can be shared with others. Since I don't post that often in this list I would like to make this post a long one, and talk about the status of my extension and where its headed in the coming weeks. Some of the features which were part of my timeline for GSoC but were not completed are put under the section "Things yet to be done" along with the other features that I would be working on in the upcoming weeks. *1. Completed Features* * * 1. Dashboard Page (more features are likely to be added depending upon the feedback I gather from the people who have set up conferences on their wiki in the past) 2. Author Registration Page 3. Conference Setup Page 4. Backend (DB) for storing the conference details 5. The basic architecture of the extension: 5.a) Model classes - encapsulating the basic objects required for this extension 5.b) Api Module -- for interacting with ajax calls from the client 5.c) Util classes 5.d) Templates -- classes exending QuickTemplate class, providing a basic layout for Dashboard and Author Register pages 5.e) UI classes - classes extending SpecialPage class (Dashboard, AuthorRegister and ConferenceSetup pages) 5.f) JS + CSS resource modules 6. Parser tags, Magic Words (Variables) and a parser function parser tags --> <conference>, <page>, <account>, <registration>,<passport>,<author>,<submission>,<event>,<organizer> and <location> variables --> {{CONFERENCENAME}}, {{CONFERENCEVENUE}}, {{CONFERENCECITY}}, {{CONFERENCEPLACE}}, {{CONFERENCECOUNTRY}}, {{CONFERENCECAPACITY}}, {{CONFERENCEDESCRIPTION}} parser function --> {{#cvext-page-link}} 7. Sidebar modification (added some new portals for the conference) 8. Schedule Template System - which automates the process of creating a schedule for the conference, as new locations and events are added to the system. 9. Content Pages - these are the default set of pages that are created for the conference by the extension (Note : these are just like any other wiki pages whose content can be modified using the wiki interface) *2. Things yet to be done !* * * 1. *DB rollback implementation in most of my model classes 2. *Account Setup Page (for registration of users) 3. *Modification of User pages for displaying content related to the conference 3. Organizer management module (most part of it is already implemented in the basic architecture, just some additions needed regarding the permissions and rights for this group) 4. Payment Gateway 5. Support for languages other than English 6. Some more parser functions and variables which would help in editing the content pages of the conference * - These features were not completed during the GSoC period. I really enjoyed my experience of working with such a vibrant community over this summer, especially thankful to all the people who helped me out in the IRC channel may it be regarding the setting up of labs, or helping me out with the localisation issues, or even suggesting me come up with a better feature than what I had already implemented. Other community fellows who reviewed my big chunks of code, many issues which I very easily missed were pointed out with a proper explanation of what needs to be done, have helped me a great deal in improving it. And finally I would like to thank Sumana and Greg for managing this program so well, and my mentor Jure Kajzer for his unmatched support and guidance throughout the summer. Some important links: Proposal Page - http://www.mediawiki.org/wiki/User:Chughakshay16/GSOCProposal(2012) Gerrit changesets - https://gerrit.wikimedia.org/r/#/q/ConventionExtension,n,z Extension Page - http://www.mediawiki.org/wiki/Extension:ConventionExtension Suggestions are always welcome ! -- Thanks, Akshay Chugh skype- chughakshay16 irc - chughakshay16(#mediawiki) [[User:Chughakshay16]] on mediawiki.org

13 17

Improving Documentation on Handling Bug Reports
by Andre Klapper 29 Oct '12

29 Oct '12

Hi everybody, at last weekend's Hackathon I investigated how to get into bug management/triaging in Wikimedia. I'd like to propose some changes in order to streamline, harmonize and centralize documentation in order to make it easier to get involved: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#Improv… Feedback, comments, criticism on this draft are very welcome. andre -- Andre Klapper (maemo.org bugmaster & GNOME Bugsquad) http://blogs.gnome.org/aklapper/

8 10

scaled media (thumbs) as *temporary* files, not stored forever
by Ariel T. Glenn 24 Oct '12

24 Oct '12

So it's time to have this discussion again. At least, I think we're having it again, though I could not find previous threads on this list about the subject. In short, scaled media is currently generated on the fly for any size and for any user. The resulting files are kept around forever or until we run perilously short of space, at which point we make some guesses about what we can toss and then do a mass purge. Last time we did so, we had the rotation bug going at the same time, which made for a real fine mess. A little bit of crunching shows me that we have about 6 million images in use on the projects, and yet we manage to have around 130 million thumbnails. Just for fun I checked to see how many thumbs each image has, what sizes we are looking at, etc. Here's the results. Some "standard" sizes are most popular, with between 200K and 640K media files having thumbs scaled to each of these widths: 75, 120, 150, 180, 200, 220, 320, 640, 800, 1024, and 1280 pixels But there's plenty of "odd" sizes with lots of thumbs too. For example, over 65K files with width 181px, 20K with width 138px. As an experiment and before having this data, I purged from ms5 (no longer in use for thumbs) 1/16 of the thumbs that were greater than 100px wide but not one of these widths: 120px, 200px, 220px, 250px, 320px, 640px, 800px We got back over 300GB of space. The other thing about delivering any scaled version on demand is that we have some media files with several hundred different thumb sizes in there. Here's a few of the top offenders for your entertainment: 2514 wikipedia/commons/thumb/f/f9/Orange_and_cross_section.jpg 2285 wikipedia/commons/thumb/f/fb/Thrermal_grease.jpg 2218 wikipedia/commons/thumb/f/fc/Blue_sport.jpg 2071 wikipedia/commons/thumb/f/f3/Flag_of_Switzerland.svg 2062 wikipedia/commons/thumb/f/f2/Flag_of_Costa_Rica.svg 2034 wikipedia/commons/thumb/f/f8/Wiktionary-logo-en.svg 1915 wikipedia/commons/thumb/f/f6/VeulesLesRoses.JPG 1689 wikipedia/commons/thumb/f/fa/Wikibooks-logo.svg 1447 wikipedia/commons/thumb/f/fa/Wikiquote-logo.svg 1371 wikipedia/commons/thumb/f/f0/Mori_Uncanny_Valley.svg 1249 wikipedia/commons/thumb/f/f5/Grand_prismatic_spring.jpg 1246 wikipedia/commons/thumb/f/f3/Mature.jpg 1191 wikipedia/commons/thumb/f/f7/Kirchdorf_in_Tirol.JPG 1187 wikipedia/commons/thumb/f/f8/Camille_Cabral_pour_les_Trans.JPG 1143 wikipedia/commons/thumb/f/f7/Profanity.svg 1079 wikipedia/commons/thumb/f/f2/HSV_color_solid_cone.png 1040 wikipedia/commons/thumb/f/f2/Carmen_Electra.jpg 1032 wikipedia/commons/thumb/f/f1/Pink_eye.jpg 1001 wikipedia/commons/thumb/f/f6/USNS_Medgar_Evers_announcement.jpg I'd comment on some of those but I'd be too snarky. So there are some things we could change: 1. We could generate and keep only certain sizes, tossing the rest. 2. We could keep *nothing*, scaling all media as required. 3. We could have a cron job that was clever about tossing thumbs every day (not sure how easy it would be to be clever). 4. ?? In any of these cases, the squids will have copies of recently requested scaled media, so we won't be scaling the same file to the same size over and over in a short time frame. What do folks think about how to proceed? Ariel

26 50

Gerrit question: pushing to another branch
by Jeroen De Dauw 24 Oct '12

24 Oct '12

Hey, Is it possible to push to a branch other then the default one on gerrit using git review? This is needed when you want to have more then one branch on which you have reviewed code, or if you want different levels of review. For example if you want a novice committer play around with an extension a bit and push new functionality that gets reviewed but is not ready to go onto master until it really has stabilized and finalized. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --

10 12

best way to clean up the wiki from 3Gb of spam
by Yury Katkov 06 Oct '12

06 Oct '12

Hi everyone! I have found myself in the following situation several times: I created a wiki for some event or small project, everything works fine and after the event or project was done - nobody have seen this wiki for several months and does nothing on it. After several months somebody needs the wiki once again and realizes that the wiki database now have 3 Gb of text spam. Suppose that there is no back-up or rollback option in a wiki hosting. So here is the question: how to 1) remove all the spam 2) delete all the spam accounts 3) reduce the database size from 3Gb to the original size Cheers, Yury Katkov, WikiVote

8 24

translatewiki.net ending localisation support for svn.wikimedia.org MediaWiki extensions
by Siebrand Mazeland 03 Oct '12

03 Oct '12

Dear all, Starting October 1, 2012, translatewiki.net will drop support for all MediaWiki extensions it currently supports that still remain in the Subversion repository svn.wikimedia.org. Many, if not all of the extensions that by that time have not been migrated to git/Gerrit, are clearly not that well maintained and we want to prevent our translators from spending their time on it. At the moment, a maximum of 273 extensions are affected. In case this message makes you wonder what git and Gerrit is all about, and how you can revive your precious extension, please see the following links: * https://www.mediawiki.org/wiki/Git/Tutorial * https://www.mediawiki.org/wiki/Git/Conversion/Extensions_queue Cheers! Siebrand

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 August 2012