Last modified: 2013-01-14 17:04:25 UTC
In edit summaries, pairs of square brackets should only create wikilinks if they are literal characters. Instead, escaped square brackets (HTML entities) are wrongly being treated as wikilink delimiters when edit summaries are displayed. Note: In the examples below, to prevent bugzilla from attempting to parse literals, I have used {curly brackets} to indicate character names. At present, the edit summary parser converts: - the HTML entities "&" U+0026 {AMPERSAND} followed by "#91;" or "#x5B;" or "#5b;" to "[" U+005B {LEFT SQUARE BRACKET} - the HTML entities "&" U+0026 {AMPERSAND} followed by "#93;" or "#x5D;" or "#5d;" to "]" U+005D {RIGHT SQUARE BRACKET} This differs from the parsing in article text and makes it impossible to submit pairs of square brackets that render literally in a displayed edit summary. (Any nowiki tags are intentionally rendered literally in edit summaries - i.e. have no special effect. So there is no way to force paired square brackets to display.) For example "[[test]]": - "{AMPERSAND}#91;{AMPERSAND}#91;test{AMPERSAND}#93;{AMPERSAND}#93;" should render as "{LEFT SQUARE BRACKET}{LEFT SQUARE BRACKET}test{RIGHT SQUARE BRACKET}{RIGHT SQUARE BRACKET}" - but instead the edit summary is parsed as a wikilink with the HTML '<a href="/wiki/Test" title="Test">test</a>'. Tested on enwiki 1.21wmf4, but I have noticed this behaviour for several weeks. (As expected, the named character entities "lsqb", "lbrack", "rsqb" and "rbrack" are NOT parsed - the preceding ampersand is correctly escaped as "&" followed by "amp;".) lt and gt entities do not seem to be affected, so this probably does not have security implications. But broken character escaping is at least potentially a cause for concern.
