Page MenuHomePhabricator

SpamBlacklist is escaping/validating patterns incorrectly - "Compilation failed: nothing to repeat at offset 13"
Closed, DuplicatePublicPRODUCTION ERROR

Description

3 Compilation failed: nothing to repeat at offset 13 in /srv/mediawiki/php-1.28.0-wmf.22/extensions/SpamBlacklist/EmailBlacklist.php on line 61

Regexp doesn't seem as expected.

Event Timeline

Krinkle subscribed.

Still seen. Recent sample:

PHP Warning: Compilation failed: nothing to repeat at offset 13

#1 /srv/mediawiki/php-1.32.0-wmf.20/extensions/SpamBlacklist/includes/SpamBlacklistHooks.php(79): EmailBlacklist->checkUser(User)
#2 /srv/mediawiki/php-1.32.0-wmf.20/includes/Hooks.php(174): SpamBlacklistHooks::userCanSendEmail(User, boolean)
#3 /srv/mediawiki/php-1.32.0-wmf.20/includes/Hooks.php(202): Hooks::callHook(string, array, array, NULL)
#4 /srv/mediawiki/php-1.32.0-wmf.20/includes/user/User.php(4831): Hooks::run(string, array)
#5 /srv/mediawiki/php-1.32.0-wmf.20/includes/skins/Skin.php(1100): User->canSendEmail()
#6 /srv/mediawiki/php-1.32.0-wmf.20/includes/skins/SkinTemplate.php(1350): Skin->showEmailUser(User)
#7 /srv/mediawiki/php-1.32.0-wmf.20/includes/skins/SkinTemplate.php(462): SkinTemplate->buildNavUrls()
#8 /srv/mediawiki/php-1.32.0-wmf.20/includes/skins/SkinTemplate.php(225): SkinTemplate->prepareQuickTemplate()
#9 /srv/mediawiki/php-1.32.0-wmf.20/includes/OutputPage.php(2402): SkinTemplate->outputPage()
#10 /srv/mediawiki/php-1.32.0-wmf.20/includes/MediaWiki.php(875): OutputPage->output(boolean)
#11 /srv/mediawiki/php-1.32.0-wmf.20/includes/MediaWiki.php(887): Closure$MediaWiki::main()
#12 /srv/mediawiki/php-1.32.0-wmf.20/includes/MediaWiki.php(525): MediaWiki->main()
#13 /srv/mediawiki/php-1.32.0-wmf.20/index.php(42): MediaWiki->run()

The happens consistently for all page views that involve the spam blacklist on pms.wikipedia.org. This suggests a systemic problem in the way the blacklist itself is parsed and applied, induced by something in the configuration for pms.wikipedia.org.

I suspect it may be lacking the proper escaping or validation. Example url that will trigger the above error in the backend: https://pms.wikipedia.org/wiki/Special:Contributions/Krinkle.

Krinkle renamed this task from Compilation failed: nothing to repeat at offset 13 in EmailBlacklist::checkUser to SpamBlacklist is escaping/validating patterns incorrectly - "Compilation failed: nothing to repeat at offset 13".Sep 18 2018, 5:06 PM
Krinkle added a project: Editing-team.
Krinkle updated the task description. (Show Details)

Still seen on 1.32.0-wmf.23. Suppressing for another week.

Still seen regularly.

  • Request ID: XOqR5ApAAD0AAFQGBzEAAABY
  • Request URL: GET /w/index.php?title=Ciaciarade: ** &action=edit (opening the editor on a user page)
trace
#0 /srv/mediawiki/php-1.34.0-wmf.6/extensions/SpamBlacklist/includes/EmailBlacklist.php(60): MWExceptionHandler::handleError(integer, string, string, integer, array, array)
#1 /srv/mediawiki/php-1.34.0-wmf.6/extensions/SpamBlacklist/includes/SpamBlacklistHooks.php(79): EmailBlacklist->checkUser(User)
#2 /srv/mediawiki/php-1.34.0-wmf.6/includes/Hooks.php(174): SpamBlacklistHooks::userCanSendEmail(User, boolean)
#3 /srv/mediawiki/php-1.34.0-wmf.6/includes/Hooks.php(202): Hooks::callHook(string, array, array, NULL)
#4 /srv/mediawiki/php-1.34.0-wmf.6/includes/user/User.php(4758): Hooks::run(string, array)
#5 /srv/mediawiki/php-1.34.0-wmf.6/includes/skins/Skin.php(1107): User->canSendEmail()
#6 /srv/mediawiki/php-1.34.0-wmf.6/includes/skins/SkinTemplate.php(1366): Skin->showEmailUser(User)
#7 /srv/mediawiki/php-1.34.0-wmf.6/includes/skins/SkinTemplate.php(470): SkinTemplate->buildNavUrls()
#8 /srv/mediawiki/php-1.34.0-wmf.6/includes/skins/SkinTemplate.php(228): SkinTemplate->prepareQuickTemplate()
#9 /srv/mediawiki/php-1.34.0-wmf.6/includes/OutputPage.php(2749): SkinTemplate->outputPage()
#10 /srv/mediawiki/php-1.34.0-wmf.6/includes/MediaWiki.php(872): OutputPage->output(boolean)
#11 /srv/mediawiki/php-1.34.0-wmf.6/includes/MediaWiki.php(884): Closure$MediaWiki::main()
#12 /srv/mediawiki/php-1.34.0-wmf.6/includes/MediaWiki.php(515): MediaWiki->main()
#13 /srv/mediawiki/php-1.34.0-wmf.6/index.php(42): MediaWiki->run()

@matmarex @Esanders (recent committers from stewarding team): If this is broken and not important, should the sub-feature be (temporarily) disabled so as to avoid false alarms during deployments that hint at a regression?

If it is working as intended, could the warning be caught/suppressed as stop-gap solution?

We only touched the VE integration of this extension. We have no particular expertise it how it works.

As far as I can tell, the error message correctly indicates that the blacklist defined in a MediaWiki message contains invalid regexes.

For example, https://pms.wikipedia.org/w/index.php?title=MediaWiki:Email-blacklist&action=edit contains a line beginning with a *, thus the error "nothing to repeat".

In this case it's a mistake in the translation rather than a real blacklist. I corrected the message on Translatewiki: https://translatewiki.net/w/i.php?title=MediaWiki:Email-blacklist/pms&diff=8817909&oldid=8759672. I don't have time to look for other broken translations, but if someone wishes to silence the errors, hopefully this is a good example to follow.

If the intention is to support arbitrary user input as regexes, and to allow saving this input without validation, then the extension must explicitly catch these warnings and explicitly behave how it wants to (in this case, by ignoring the entry).

Currently the code is written as if the input is always valid, thus the error indicates that the application is running an invalid regexp, suggesting a faulty deploy or unstable software. If the maintainers of the extension are interested in finding out about invalid regexes provided by users, this could be done with a user-interface facing editors. Or by logging to a dedicated low-severity channel that doesn't feed into fatalmonitor, canary checker, and other operational monitoring.

(I'm aware nobody is currently considering themselves "maintainer" of this extension. I've pinged JR about considering a stewardship process to resolve that situation.)

mmodell changed the subtype of this task from "Task" to "Production Error".Aug 28 2019, 11:11 PM