Am Dienstag, 29. März 2016, 22:24:16 CEST schrieb Christian Boltz:
good news: after a month of hunting a) spammers and b)
the needed wiki extensions to prevent and delete wiki spam finally got
installed and the database updated so that those extensions can work.
Two weeks later, I have another update - hopefully the final one on this
We deleted all spam from the english wiki, and have set up filter rules
(using the AbuseFilter extension) to prevent new spam.
"All spam" means: we had to delete 6612 spam files, 513 pages in the main
namespace and and about 50 pages spread over the other namespaces.
I had the most fun with deleting about 5000 pages and files, and Micah
(one of the Admins in Provo who is also a good Mail/IRC to SSH relay ;-)
deleted the remaining 2200 spam files after cleaning up the recentchanges
table (see the "Nuke" section below).
While working on this, some funny things happened - as usual when I use
or touch some code the first time, it breaks into parts ;-) and someone
needs to fix it.
AbuseFilter was my first victim - it worked fine for blocking spam pages,
but it didn't block uploading of spam files with similar titles.
It turned out that AbuseFilter used a wrong variable name for file
uploads, making it impossible to filter for upload filenames. This was
fixed (after I poked some people on #mediawiki) in
I applied this fix to the openSUSE wiki.
This bug might also explain why the spammers prefer file uploads - lots
of wikis around the world don't have this fix yet and therefore make it
easy to upload spam files. (Dear spammers, sorry for finding this bug and
making your life harder *g,d&r*)
My second victim was the Nuke extension - after deleting some of the
spam, I noticed that it offered the same files for deletion over and over
again, even if they were already deleted. (This happened only for files,
not for "normal" pages.)
It turned out that Nuke works based on the "recentchanges" table. This
works fine for normal pages because Mediawiki deletes their "create"
event from recentchanges when you delete them. However, it doesn't do
this with "upload" events when deleting a file. (I'll re-check this
behaviour with a newer version of MediaWiki, and open a bugreport if
it's still the same.)
As a workaround, we used a manual delete query on the recentchanges
table. Not too nice, but it worked.
(Done in the english wiki, the others will follow.)
Micah deployed the Nuke and AbuseFilter extensions on the non-english
staging wikis (for example destage.o.o), and will push them to all
production wikis next week.
This means the admins of the non-english wikis will be able to use
Special:Nuke and Special:Abusefilter soon. (See my previous mail on this
topic for some links and instructions.)
My request from the lat mail still stands:
If you reply to this mail, please answer only to one
Cross-posting the announcement is enough ;-)
Wenn derjenige hinterher herumjammert, "Zwar hängt jetzt das Bild, aber
ich habe ein Loch in der Wand und ein Nagel steht hervor...", dann habe
ich große Zweifel daran ob es so gut war, dass derjenige einen Hammer
und Nagel in die Hand bekommen hat. [Igor Sverkos in postfixbuch-users]
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org