Wikitech-l April 2013

wikitech-l@lists.wikimedia.org

174 participants
212 discussions

MediaWiki Security Release: 1.20.4 and 1.19.5
by Chris Steipp 15 Apr '13

15 Apr '13

I would like to announce the release of MediaWiki 1.20.4 and 1.19.5. These releases fix 3 security related bugs that could affect users of MediaWiki. Download links are given at the end of this email. * An internal review discovered that specially crafted Lua function names could lead to XSS. <https://bugzilla.wikimedia.org/show_bug.cgi?id=46084> * Daniel Franke reported that during SVG parsing, MediaWiki failed to prevent XML external entity (XXE) processing. This could lead to local file disclosure, or potentially remote command execution in environments that have enabled expect:// handling. <https://bugzilla.wikimedia.org/show_bug.cgi?id=46859> * Internal review also discovered that Special:Import, and Extension:RSS failed to prevent XML external entity (XXE) processing. <https://bugzilla.wikimedia.org/show_bug.cgi?id=47251> Full release notes for 1.20.4: <https://www.mediawiki.org/wiki/Release_notes/1.20> Full release notes for 1.19.5: <https://www.mediawiki.org/wiki/Release_notes/1.19> For information about how to upgrade, see <https://www.mediawiki.org/wiki/Manual:Upgrading> ********************************************************************** 1.20.4 ********************************************************************** Download: http://download.wikimedia.org/mediawiki/1.20/mediawiki-1.20.4.tar.gz Patch to previous version (1.20.3): http://download.wikimedia.org/mediawiki/1.20/mediawiki-1.20.4.patch.gz GPG signatures: http://download.wikimedia.org/mediawiki/1.20/mediawiki-1.20.4.tar.gz.sig http://download.wikimedia.org/mediawiki/1.20/mediawiki-1.20.4.patch.gz.sig Public keys: https://secure.wikimedia.org/keys.html ********************************************************************** 1.19.5 ********************************************************************** Download: http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.5.tar.gz Patch to previous version (1.19.4): http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.5.patch.gz GPG signatures: http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.5.tar.gz.sig http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.5.patch.gz.sig Public keys: https://secure.wikimedia.org/keys.html ********************************************************************** Extension:RSS ********************************************************************** Information and Download: https://www.mediawiki.org/wiki/Extension:RSS

1 0

Pushing Technical changes to Wikimedia projects
by Denny Vrandečić 15 Apr '13

15 Apr '13

Technical changes on the Wikimedia projects can be hairy. We are currently having a discussion about the Wikidata deployment to the Wikipedias, and there have been many examples in the past of deployments that raised discussions. One of my statements in this discussion is that the a priori discussion of such features is highly undemocratic. What I mean with that is that design and deployment decisions are often made by a very small group, which are in the best case a part of the affected community, but, in many cases, even external to the affected community. So the decisions are made by a group that does not represent or is constituted by the community - which I mean with undemocratic. This has repeatedly raised criticism. And I think that criticism is often unfair. Additionally, it is usually true (which makes is not anymore fair, though). I thought that in order to discuss these design decisions with the community before hand, telling them on their respective village pump is sufficient. Not so it seems. No single channel would find acceptance to communicate with the community. This, obviously means, that it is not actionable to communicate with the community. What about setting up a community selected body of representatives to discuss such issues beforehand? At first, it sounds like a good idea - but the issue is, it makes the process only more complicated without at all resolving the underlying issues. Does anyone really think that such a body would stop the criticism before or after the deployment of the change in question? Yeah, right. Doesn't change a thing. So, what do I want to achieve with this Mail? Merely to ask some community members to be a bit more constructive in their comments. Claiming that the product managers and designers have no idea of the Wikimedia communities and the use of wikis is often neither help- nor truthful. What would be even better would be to come up with processes or mechanisms to avoid these issues in the future. I would be very glad if the people who are often critically accompanying such changes would help in building effective channels for their discussion. Any thoughts? -- Project director Wikidata Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

9 12

Gadget-Reviews
by Lukas Benedix 15 Apr '13

15 Apr '13

Hi, Is there any written policy about the review-process for Gadgets? For Extensions I found a document, that says an Extension should: get a design review, be internationalized, get a code review and finally get a deployment review. [https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment] I can't find any rules like this for Gadgets, but I see lot's of Gadgets set default in several Wikis. I think Gadgets can be designed badly and have security flaws as well as Extensions… so there shouldn't there exists some review process? best regards, Lukas

5 6

Problems with file deletion on Commons
by Eugene Zelenko 15 Apr '13

15 Apr '13

Hi! I'd like to bring to attention of developers and system administrators problems with file deletion on Commons: http://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard#Dai… Sorry, if it's known issue, but it persist for several days and definitely affects administrators job. Eugene.

2 1

Next bugday: Apr 15, 16:00-20:00UTC on old reports without updates for 18 months
by Andre Klapper 15 Apr '13

15 Apr '13

