Hi all,
I would like to ask for deployment of new version of Gadgets
extension. It would be great to get rid of MediaWiki:Common.js by
splitting it into separate gadgets, enabled for everyone by default.
Any registered user will be able to disable functionality he/she does
not like. What is more, it will simplify loading additional
dependencies - now it is done by importScript etc. and allow to take
advantage of Resource Loader.
Regards,
Ildefons Stułbia
I missed the report on last week's bug triage, so to keep that snafu
from repeating, you're getting this report right away. You can see
the notes we made during the meeting on etherpad: http://hexm.de/37
(Note that in this report I reference the weekend sprints I have posted
to the list in the past a few times here. After some encouragement at
the Berlin Hack-a-thon and elsewhere, I plan to revive them this
weekend.)
=== Block notice when editing talk page of blocked user doesn't go away
after block expires ===
https://bugzilla.wikimedia.org/27858
Besides the problem that I managed to reproduce on enwiki, I brought
this bug up because of bawolff's comment that he “has never liked how
we only modify some timestamps for timezone”
I will try to reproduce this particular bug again after setting my
preferences – I think it really is a bug.
As far as the larger problem, MediaWiki's inconsistent time display
behavior, I've created a tracking bug
(https://bugzilla.wikimedia.org/29235 MediaWiki is inconsistent in how
it displays time) under which I'll try to gather instances of this
problem.
=== Allow different directionality (rtl/ltr) for user interface and wiki
content ===
https://bugzilla.wikimedia.org/6100
Robla put a note on this bug that indicated in might have been fixed
and then reverted. Confused, I brought it up again so that we could
discuss what was really needed to fix this bug.
The revision indicated in Robla's comment was related to this bug, but
was only a small part of fixing it. Discussion with other developers
indicates that this isn't a trivial problem but would be a major
new feature.
=== Upgrade fails "Unknown character set: 'mysql4'" ===
https://bugzilla.wikimedia.org/29102
I'm going to try to get Chad to fix this one. Depending on his
availability, I may have a go myself.
=== Cannot remove watchlist junk, either in Edit Watchlist page or by
editing raw watchlist ===
https://bugzilla.wikimedia.org/28936
I had trouble testing this, but it looks like it is a real problem
with how watchlists work when pages are removed. Roan put some steps
for reproducing this into Etherpad and I'll work on getting them into
Bugzilla and, perhaps, making an easy test case.
=== Long external link (which exceeds 313 characters) crashes PHP in
Windows ===
https://bugzilla.wikimedia.org/29197
This is probably an upstream PHP/libpcre bug, and, so far, only
reproducible on Windows XAMP. We briefly discussed testing for this
and warning about it during installation. We're working around it now
by using different regular expressions.
=== Pages loading without formatting too often ===
https://bugzilla.wikimedia.org/29153
This seems to be a frequently reported problem with 1.17, but it
doesn't seem to be easily reproducible. I've updated the bug asking
if the reporter can reproduce this easily.
[If anyone reading this can reproduce the problem in a fairly
consistent matter, please contact me.]
=== Implement a way for authorized users to use Special:PasswordReset on
other usernames ===
https://bugzilla.wikimedia.org/29135
A valid feature request, but just that. T. Gries has provided a lot
of details, so this makes a good one for me to promote for a weekend
sprint.
=== Slowness in accessing English Wikipedia ===
https://bugzilla.wikimedia.org/29034
Someone from Canada weighed in on this last week. I brought it up
during the dev triage in case someone there had an idea, but it looks
like I need to find out the status from Ops.
=== protected page not protected. user can edit ===
https://bugzilla.wikimedia.org/29021
This looks like it is the result of an unclear log message or a
misinterpretation of the message. We don't plan on taking any action.
=== Require token for watching/unwatching pages ===
https://bugzilla.wikimedia.org/27655
This is a bug to fix a CSRF issue. During the triage meeting, Krinkle
told us that he and Reedy had been working on this but needed someone
else to follow it the rest of the way. I assigned the rest of the
work (making the the non-javascript fallback use a token) to Bryan.
=== width of <gallery> always 100% ===
https://bugzilla.wikimedia.org/27540
I have put an example of the issue here: http://hexm.de/3b.
This is another good candidate for a weekend sprint.
== Ancient bugs with recent patches ==
For this week's triage, I tried adding in some ancient bugs with
recently submitted patches. My thinking was that someone has made an
effort to fix these recently. I'll probably use these from now on for
weekend sprints, but not bring them up in Triage meetings.
In any case here they are:
=== Suppressed edits still appear in Special:DeletedContributions and
Special:Undelete ===
https://bugzilla.wikimedia.org/19725
=== lang and hreflang attributes for interwiki links ===
https://bugzilla.wikimedia.org/4901
=== Different diff-colors no to discriminate red-green color blinds ===
https://bugzilla.wikimedia.org/11374
(Krinkle actually started working on making a gadget for this after
the Triage meeting.)
=== Email notification mistakes log action for new page creation ===
https://bugzilla.wikimedia.org/14901
(I'm going to commit the provided patches.)
=== $wgSharedDB PostgreSQL support ===
https://bugzilla.wikimedia.org/16794
(After spotting this series of patches, I think we may have found
someone to help maintain the PostgreSQL support.)
=== WAI-ARIA landmark roles to improve accessibility ===
https://bugzilla.wikimedia.org/18338
(This needs a bit more research… does anyone with a screen reader want
to be my guinea pig?)
2011/6/3 Jon Harald Søby <jhsoby(a)gmail.com>:
> The only reason I can see for not allowing embedding is that
> embedding would be promoting YouTube
Embedding YouTube videos in Wikimedia content would send IP addresses
and other information about Wikimedia users to Google. This is
against Wikimedia's privacy policy, as I understand it, and it would
certainly upset a lot of people. I think it's extremely unlikely to
happen.
Hi.
Aryeh mentioned that Wikimedia wikis still aren't using HTML5. I know it was
enabled a few times and is currently disabled. As far as I remember, the
biggest issue was third-party tools and such, which seemed solvable by
announcing the change early (letting any developers know that
test.wikipedia.org is using HTML5 currently, of course) and then making the
switch a few weeks later. Is that generally correct, and if so, can we start
that process? If that's not correct, what are the outstanding issues?
Related bug: <https://bugzilla.wikimedia.org/show_bug.cgi?id=27478>.
MZMcBride
Hello,
Last year there where a lot of discussions about projects inside wikimedia
that needed to be renamed. The last thing I can remember is that it wasn't
possible at that time. However I would like to know if something changed
since the last discussion?
There are like 5 or 6 projects under discussion that /could/ be renamed, so
the question remains: Is it possible?
--
Kind regards,
Huib Laurens
WickedWay.nl
Is there a way we can narrow down this security check so it doesn't keep
breaking API requests, action=raw requests, and ResourceLoader requests,
etc?
Having the last param in a query string end in say ".png" or ".svg" or
".jpg" or ".ogg" is..... very frequent when dealing with uploaded files and
file pages. In addition to the reported breakages with ResourceLoader, I've
seen this problem break classic-style action=raw site CSS page loads
(action=raw&title=MediaWiki:Filepage.css) and API requests for
MwEmbed+TimedMediaHandler's video player, for the OEmbed extension I'm
fiddling with, etc.
The impression I get is this is:
1) only exploitable on IE 6 (which is now a small minority and getting
smaller)
2) only exploitable if the path portion of the URL does not include an
unencoded period (eg 'api' or 'api%2Ephp' instead of 'api.php')
3) only exploitable if raw HTML fragments can be injected into the output,
eg a '<body' or other that triggers IE's HTML detection
For 1) I'm honestly a bit willing to sacrifice a few IE 6 users at this
point; the vendor's dropped support, shipped three major versions, and is
actively campaigning to get the remaining users to upgrade. :) But I get
protecting, so if we can find a workaround that's ok.
For 2) ... if we can detect this it would be great as we could avoid
breaking *any* api.php, index.php, or load.php requests in most real-world
situations.
For 3) ... formatted & XML output from the API should always be safe as,
even if it triggers XML/HTML detection you can't slip in arbitrary <script>
bits. JSON output seems to be the problematic vector currently, as you can
manage to get arbitrary strings embedded in some places like error messages:
{"warnings":{"siteinfo":{"*":"Unrecognized value for parameter
'siprop': <body onload=alert(1)>.html"}}}
On the other hand if our JSON output escaped '<' and '>' characters you'd
get this totally safe document:
{"warnings":{"siteinfo":{"*":"Unrecognized value for parameter
'siprop': \u003Cbody onload=alert(1)\u003E.html"}}}
I tested this by slipping a couple lines into ApiFormatJson:
$this->printText(
$prefix .
str_replace( '<', '\\u003C',
str_replace( '>', '\\u003E',
FormatJson::encode( $this->getResultData(),
$this->getIsHtml() ) ) ) .
$suffix
);
and can confirm that IE 6 doesn't execute the script bit.
Are there any additional exploit vectors for API output other than HTML tags
mixed unescaped into JSON?
-- brion
So the Open Library, a project by the Internet Archive that has a structured
wiki page for every book and which also lends books online, has announced
they just got new "Read" API.[1, 2] The announcement describes its as:
"The idea is, you can hit the Read API with an identifier or a series of
identifiers or an array of identifiers, and it will tell whether there is a
readable or borrowable version available through Open Library. As you render
a page in your own bookish website, you can paint links into Open Library
based on the response."
I wonder if there is some use case for this in Wikipedia or other projects?
Perhaps linking references or book articles to Open Library copies? Letting
Wikimedians know when they can borrow reference works for free online? I
figure that identifiers like ISBNs are all over the place in Wikimedia
content.
Not sure, but it's interesting to think about. Their open source online book
reader is also pretty awesome and isn't Flash based.
Steven
1. http://blog.openlibrary.org/2011/06/03/announcing-a-new-read-api/
2. http://openlibrary.org/dev/docs/api/read
