- Passed security review or already Wikimedia deployed
- Voting CI structure tests
- Runs MediaWiki-CodeSniffer
- Runs phan
- Supports MySQL, SQLite, and Postgres (if there are schema changes)
- GPL v2 or later compatible license
- Extension's default configuration provides optimal experience
- Tested with web installer
Description
Details
Event Timeline
Just that the majority of wiki sysadmins will not need to change any of the defaults after installing.
Also, same question for "Tested with web installer".
Run through the web installer, installing MediaWiki+AbuseFilter, and then do a basic test that everything works as expected.
Looking at WMF config, these are my thoughts about default configuration:
- Regarding available actions (AbuseFilterActions), I think we should remove blockautopromote (unused), while 'block' can probably be left in place.
- We need to decide whether AF major rights (modify, viewprivate, log-detail ...) should be assigned to sysops or to a dedicated group. I think for WMF wiki the preferred option is to give all these rights to sysops only.
- We need to decide who to assign basic rights (abusefilter-view, abusefilter-log). I think the most used configs are to give them either to everyone ('*') or autoconfirmed.
- Profiling should be enabled by default, as soon as https://gerrit.wikimedia.org/r/#/c/201104/ is merged
- Maybe a default should be specified for AbuseFilterNotifications (rc?), while AbuseFilterNotificationsPrivate should probably be left false
Discussing the points above should be enough to make the default configuration optimal.
Works with web installer. The DB part is dependent on several tasks, so it won't probably be completed too soon. As for the user rights, I'm adding to my comment above the fact that "abusefilter-modify-restricted" has to be assigned by default: the default config has "dangerous" actions enabled and categorized as restricted, but the right is unassigned, so no-one can edit filters with such actions. Giving it to sysop would be the natural solution.
Change 468696 had a related patch set uploaded (by Daimona Eaytoy; owner: Daimona Eaytoy):
[mediawiki/extensions/AbuseFilter@master] Rearrange config to provide better experience
Change 468696 had a related patch set uploaded (by Daimona Eaytoy; owner: Daimona Eaytoy):
[mediawiki/extensions/AbuseFilter@master] Rearrange config to provide better experience
Change 530349 had a related patch set uploaded (by Daimona Eaytoy; owner: Daimona Eaytoy):
[mediawiki/extensions/AbuseFilter@wmf/1.34.0-wmf.17] Rearrange config to provide better experience
Change 530349 merged by jenkins-bot:
[mediawiki/extensions/AbuseFilter@wmf/1.34.0-wmf.17] Rearrange config to provide better experience
Mentioned in SAL (#wikimedia-operations) [2019-08-15T12:14:47Z] <urbanecm@deploy1001> Synchronized wmf-config/: SWAT: 7e95f6d: Update AbuseFilter config to keep the status quo (T191740, T200032, T226987) (duration: 00m 49s)
Mentioned in SAL (#wikimedia-operations) [2019-08-15T12:16:18Z] <urbanecm@deploy1001> Synchronized php-1.34.0-wmf.17/extensions/AbuseFilter/extension.json: SWAT: rEABFe9422c5c92cb: Rearrange config to provide better experience (T191740, T200032, T226987) (duration: 00m 47s)
Change 468696 merged by jenkins-bot:
[mediawiki/extensions/AbuseFilter@master] Rearrange config to provide better experience
@Daimona, what is the status of the DB work? Will this be ready for 1.34? The release branch is being cut on September 30.
@CCicalese_WMF It depends... Right now we only have two known incompatibilities with Postgres.
For the first one (T193068), there's https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/AbuseFilter/+/503562/. That patch (and its two depends-on) are something that maybe CPT could review?
As for the second (T42757): I had tried to fix it by using string casts. While the incompatibility was fixed, casting a primary key slowed down the affected queries a lot (T221357), hence we had to revert. There's a proper fix at https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/AbuseFilter/+/459818/ (which would also pay some tech debt), but it requires a schema change, so I don't think that's doable before the branch cut. We could try to get it done before the 1.35. It would need some review as well.
Not addressed to me, but I suggest holding of until 1.35. There are a few security tickets that I have permission to view that are still open (and probably some that I cannot see) including T224203 and T223654, as well as (the less urgent) T230320 (which will be more relevant if bundled)
Thank you, @Daimona and @DannyS712! I will bump to 1.35 and have requested CPT review for the patches related to T193068.
@CCicalese_WMF Thanks! I'd also appreciate a lot some review for T220791, which is a bit more delicate...
As for the security issues: yes, of course there are others, with varying severities. I don't know how strict the requirements should be for bundling an extension in the tarball, but of the three above I'd say that T230320 is not so urgent. T152394 is IMHO more important (and a bit harder to fix).
I'd also like to fix T213006 first, so that people will start with a sane version. That one is blocked on T34478 and T213478, for which I'd also like some input from CPT. Resolving that task would mean paying a lot of tech debt, a decent cleanup, and the disappearing of several issues like T187731 (security).
As a side note, waiting for 1.35 would also give us time to make some progresses in T156095, which is good.
Those task contain personal info leaks, so I'm unsure about the policy to add people to them (specifically regarding NDA). For me it's fine to add you, but I don't want to make anything wrong. I can definitely say that T187731 is not too bad, and it's not exploitable by normal users.
[Moving specific discussion here.]
Sorry, I was insufficiently clear. Support for postgres and sqlite is a requirement for bundling extensions.
That's fine, we can just move this to 1.37. :-)
Yeah 1.38 is the current target for this. Once 1.37 is cut I'll rebase r488482 and put it up for review, so that we can move this forward as soon as possible.
Change 751479 had a related patch set uploaded (by Jforrester; author: Jforrester):
[mediawiki/tools/release@master] Add AbuseFilter to the MW tarball
Change 751479 merged by jenkins-bot:
[mediawiki/tools/release@master] Add AbuseFilter to the MW tarball
Thanks!
EDIT: Forgot this spot.
That's not a normal section; I've added it into the actual release notes, which will be copy-pasted there during the release process. But no worries, we can clean things up, it's a wiki after all.
EDIT: Forgot this spot.
That's not a normal section; I've added it into the actual release notes, which will be copy-pasted there during the release process. But no worries, we can clean things up, it's a wiki after all.
Indeed. No worries. I just took the link from the bundled template and added the section to the page. Did not put much thought into it. Probably the template needs to be tweaked a bit.