Our patch for the Internet Explorer 6 XSS issue (bug 28235) released
two days ago in 1.16.3 was insufficient to fix that bug. The original
reporter, Masato Kinugawa, pointed out the flaw on bug 28507. So we
are doing another release, which contains a second attempt at fixing
the issue.
Apologies to everyone for the inconvenience. Big thanks go to Masato
Kinugawa for helping to keep MediaWiki secure. Thanks also to Roan
Kattouw who helped me test the patch this time around, so that we can
hopefully avoid a repeat.
It is necessary to upgrade MediaWiki to avoid an XSS vulnerability for
Internet Explorer clients, version 6 and earlier. Also, if you used
the Apache configuration I suggested in the previous release
announcement, you should update it to:
RewriteEngine On
RewriteCond %{QUERY_STRING} \.[a-z0-9]{1,4}(#|\?|$) [nocase]
RewriteRule . - [forbidden]
We missed the fact that there can be more than one question mark in a
URL. In certain circumstances, IE 6 will use a file extension
immediately before a question mark character, regardless of how many
question marks precede it. For example, with the URL:
http://example.com/a?b?c.html?d?e
IE 6 will see the file extension as ".html".
**********************************************************************
Download:
http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.4.tar.gz
Patch to previous version (1.16.3):
http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.4.patch.gz
GPG signatures:
http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.4.tar.gz.sighttp://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.4.patch.gz.sig
Public keys:
https://secure.wikimedia.org/keys.html
The April run of the english history dumps is incomplete. There is at
least one file that will need to be regenerated. When it's ready I'll
send an email update. I expect a delay of 4-5 days for that.
Ariel
Instead of waiting until Wednesday like I did last week, this week I'll
get right to it.
The bug triage was at Noon PDT, so our European developers (Sam, Roan,
etc.) were able to participate this week. Last week was a call for
Parser bugs and ended up being a tour of golden oldies. This week, I
tried to keep it more up-to-date and current. I feel like I mostly
succeeded.
Without further delay, the results of the triage:
When using existing DB user, grants aren't added to new tables
http://bugzilla.wikimedia.org/28375:
Bumped to highest priority since it is tarball blocker
Fatal Error if logged in
http://bugzilla.wikimedia.org/28439:
LQT bug. Low priority since Andrew is currently rewriting this.
Caching problems with mobile_main_page
http://bugzilla.wikimedia.org/22014
Pinged Tomasz… opening new bug on Canonical URL redirection.
related canonical URL redirection issue: https://bugzilla.wikimedia.org/27935
After much discussion created https://bugzilla.wikimedia.org/28602 - Canonicalize URLs
Old version seen immediately after edit
http://bugzilla.wikimedia.org/27891
Tim gave this the first fix, but it might need another.
Vector EditWarning breaks page caching. Edits get erased when
navigating back and forth
http://bugzilla.wikimedia.org/22680
Assigned to Roan
When $wgSpamRegex is triggered be sure to return to editing and not
throw the users work away
http://bugzilla.wikimedia.org/25985
Slated for 1.18 fix
High REOPENED When inserting text in iframe mode (using toolbar,
special characters or dialogs) the edit window scrolls
http://bugzilla.wikimedia.org/23052
Current bug was fixed, Bug was hijacked. Split off new issue into
Bug #28603 Toolbar buttons don't correctly insert lists
lucene search for simple text misses some results
http://bugzilla.wikimedia.org/25404
Searching is not working on Korean Wikinews and others.
http://bugzilla.wikimedia.org/25586
Ops is aware, new search indexer will be set up soon. All should
be fine in a few days
Normal NEW deformed layout of ogg player options in new gallery
http://bugzilla.wikimedia.org/27982
merge queue
in IE9 #p-personal portlet links are shown vertically in RTL wikis with Vector
http://bugzilla.wikimedia.org/28438
Kaldari will get IE9 set up for testing and fix this one.
Upload stash API allows some kinds of resource exhaustion
http://bugzilla.wikimedia.org/26063
This a low-risk threat that can be handled by MW or cron garbage
collection.
Languagelinks aren't working on talk pages
http://bugzilla.wikimedia.org/26085
WONTFIX for reasons outlined in the bug. Opened
https://bugzilla.wikimedia.org/28604 based on
discussion. See comment 12:
https://bugzilla.wikimedia.org/26085#c12
Special:Undelete doesn't use ar_page_id
http://bugzilla.wikimedia.org/26123
Specifically responding to comment #3: non issue since we sort by
time.
A file redirect from a foreign File Repo overrides local wiki page
(instead of vice versa)
http://bugzilla.wikimedia.org/28299
Best decribed in #c2: https://bugzilla.wikimedia.org/show_bug.cgi?id=28299#c2
If it's _not_ affecting page views / editing it may not actually
be an issue; if it is, those things need fixing.
self unblock with username does not work under 1.17
http://bugzilla.wikimedia.org/28352
Apparently fixed in trunk. I’ll find the revision. Or find
someone to find the revision.
"Block::purgeExpired" Database returned error "1205: Lock wait timeout
exceeded;"
http://bugzilla.wikimedia.org/28485
Article::updateCategoryCounts 1213 Deadlock found when trying to get lock
http://bugzilla.wikimedia.org/28543
1205: Lock wait timeout exceeded; try restarting transaction
http://bugzilla.wikimedia.org/28499
Roan looked at this and saw it focused around a single user on a
single wiki. Trying to get another person to look at this one.
Escape asterisks (*) in {{PAGENAME}}
http://bugzilla.wikimedia.org/28588
Parser bug with a workaround: {{#tag:nowiki|{{PAGENAME}}}}
tagged for newparser
Edit notices display "edit" tab instead of "view source" even if the
editor cannot edit them
http://bugzilla.wikimedia.org/28589
Not bumping up priority or assigning
IE upload fails silently on Enter key from wpDestFile
http://bugzilla.wikimedia.org/25885
Neil will investigate,
Replace MD5 password hashing with WHIRLPOOL
http://bugzilla.wikimedia.org/28419
Letting Tim set priority since this is his idea.
printable version centered images are not centered
http://bugzilla.wikimedia.org/28573
Kaldari will do it
Remove stub link formatting user preference from MediaWiki core
http://bugzilla.wikimedia.org/28426
Get some stats from wmf wikis (presumably fairly popular on small
wikis). Roan's running it.
Configure which sections of the sidebar navigation menu are
expanded/collapsed by default
http://bugzilla.wikimedia.org/25394
Parsing the sidebar even more, perhaps wait untill the GUI
Special:Sidebar thing is ready (GSoC) so we can store cleanly in
db
I did ask for UI bugs from the wikitech-l last week and got two from
Amir, one of which I included. Discussion during the Triage mirrored
discussion on the list last week, and we decided this one was a very low
priority fix:
diff radio buttons in revision history are not vertically aligned when
"Justify paragraphs" is enabled
http://bugzilla.wikimedia.org/28359
The other bug I included (from those mentioned on the list) was MZ
McBride's. Trevor proposed an improved 404 page last August but no one
was taken the time to put it up. Priyanka said she would take charge of
the “shell” aspects of this bug:
Redesign the wmf non-mediawiki 404 error page
http://bugzilla.wikimedia.org/17316
Full notes from the triage are at: http://etherpad.wikimedia.org/BugTriage
Mark.
Continuing with my changes to $wgOut, $wgUser, Skin, and SpecialPage
patterns.
The Linker is now static, $sk->link will still work, however you should
not be requiring a Skin anymore to use linker methods. Please use
Linker::link directly.
The only exception is the method to create an editsection link, that
method IS part of Skin itself now.
Also there is some compat for hooks that were passed the linker as an
instance, and `$parserOptions->getSkin();` However note that
ParserOptions::getSkin no longer returns an actual Skin, it now returns
a plain linker instance and makes a depreciated call.
((for reference the 'instance' of Linker which is static is actually a
"DummyLinker" class which has a __call that forwards old method calls to
static calls to the linker))
So nearly EVERY case you are currently grabbing a Skin for, you should
no longer be fetching a skin.
Now, if you really do need a skin, the the new way to get a skin is
`$context->getSkin()`, OutputPage has a helper `$out->getSkin()` if you
happen to be working on OutputPage related stuff and need to interact
with the skin. `$wgUser->getSkin();` has some BackCompat to keep
working, however please avoid using it, it uses the main RequestContext,
not whatever the RequestContext for whatever context you are in is.
Also, there is no equivalent to `$wgUser->getSkin( $title );`. Skin no
longer has a mTitle of it's own, it gets the title used in the attached
RequestContext, which is the same one that OutputPage uses, and is
essentially the replacement to $wgTitle. So you don't need to work
around bugs like that in Skin, nor in OutputPage anymore. Additionally
that format was never actually used right, nearly every call to that was
actually made in contexts where one was using the Linker methods (which
don't use mTitle) and was not interacting with the skin.
I started a page on the RequestContext object:
http://www.mediawiki.org/wiki/Request_Context
---- some extra ----
I'm still contemplating skin setting and relation to context right now.
I would like to make it possible to do something like
`$context->setSkin( new DummyOfflineSkin );` but also want to avoid bugs
where you try to set the same skin onto two contexts and get an error.
I examined the code paths, and Skin doesn't actually make any
RequestContext dependent calls except inside calls made from the
Skin::outputPage( $out ); entrypoint which is called by
OutputPage::output();, in other words theoretically I could avoid tying
a Skin instance to any specific context by setting the context at the
start of Skin::outputPage( $out ) ($out provides the RequestContext),
and exiting that context when it's done. However there is one instance
where this rule is broken, ApiParse which makes a direct call outside of
that context when you use categoryhtml or languagehtml (which I wanted
to stop from being released from the start).
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
It's been re-cloned and is being updated every 10 minutes.
Note that this was a non-fast-forward updates, so "git pull" on
existing checkouts won't work, you'll have to re-clone.
On the plus side this is now being cloned directly from svn, e.g. this
is the latest commit:
git-svn-id:
svn+ssh://svn.wikimedia.org/svnroot/mediawiki/trunk@86256
dd0e9695-b195-4be7-bd10-2dea1a65a6b6
This means that using this to bootstap your own git-svn checkout (to
use for further development) should be possible now, but I don't have
instructions for how to do that, patches to
http://www.mediawiki.org/wiki/Git#Rebuilding_SVN_metadata welcome.
Note that this is still out of date:
http://gitorious.org/mediawiki
I don't know who maintains it, but if there's demand for having one on
gitorious I'd be happy to update that one too. It's just a matter of
adding a couple of extra pushes here:
https://github.com/avar/mediawiki-mirror/blob/master/mediawiki-mirror.sh#L22
2011/4/14 Mark Hershberger <mhershberger(a)wikimedia.org>:
> Sorry, I should have been clearer. Yes, branch now(ish) and then aim for a
> 1.18 release on July 15th. My idea is that setting a date for the release
> to be soon and early would provide the motivation to the people involved in
> code review to keep it up-to-date.
>
The point I was trying to make was that July is by no means "soon and
early" in my book. It's three months away, which is way to long.
Setting a date is nice, but if we can get a release out before the set
date, that's a good thing, and I think we can (and /should/) get 1.18
out way faster.
Roan Kattouw (Catrope)
This is a fork of this thread:
http://www.gossamer-threads.com/lists/wiki/wikitech/228949?page=last
Is there a possibility that I could instead (easily) merge the handful
of individual wiki's content into one consolidated wiki and implement a
more enhanced search against it instead? I've no experience performing a
merge like this so expert advice would be appreciated!
Thanks - Tod
Hi.
I'm getting close to releasing JSWikiGantt extension and I'm wondering
if this should go to SVN or not? And in effect should I ask for commit
access to SVN or not. I have my own server so I can put my code there,
but I'm not sure what are the habits with extensions.
Just to clarify what the extension is - it's basically a port of JSGantt
to MediaWiki. It allows injecting Gantt diagrams as XML into articles.
There's certainly a lot room for improvement (like e.g. an ability to
have more then one diagram per page) and I still need to go for i18n,
but that should be ready soon (I hope).
BTW are there any guidelines (or at least good examples) of i18n in JS?
What I mean is - I need to use some (most) localized strings in JS and
would like to use existing code (if possible) for pushing strings from
PHP to JS.
I also have another extension for editing diagrams of certain type -
namely calendar-diagrams for activities such as "Delegation",
"Vacation", "Sick leave". From what I've read this probably shouldn't go
to SVN or should it?
Oh, both extensions where written for 1.16, but I'm mostly using JS
anyway so this probably shouldn't matter.
Regards,
Nux.
Extension and Core:
* Patrick Reilly (preilly)
Patrick has joined the WMF engineering team as Sr. Software Developer
for mobile.
--
Priyanka Dhanda
Code Maintenance Engineer
Wikimedia Foundation
http://wikimediafoundation.org
San Francisco, CA