Page MenuHomePhabricator

Some MediaWiki: messages not safe in HTML (tracking)
Open, NormalPublic

Description

Many MediaWiki: messages are still used as raw HTML output. Strict XML parsing by user agents would make
it very difficult for a sysop modifying them through the wiki to recover from an error which creates invalid
output -- the entire wiki interface can be broken.

Messages should be converted to either plaintext (via htmlspecialchars()) or wikitext which will go through
normalization. (This is an ongoing effort.)

Details

Reference
bz212

Related Objects

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 6:43 PM
bzimport set Reference to bz212.
bzimport added a subscriber: Unknown Object (MLST).
brion created this task.Aug 25 2004, 7:14 AM

leercontainer-bugzilla wrote:

(In reply to comment #0)

Messages should be converted to either plaintext (via htmlspecialchars()) or

wikitext which will go through

normalization. (This is an ongoing effort.)

I'd much prefer the ongoing effort. Is there some list of what messages that are
converted to wikitext, or some easy (grep?) way to find out?

avarab wrote:

Marking it as INVALID, please provide specific issues like specific tags that
cause problem or specific messages that do, submitting a bug like "some stuff in
part x of the codebase causes problems" doesn't do a whole lot for those
interested in fixing it.

brion added a comment.Apr 1 2005, 8:29 PM

Every message that is output as HTML.

Created attachment 414
Changes errorpage function to add wikitext

attachment errorpage2.diff.txt ignored as obsolete

avarab wrote:

It doesn't change nearly all the messages that use the errorpage function, which
are: rcpatroldisabledtext, markedaspatrollederrortext, nospecialpagetext,
watchnologintext, watchnologintext, nosuchactiontext, uploadnologintext,
sessionfailure, notargettext, notargettext, nospecialpagetext, mailnologintext,
notargettext, notargettext, noemailtext, noemailtext, movenologintext,
notargettext, nospecialpagetext, prefsnologintext, notargettext, notargettext,
uploadnologintext, nospecialpagetext, notargettext, notargettext.

$ for i in rcpatroldisabledtext markedaspatrollederrortext nospecialpagetext
watchnologintext watchnologintext nosuchactiontext uploadnologintext
sessionfailure notargettext notargettext nospecialpagetext mailnologintext
notargettext notargettext noemailtext noemailtext movenologintext notargettext
nospecialpagetext prefsnologintext notargettext notargettext uploadnologintext
nospecialpagetext notargettext notargettext; do grep $i patch|wc -l|perl -pe
's/\n/\t/g' && echo $i; done|sort -nr
92 uploadnologintext
92 uploadnologintext
90 prefsnologintext
88 mailnologintext
87 movenologintext
85 watchnologintext
85 watchnologintext
0 sessionfailure
0 rcpatroldisabledtext
0 notargettext
0 notargettext
0 notargettext
0 notargettext
0 notargettext
0 notargettext
0 notargettext
0 notargettext
0 notargettext
0 nosuchactiontext
0 nospecialpagetext
0 nospecialpagetext
0 nospecialpagetext
0 nospecialpagetext
0 noemailtext
0 noemailtext
0 markedaspatrollederrortext

avarab wrote:

Nevermind, the rest of those messages didn't need any modification, applied the
patch to HEAD.

WP:BEANS violation:

  1. GOTO http://en.wikipedia.org/wiki/MediaWiki:Copyright
  2. ADD <img src="/w/api.php?action=logout" />
  3. FLEE

i.e. rouge admin can make everyone forced to log out.

demon added a comment.Jun 5 2008, 2:41 PM

(In reply to comment #7)

WP:BEANS violation:

  1. GOTO http://en.wikipedia.org/wiki/MediaWiki:Copyright
  2. ADD <img src="/w/api.php?action=logout" />
  3. FLEE

i.e. rouge admin can make everyone forced to log out.

You sure about this? I could be wrong, but I just tried it on my localhost and it didn't force a logout.

I think I got most of them with my last commits r50881, r50882 and r50883. Keeping this bug open like this seems not quite useful. What I would like to is mechanism to detect this automatically, something that can be enabled during development. PHP's taint module seems a candidate, but as of now it is not easy to install.

Created bug 19291 for that. Closing this now as INVALID, because this bug cannot be easily fixed as-is.

Reopening as there seems no reason to close it; bug 19291 looks like a request for a tool to aid in working on bug 212 issues.

happy.melon.wiki wrote:

Are there *any* messages that need to allow full (X)HTML?? Pages like the site footer use raw HTMl links, for example: is that still performance-necessary?

(In reply to comment #8)

(In reply to comment #7)

WP:BEANS violation:

  1. GOTO http://en.wikipedia.org/wiki/MediaWiki:Copyright
  2. ADD <img src="/w/api.php?action=logout" />
  3. FLEE

i.e. rouge admin can make everyone forced to log out.

You sure about this? I could be wrong, but I just tried it on my localhost and
it didn't force a logout.

This still apply (just tested) Remember to modify the src="" to match your local install.

Changing subject since we don't support XHTML 1.0 anymore ;).

As an aside, people on wikinews use the raw html in [[mediawiki:Copyright]] to add rdf to the footer, to make them be picked up in google's creative commons content search.

(In reply to comment #15)

As an aside, people on wikinews use the raw html in [[mediawiki:Copyright]]
to
add rdf to the footer, to make them be picked up in google's creative commons
content search.

Raw RDF comments instead of RDFa!!!

Qgil added a comment.Apr 14 2014, 1:55 AM

Interesting report history. :)

The fact is that nobody seems to be working or planning to work on this. Setting priority to Lowest accordingly.

  • Bug 43646 has been marked as a duplicate of this bug. ***
  • Bug 43646 has been marked as a duplicate of this bug. ***

Converting to tracking bug per bug 43646 comment 6.

Nemo_bis raised the priority of this task from Lowest to Normal.Dec 9 2014, 1:29 PM

Nikerabbit committed a number of patches. https://gerrit.wikimedia.org/r/#/q/topic:esc,n,z

demon removed a subscriber: demon.Dec 9 2014, 3:34 PM
Deskana set Security to None.Dec 9 2014, 4:15 PM
Deskana removed a subscriber: Deskana.

@Nemo_bis: If an end ("task resolved") can ever be clearly defined: epic. If not: tracking. I think the latter.

TTO renamed this task from Many MediaWiki: messages not safe in HTML (tracking) to Some MediaWiki: messages not safe in HTML (tracking).Sep 8 2015, 7:02 AM
TTO updated the task description. (Show Details)
TTO added a subscriber: TTO.

Changed title from "Many" to "Some". A quick unscientific audit (prepending some inline JS to each message string in en.json) hasn't found many raw HTML messages at all. There are probably very few raw HTML messages remaining, I'll file tasks for any I come across and mark them "easy".

T85864 found hundreds just on the extensions enabled at translatewiki.net. There are probably hundreds more.

Qgil removed a subscriber: Qgil.Sep 10 2015, 7:34 AM
TTO added a comment.Sep 10 2015, 9:34 AM

T85864 found hundreds just on the extensions enabled at translatewiki.net. There are probably hundreds more.

This is a core task, my comment was referring to core only. My apologies for any confusion.

Meno25 removed a subscriber: Meno25.Feb 22 2016, 5:49 PM
Tgr added a subtask: Restricted Task.Mar 19 2018, 6:50 AM
Bawolff added a subtask: Restricted Task.Jul 5 2018, 5:04 PM
Liuxinyu970226 added a comment.EditedMar 16 2019, 1:51 PM

Dear author @brion, it's prefer to (request to) create tasks instead of opening tracking tasks which are nowadays nonsense under any circumstances.

Should we convert this old-decaded tracking task to a project? Or just archive this task?