--- Comment #2 from Philippe Verdy <verd...@wanadoo.fr> ---
"Normal priority" ?
Aa the Translate extnesion starts being used more widely, along with TNT and
similar templates based on detetion of subpages trying to see if it is the
source (untranslated) page or the translated subpage, we get cases were the
source page to translate contains apostrophe-quotes.
And then we get the HTTP 500 server error. Apostrophe-quotes or double quotes
or ampersands are not uncommon in titles of pages, and these pages, on
multilingual sites like MetaWiki or Commons, will cause such failure.
It is also very easy to reproduce it, and within wikis that use a lot of
utility templates to display various notice banners (which may be translated in
the page's content language detected, #language will crash in those utility
IF these utility templates are widely used, a user may insert the malicious
code with #template, and could cause LOTS of pages to generate HTTP 500.
These templates will not be easily editable by users that have a preference to
disply immediately a preview on the first edit. Most users visit the template
page to view it alog with its "noinclude" documentation containing some
examples of rendering of the template. Such visits will crash before the user
can click on the "Edit" tab.
Avanced users could also try eduting it by inserting the URL with the
"?action=edit" parameter, but they will also fail if their user preferences
include the preview on the first load of the editor.
The crash may not be easy to detect where it occurs, because it will occur
before hte page is fully expanded and the dependencies are computed and saved,
the page will never be rendered or could only contain the outdated references
to the previous state before the change in some deeply hidden sub-sub-template.
May be the server could implement a crash handler for pages so that they are at
least autocategorized: we could explore the list to determine which
translcluded template or subpage containing #language with bad parameters
causes the crash.
The crash is so easy to reproduce that I fear that now it will be exploited to
generate DoS attacks against servers constantly trying to recover from HTTP 500
crashes by relaunching new instances (with empty caches in memory, each crashes
generates lots of IO on disk and on the database).
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
Wikibugs-l mailing list