Hi everybody, Please join us on the next Wikimedia Bugday: Monday, April 15th, 16:00-20:00 UTC [1] in #wikimedia-office on Freenode IRC [2] We are going to take a look at old reports, trying to reproduce some plus provide feedback. Currently these are about 140 tickets (see [3] for a list). Everyone is welcome to join, and no technical knowledge needed! It's a nice and easy way to get involved in the community or to give something back. Join IRC, say hello and that you're here for the bugday, and have fun. This information and more can be found here: https://www.mediawiki.org/wiki/Bug_management/Triage/20130415 For more information on Triaging in general, check out https://www.mediawiki.org/wiki/Bug_management/Triage We look forward to seeing you! andre (PS: You can find the results of the last bug day here: https://www.mediawiki.org/wiki/Bug_management/Triage/20130402 ) [1] Timezone converter: http://www.timeanddate.com/worldclock/converter.html [2] See http://meta.wikimedia.org/wiki/IRC for more info on IRC chat [3] https://bugzilla.wikimedia.org/buglist.cgi?bug_severity=blocker&bug_severit… -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/

1 1

HTML versioning information in skins?
by Bartosz Dziewoński 15 Apr '13

15 Apr '13

tl;dr: Let's add class="skintimestamp-YYYYMMDD" to <body> in all skins, so we can make HTML+CSS changes without breaking the sites. [Resending as it doesn't seem to have gotten through the first time.] We need HTML versioning information needed in skins to be able to cleanly make incompatible CSS changes. In the Wikimedia setup generated page HTML is cached for ~30 days regardless of skin HTML changes, while CSS&JS is purged at most a few minutes after a change is deployed. This is a highly suboptimal situation, as this means that in every change that modifies both the HTML and the CSS, the CSS must be backwards-compatible with old HTML. This requires a lot of care and additional awkward testing and causes major issues when not done carefully enough (e.g. bug 42452), and sometimes just isn't possible at all unless some transitional hacks are inserted (e.g. bug 46947). Luckily this isn't an issue for most third-party wikis, as `php update.php` after upgrade purges the cache entirely. ---- I'm proposing adding another class to <body>, "skintimestamp-YYYYMMDD", where YYYYMMDD is the year, month and day of the time that given skin's HTML was last modified in an incompatible way. Day should be enough granularity to avoid conflicts while keeping the class name short enough. This can be easily done using the addToBodyAttributes() method of the Skin class. The timestamp would be updated manually by whoever is making those changes, and the class could be used in the CSS to only apply new styles to newly generated HTML. Older styles could be simply left intact, and then removed after enough time has passed. If multiple incompatible changes are ever done in overlapping time periods, the successive ones would include updates to the "old new" styles to use both the new and old class. Thoughts? [Bug for this is https://bugzilla.wikimedia.org/show_bug.cgi?id=46956 , but let's keep the discussion here, please.] -- Matma Rex

3 4

Scribunto REPL (debug console)
by Ori Livneh 15 Apr '13

15 Apr '13

Small Python script to run an interactive Scribunto session in your terminal, using Scribunto's API module: https://gist.github.com/atdt/5382043/raw/d083ff757066200728c0b50992ab6c7bb1… :) -- Ori Livneh

5 5

Updating the dump file?
by Sajid Hussain 14 Apr '13

14 Apr '13

Hi!. I downloaded “pages-articles.xml.bz2″ and I am using it through WikiTaxi. It’s working fine but I have a question. I downloaded the above mentioned dump which was created in Jan. 2013. Now there’s the new version of this dump available created in April 2013. My question is can I update my older dump to the current one without downloading all the data? I only need the updates. Please help. -- Sajid Hussain,

3 2

vagrant issues
by Moritz Schubotz 14 Apr '13

14 Apr '13

Hi, after updateing my vgrant folder via git deleting the oracle vm folder and recreating the vm I have two issues 1) there is no database wiki; only test without tables. 2) if I log in I get the following message -bash: /etc/virtualbox-version: No such file or directory Your VirtualBox guest additions are out-of-date. Please run 'update-guest-additions'. Is there a way to recreate the db? Best regards physikerwelt -- Mit freundlichen Grüßen Moritz Schubotz Telefon (Büro): +49 30 314 22784 Telefon (Privat):+49 30 488 27330 E-Mail: schubotz(a)itp.physik.tu-berlin.de Web: http://www.physikerwelt.de Skype: Schubi87 ICQ: 200302764 Msn: Moritz(a)Schubotz.de

2 3

Recycling wikitech-announce for tech contributors
by Quim Gil 13 Apr '13

13 Apr '13

Hi, We were missing a way to notify tech contributors and volunteers about new activities, and after some discussion [1] we have decided to recycle the unused https://lists.wikimedia.org/mailman/listinfo/wikitech-announce Subscribers will receive CALLS FOR ACTION ONLY e.g. for activities like the ones listed at https://www.mediawiki.org/wiki/Project:Calendar. No announcements of new releases, features removed, etc. We have channels already for that. We will sync the announcements at wikitech-announce with with wikitech-l and wikitech-ambassadors. While this is not a big deal for current contributors following already wikitech-l and a number of wiki pages etc, it will help potential volunteers willing to get involved and know about opportunities to contribute. [1] https://www.mediawiki.org/wiki/Project_talk:New_contributors#How_to_solve_N… PS: before clicking reply please read http://www.gossamer-threads.com/lists/wiki/wikitech/282349 :) -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

1 0

← Newer
1
...
12
13
14
15
16
17
18
...
22
Older →

Jump to page:

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 April 2013