Bawolff (Brian Wolff)
Security

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Monday

  • Clear sailing ahead.

User Details

User Since
Oct 25 2014, 1:53 AM (156 w, 8 h)
Availability
Available
IRC Nick
Bawolff
LDAP User
Brian Wolff
MediaWiki User
Bawolff

I work on the MediaWiki Security Team.

Recent Activity

Wed, Oct 18

Bawolff added a comment to T167786: Clarify relation between Phabricator Etiquette and Code of Conduct for technical spaces.

I feel like the intent of the code of conduct is that in the event of a conflict, it is considered superior to any local policies

Wed, Oct 18, 5:43 PM · Developer-Relations (Oct-Dec 2017)
Bawolff added a comment to T70876: Make user_email_authenticated status visible on labs.

Could we maybe just have a new separate view that contains user_id, user_name and user_is_emailable where user_is_emailable is a boolean field that checks that disablemail is not on and use email is authenticated?

Wed, Oct 18, 5:29 PM · Data-Services
Bawolff added a comment to T178505: Page creation logs missing.

Umm, which page creation log specificly do you mean? Can you give a url to where the log used to be?

Wed, Oct 18, 4:30 PM · Commons, English-Wikipedia-New-Pages-Patrol

Mon, Oct 16

Bawolff added a comment to T176456: ORES on Watchlist causes big slowdown—especially with 'Last revision' filter turned on.

Checked in betalabs (big watchlist (>700 pages) and very few updates happening) and production (few pages on the Watchlist and big volume of updates) - the new query works fast in both cases.

Mon, Oct 16, 11:05 PM · User-notice-collaboration, Patch-For-Review, Collaboration-Feature-Rollouts (Collaboration-WL-Graduated-Everywhere), Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), Performance, Edit-Review-Improvements
Bawolff added a comment to T178135: ores_classification table corrupt on enwiki labs replica labsdb1001.

But yes, the best answer is to start using the new servers :-)

Mon, Oct 16, 6:24 AM · DBA, Data-Services

Sat, Oct 14

MichaelSchoenitzer_WMDE awarded T173041: Newsletter extension should have an rss feed for newsletters a Love token.
Sat, Oct 14, 1:11 PM · MediaWiki-extensions-Newsletter
Bawolff added a comment to T178052: pagetranslation log_type missing on replicas.

Ok, so suppress, spamblacklist and titleblacklist must not be in the view.

Sat, Oct 14, 3:46 AM · Patch-For-Review, Security-Team, DBA, Data-Services

Fri, Oct 13

IKhitron awarded T173041: Newsletter extension should have an rss feed for newsletters a Like token.
Fri, Oct 13, 6:56 PM · MediaWiki-extensions-Newsletter
Bawolff added a comment to T134976: SpecialRecentChangesLinked::doMainQuery blocking database infrastructure.

Btw, it seems the root cause was two things:

  • straight_join preventing efficient queries in case the associated page has a few links (e.g. not the giant category use case)
  • the query killer not recognizing union queries.
Fri, Oct 13, 6:49 PM · MediaWiki-Platform-Team (MWPT-Q2-Oct-Dec-2017), Scoring-platform-team, MediaWiki-Special-pages, Wikimedia-log-errors
Bawolff awarded T174603: Make footer use new WMF logo a Heartbreak token.
Fri, Oct 13, 5:58 PM · Patch-For-Review, Wikimedia-Site-requests
D3r1ck01 awarded T173041: Newsletter extension should have an rss feed for newsletters a Mountain of Wealth token.
Fri, Oct 13, 5:49 PM · MediaWiki-extensions-Newsletter
Bawolff added a comment to T173041: Newsletter extension should have an rss feed for newsletters.

MediaWiki already has a lot of internal support for RSS (For history pages, watchlist, recentchanges), So i doubt it would be super onerous.

Fri, Oct 13, 5:40 PM · MediaWiki-extensions-Newsletter
Bawolff renamed T168096: Special:RecentChanges with complex query (rc_namespace = 1 AND ct_tag = 'visualeditor') slow due to using wrong index from Read timeout on Special:RecentChanges with complex query to Special:RecentChanges with complex query (rc_namespace = 1 AND ct_tag = 'visualeditor') slow due to using wrong index.
Fri, Oct 13, 5:24 PM · Scoring-platform-team, MediaWiki-extensions-FlaggedRevs, MediaWiki-extensions-ORES, Collaboration-Team-Triage, Edit-Review-Improvements-RC-Page, MediaWiki-Recent-changes
Bawolff merged T177026: [1.31.0-wmf.1] RC page - Fatal exception of type "Wikimedia\Rdbms\DBQueryTimeoutError" for a saved filter into T164796: Very long search times on RC Page for "Very likely good faith" + "Likely have problems" (on en.wiki only?).
Fri, Oct 13, 5:21 PM · MW-1.31-release-notes (WMF-deploy-2017-10-10 (1.31.0-wmf.3)), Patch-For-Review, Scoring-platform-team, Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), Edit-Review-Improvements-RC-Page, MediaWiki-extensions-ORES
Bawolff merged task T177026: [1.31.0-wmf.1] RC page - Fatal exception of type "Wikimedia\Rdbms\DBQueryTimeoutError" for a saved filter into T164796: Very long search times on RC Page for "Very likely good faith" + "Likely have problems" (on en.wiki only?).
Fri, Oct 13, 5:21 PM · Wikimedia-log-errors, Edit-Review-Improvements-RC-Page, Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017)
Bawolff added a comment to T177026: [1.31.0-wmf.1] RC page - Fatal exception of type "Wikimedia\Rdbms\DBQueryTimeoutError" for a saved filter.
2017-09-28T20:55:51
A database query timeout has occurred.
Error: 2062 Read timeout is reached (10.64.32.25)
#0 /srv/mediawiki/php-1.31.0-wmf.1/includes/libs/rdbms/database/Database.php(979): Wikimedia\Rdbms\Database->reportQueryError(string, integer, string, string, boolean)
#1 /srv/mediawiki/php-1.31.0-wmf.1/includes/libs/rdbms/database/Database.php(1361): Wikimedia\Rdbms\Database->query(string, string)
#2 /srv/mediawiki/php-1.31.0-wmf.1/includes/specials/SpecialRecentchanges.php(358): Wikimedia\Rdbms\Database->select(array, array, array, string, array, array)
#3 /srv/mediawiki/php-1.31.0-wmf.1/includes/specialpage/ChangesListSpecialPage.php(746): SpecialRecentChanges->doMainQuery(array, array, array, array, array, FormOptions)
#4 /srv/mediawiki/php-1.31.0-wmf.1/includes/specialpage/ChangesListSpecialPage.php(543): ChangesListSpecialPage->getRows()
#5 /srv/mediawiki/php-1.31.0-wmf.1/includes/specials/SpecialRecentchanges.php(166): ChangesListSpecialPage->execute(NULL)
#6 /srv/mediawiki/php-1.31.0-wmf.1/includes/specialpage/SpecialPage.php(522): SpecialRecentChanges->execute(NULL)
#7 /srv/mediawiki/php-1.31.0-wmf.1/includes/specialpage/SpecialPageFactory.php(578): SpecialPage->run(NULL)
#8 /srv/mediawiki/php-1.31.0-wmf.1/includes/MediaWiki.php(287): SpecialPageFactory::executePath(Title, RequestContext)
#9 /srv/mediawiki/php-1.31.0-wmf.1/includes/MediaWiki.php(851): MediaWiki->performRequest()
#10 /srv/mediawiki/php-1.31.0-wmf.1/includes/MediaWiki.php(523): MediaWiki->main()
#11 /srv/mediawiki/php-1.31.0-wmf.1/index.php(43): MediaWiki->run()
#12 /srv/mediawiki/w/index.php(3): include(string)
#13 {main}
Fri, Oct 13, 5:20 PM · Wikimedia-log-errors, Edit-Review-Improvements-RC-Page, Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017)
Bawolff added a comment to T178185: ForeignDBRepo doesn't support ssl configuration properties from $wgDBservers.

I think the idea is that people with complex needs should be encouraged to use ForeignDBRepoViaLB instead.

Fri, Oct 13, 5:14 PM · Multimedia, Commons, MediaWiki-File-management
Bawolff added a comment to T168096: Special:RecentChanges with complex query (rc_namespace = 1 AND ct_tag = 'visualeditor') slow due to using wrong index.

This probably should be using the tmp_3 index (which is on production but not in mediawiki - its on (rc_timestamp, rc_namespace)) But according to the explain on production its using the rc_timestamp index. [my quick test showed 3.48 seconds when FORCE INDEX for tmp_3 vs 42.65 for query as is. Running the faster query first, so any effects of warm cache would favour the slow one]

Fri, Oct 13, 5:09 PM · Scoring-platform-team, MediaWiki-extensions-FlaggedRevs, MediaWiki-extensions-ORES, Collaboration-Team-Triage, Edit-Review-Improvements-RC-Page, MediaWiki-Recent-changes
Bawolff renamed T178109: Wikimedia\Rdbms\DBQueryTimeoutError on Special:Contributions filtering by namespace from Wikimedia\Rdbms\DBQueryTimeoutError (not repeated) to Wikimedia\Rdbms\DBQueryTimeoutError on Special:Contributions filtering by namespace.
Fri, Oct 13, 4:39 PM · MediaWiki-Special-pages, Wikimedia-log-errors
Bawolff added a comment to T178109: Wikimedia\Rdbms\DBQueryTimeoutError on Special:Contributions filtering by namespace.

Its impossible to optimize this query further unless we denormalize namespace into the revision table (which is unlikely to happen).

Fri, Oct 13, 4:38 PM · MediaWiki-Special-pages, Wikimedia-log-errors
Bawolff updated the task description for T178109: Wikimedia\Rdbms\DBQueryTimeoutError on Special:Contributions filtering by namespace.
Fri, Oct 13, 4:33 PM · MediaWiki-Special-pages, Wikimedia-log-errors
Bawolff updated the task description for T178109: Wikimedia\Rdbms\DBQueryTimeoutError on Special:Contributions filtering by namespace.
Fri, Oct 13, 4:31 PM · MediaWiki-Special-pages, Wikimedia-log-errors
Bawolff added a comment to T173770: Code Review Hours advertised but not taking place?.

It would be even better if we could also have a list of open changesets of newcomers submitted during this quarter. Real-time might be too much, but perhaps renewed each month? With the same goal: identify which projects and reviewers could help, and keep newcomers engaged and learning.

Fri, Oct 13, 4:12 PM · Developer-Relations
Bawolff added a comment to T178094: High replication lag causing read only mode on commons.

One could fill a book with the areas of wikimedia that nobody or everybody jointly (which is the same as nobody) is responsible for...

Fri, Oct 13, 3:17 PM · Release-Engineering-Team, Performance, monitoring, MediaWiki-Debug-Logger, Commons
Bawolff added a comment to T173770: Code Review Hours advertised but not taking place?.

Whats the point of keeping newcomers engaged if they become totally ignored the minute they hit some sort of no-longer-a-newcomer class?

Fri, Oct 13, 3:03 PM · Developer-Relations
Bawolff added projects to T178094: High replication lag causing read only mode on commons: Performance, Release-Engineering-Team.

assuming that person was on IRC at the time :-)

Fri, Oct 13, 2:53 PM · Release-Engineering-Team, Performance, monitoring, MediaWiki-Debug-Logger, Commons
Bawolff added a comment to T178094: High replication lag causing read only mode on commons.

There has also been discussions on Operations on whether we should alert if mediawiki goes into read only, but this can cause many many false positives that it might be paging every hours :-)

Fri, Oct 13, 5:53 AM · Release-Engineering-Team, Performance, monitoring, MediaWiki-Debug-Logger, Commons
Bawolff added a comment to T178136: Make type hints for function parameters and return compulsory after moving MediaWiki to PHP 7.

In theory most of the time, phan will already enforce type hints from the comment block, so I'm not sure it would change much in practise in terms of code reliability (Unless we also got better at declaring more specific types).

Fri, Oct 13, 4:44 AM · NewPHP, HHVM, MediaWiki-General-or-Unknown
Bawolff added a comment to T176456: ORES on Watchlist causes big slowdown—especially with 'Last revision' filter turned on.

Usually these filters are pretty selective, but it's possible for them to not be. Thankfully, the kinds of rows that bloat the RC table (Wikidata and categorization) are also among the kinds of rows that don't have ORES scores associated with them. So for wikis with bloated RC tables, the filter will be selective, and typical selections for these filters ("only show bad edits") are quite selective too (<10% on enwiki IIRC). However, the user could choose the reverse filter ("only show good edits") and that wouldn't be very selective.

Fri, Oct 13, 4:08 AM · User-notice-collaboration, Patch-For-Review, Collaboration-Feature-Rollouts (Collaboration-WL-Graduated-Everywhere), Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), Performance, Edit-Review-Improvements
Bawolff created T178135: ores_classification table corrupt on enwiki labs replica labsdb1001.
Fri, Oct 13, 3:38 AM · DBA, Data-Services
Bawolff added a comment to T176456: ORES on Watchlist causes big slowdown—especially with 'Last revision' filter turned on.

@awight Btw, some debugging tips for next time:

Fri, Oct 13, 3:05 AM · User-notice-collaboration, Patch-For-Review, Collaboration-Feature-Rollouts (Collaboration-WL-Graduated-Everywhere), Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), Performance, Edit-Review-Improvements
Bawolff added a comment to T178094: High replication lag causing read only mode on commons.

So I guess part of the problem with the alerting is its looking at individual lag, where the real issue (MediaWiki goes into read-only mode) comes up when all the slaves are lagged more than 6 seconds - which as it stands, MediaWiki doesn't even create a log entry for this situation.

Fri, Oct 13, 2:32 AM · Release-Engineering-Team, Performance, monitoring, MediaWiki-Debug-Logger, Commons
Bawolff updated the task description for T178094: High replication lag causing read only mode on commons.
Fri, Oct 13, 2:28 AM · Release-Engineering-Team, Performance, monitoring, MediaWiki-Debug-Logger, Commons
Bawolff updated the task description for T178094: High replication lag causing read only mode on commons.
Fri, Oct 13, 2:16 AM · Release-Engineering-Team, Performance, monitoring, MediaWiki-Debug-Logger, Commons
Bawolff updated the task description for T178094: High replication lag causing read only mode on commons.
Fri, Oct 13, 2:10 AM · Release-Engineering-Team, Performance, monitoring, MediaWiki-Debug-Logger, Commons

Thu, Oct 12

Bawolff added a comment to T176456: ORES on Watchlist causes big slowdown—especially with 'Last revision' filter turned on.

It will still probably be better then the old query for people with large but not insane sized watchlists, but the savings just wont be as spectacular for big watchlists

Thu, Oct 12, 11:26 PM · User-notice-collaboration, Patch-For-Review, Collaboration-Feature-Rollouts (Collaboration-WL-Graduated-Everywhere), Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), Performance, Edit-Review-Improvements
Bawolff added a comment to T176456: ORES on Watchlist causes big slowdown—especially with 'Last revision' filter turned on.

Hey @awight, I think @Bawolff's brilliant suggestion just enabled @Catrope to totally fix this problem. Following the protocol above, even with Latest Revision on, I get a 2.19 second load time—with 30 days selected! Good job gang!

Following the protocols in T176445, I get:

==="Typical ORES filter set"
https://en.wikipedia.org/wiki/Special:Watchlist?highlight=1&limit=250&days=30&urlversion=2&hidepreviousrevisions=1&hidecategorization=1&hideWikibase=1&damaging=maybebad

2.71 secs at 7 days.

==="'Rare' ORES filter set"
https://en.wikipedia.org/wiki/Special:Watchlist?hidebots=1&hidecategorization=1&hideWikibase=1&hidelog=1&highlight=1&limit=50&days=7&urlversion=2&damaging__verylikelybad_color=c4&damaging=likelybad&goodfaith=likelygood

2.13 secs at 7 days.

@Etonkovidova, moving this to QA. @Trizek-WMF, if confirmed we should prominently announce that we've fixed the bug that caused ORES on watchlist to load very slowly. This bug predated the New Filters release, so anyone who has every dropped ORES on Watchlist in the past because of slowness should give it another try. (@Jdforrester-WMF, just pinging you because I think this will make you happy.)

Thu, Oct 12, 9:23 PM · User-notice-collaboration, Patch-For-Review, Collaboration-Feature-Rollouts (Collaboration-WL-Graduated-Everywhere), Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), Performance, Edit-Review-Improvements
Bawolff updated the task description for T178099: Show moveddeleted on 404s for all pages if the user has a session.
Thu, Oct 12, 6:45 PM · Easy, MediaWiki-Page-deletion, Performance
Bawolff added a project to T178099: Show moveddeleted on 404s for all pages if the user has a session: Easy.
Thu, Oct 12, 6:44 PM · Easy, MediaWiki-Page-deletion, Performance
Bawolff created T178099: Show moveddeleted on 404s for all pages if the user has a session.
Thu, Oct 12, 6:40 PM · Easy, MediaWiki-Page-deletion, Performance
Bawolff updated the task description for T178094: High replication lag causing read only mode on commons.
Thu, Oct 12, 6:22 PM · Release-Engineering-Team, Performance, monitoring, MediaWiki-Debug-Logger, Commons
Bawolff updated the task description for T178094: High replication lag causing read only mode on commons.
Thu, Oct 12, 6:17 PM · Release-Engineering-Team, Performance, monitoring, MediaWiki-Debug-Logger, Commons
Bawolff updated subscribers of T178094: High replication lag causing read only mode on commons.
Thu, Oct 12, 5:48 PM · Release-Engineering-Team, Performance, monitoring, MediaWiki-Debug-Logger, Commons
Bawolff awarded T178068: Remove useless/misleading "Comments" field on top of https://phabricator.wikimedia.org/maniphest/task/edit/form/1/ and other places a Pterodactyl token.
Thu, Oct 12, 5:43 PM · Release-Engineering-Team (Kanban), Regression, Phabricator
Bawolff added a comment to T177772: Purge 90% of rows from recentchanges (and posibly defragment) from commonswiki and ruwiki (the ones with source:wikidata).

Hi, There's been reports of high amounts of lag on commons causing read only mode, especially between 7:10-10:10 UTC today. (I filed T178094) Perhaps the rate of deletion of commons RC entries is too aggresive?

Thu, Oct 12, 5:31 PM · Patch-For-Review, Russian-Sites, Wikidata, DBA, MediaWiki-Watchlist
Bawolff updated the task description for T178094: High replication lag causing read only mode on commons.
Thu, Oct 12, 5:29 PM · Release-Engineering-Team, Performance, monitoring, MediaWiki-Debug-Logger, Commons
Bawolff updated the task description for T178094: High replication lag causing read only mode on commons.
Thu, Oct 12, 5:28 PM · Release-Engineering-Team, Performance, monitoring, MediaWiki-Debug-Logger, Commons
Bawolff created T178094: High replication lag causing read only mode on commons.
Thu, Oct 12, 5:28 PM · Release-Engineering-Team, Performance, monitoring, MediaWiki-Debug-Logger, Commons
Bawolff updated the task description for T177997: WikiImporter::notice echoing of unescaped values is a dangerous api.
Thu, Oct 12, 4:21 PM · Easy, Security-Core, Security, MediaWiki-Export-or-Import
Bawolff added a project to T178060: RawAction should set proper Content-Type header: Security-Team.
Thu, Oct 12, 4:08 PM · Patch-For-Review, Security-Team, User-Daniel, MediaWiki-ContentHandler
Bawolff added a comment to T176456: ORES on Watchlist causes big slowdown—especially with 'Last revision' filter turned on.

Oh, well in that case, if a particular filter is very selective it may make sense to allow query plans wherethe base table is ores_classification, with some sort of index like (oresc_model, oresc_class, oresc_probability). If we can narrow down the range of revisions (for options of the form only show last three days), putting oresc_rev at the end of that index may make sense too for index condition pushdown. This of course only makes sense if the filter is very selective as the required filesort has a high overhead.

Thu, Oct 12, 3:34 PM · User-notice-collaboration, Patch-For-Review, Collaboration-Feature-Rollouts (Collaboration-WL-Graduated-Everywhere), Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), Performance, Edit-Review-Improvements
Bawolff added a comment to T21291: Mechanism to find usages of raw-html messages.

I think it might be cool to have an extension that provides ?uselang=qqs.

Thu, Oct 12, 2:55 PM · Patch-For-Review, Parsing-Team, MediaWiki-Parser
Bawolff edited projects for T178051: Unwriteable error when creating DR in Commons:Data, added: Commons-Datasets; removed DBA.

Rv my tag change. Wrong bug.

Thu, Oct 12, 2:20 PM · Commons-Datasets
Bawolff edited projects for T178051: Unwriteable error when creating DR in Commons:Data, added: DBA; removed Commons-Datasets.

I wonder if its related to deleting all the wikibase stuff in rc(?)

Thu, Oct 12, 2:18 PM · Commons-Datasets
Bawolff added a comment to T178060: RawAction should set proper Content-Type header.

Well in general this sounds nice - there is a potential security issue here in the event that a content handler returns an unsafe mime that could execute scripts. E.g. returning text/html, application/svg+xml would be bad.Some browsers do a lot of sniffing on text/plain (not sure how much that still is the case). And there is also the potential for a format which is downloaded and executed unsafely (e.g. text/csv interpreted by excel. ) which may or not be an issue. Even if not executed could maybe cause a network request to be issued to a third party server which may be unacceptable privacy wise.

Thu, Oct 12, 1:54 PM · Patch-For-Review, Security-Team, User-Daniel, MediaWiki-ContentHandler
Bawolff added a comment to T176456: ORES on Watchlist causes big slowdown—especially with 'Last revision' filter turned on.

I dont think that index exists in production (not sure; i dont remember it one i was looking about an hour ago).

Thu, Oct 12, 12:54 AM · User-notice-collaboration, Patch-For-Review, Collaboration-Feature-Rollouts (Collaboration-WL-Graduated-Everywhere), Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), Performance, Edit-Review-Improvements

Wed, Oct 11

Bawolff added a comment to T176456: ORES on Watchlist causes big slowdown—especially with 'Last revision' filter turned on.

I'll just admit right here that I'm not particularly good at query optimization. But still, I'll go ahead and make the obvious comment. I'm not sure we're using multi-column indexes correctly. For example, this is the only index that covers the oresc_probability column,

CREATE INDEX /*i*/oresc_model_class_prob ON /*_*/ores_classification (oresc_model, oresc_class, oresc_probability);

The order of columns matters here, so in my understanding, we can only filter by probability after we've already narrowed by model and class. Similarly, we can't filter by class until model is locked in. Something like that. So I'm imagining that our multi-column key is causing the conditions to be evaluated in a difficult order.

It would be great if someone with more DB chops could take a look at this.

Wed, Oct 11, 11:20 PM · User-notice-collaboration, Patch-For-Review, Collaboration-Feature-Rollouts (Collaboration-WL-Graduated-Everywhere), Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), Performance, Edit-Review-Improvements
Bawolff added a comment to T164796: Very long search times on RC Page for "Very likely good faith" + "Likely have problems" (on en.wiki only?).

Copying my comment from T171027#3677195 over here as I commented on the wrong bug, and its good to keep things together for reference:

Wed, Oct 11, 9:18 PM · MW-1.31-release-notes (WMF-deploy-2017-10-10 (1.31.0-wmf.3)), Patch-For-Review, Scoring-platform-team, Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), Edit-Review-Improvements-RC-Page, MediaWiki-extensions-ORES
Bawolff added a comment to T164796: Very long search times on RC Page for "Very likely good faith" + "Likely have problems" (on en.wiki only?).

@jmatazzoni ah sorry, I wasn't suggesting that the query is any faster than you said. I was running on a dedicated analytics box, so the timings I gave only matter on a relative scale. The takeaway is that the query runs 30x faster when the specific unused clause I quoted is removed.

The bad news is that I didn't understand the change_tag clause when I looked at this problem yesterday. It's:

(SELECT Group_concat(ct_tag SEPARATOR ',') 
                             FROM   `change_tag` 
                             WHERE  ct_rc_id = rc_id)            AS `ts_tags`,

This isn't actually unused, it's returning tags which I assume are rendered in the results, somehow. The only quick fix that comes to mind is that we can fetch the tags in a second query, after limiting to a small number of revisions when paging the view.

Wed, Oct 11, 8:44 PM · MW-1.31-release-notes (WMF-deploy-2017-10-10 (1.31.0-wmf.3)), Patch-For-Review, Scoring-platform-team, Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), Edit-Review-Improvements-RC-Page, MediaWiki-extensions-ORES
Bawolff added a comment to T124841: Address performance needs for Wikimedia from DynamicPageList extension so that it can be deployed to further wikis.

I'd be happy to see a volunteer take this on, though I note that they'd need some support from us to get the code reviewed and a follow-up performance review undertaken to see whether it would be OK

Wed, Oct 11, 8:21 PM · Editing-team, Performance, MediaWiki-extensions-DynamicPageList
Bawolff created T177997: WikiImporter::notice echoing of unescaped values is a dangerous api.
Wed, Oct 11, 8:18 PM · Easy, Security-Core, Security, MediaWiki-Export-or-Import
Bawolff reopened T107875: Use innodb engine for searchindex table in mysql as "Open".

This is ancient history now.

Wed, Oct 11, 8:02 PM · Patch-For-Review, MediaWiki-Search
Bawolff added a comment to T171027: "Read timeout is reached" DBQueryError when trying to load specific users' watchlists (with +1000 articles) on several wikis.

Well wikidata is almost certainly a contributing factor, (particularly for russian) I would hesitate to blame it solely for slow ores on watchlist speeds, without more evidence. Especially on english wikipedia with its large recentchanges table and relatively low usage of wikidata.

Wed, Oct 11, 7:43 PM · MW-1.31-release-notes (WMF-deploy-2017-10-03 (1.31.0-wmf.2)), User-notice, MediaWiki-extensions-WikibaseRepository, Wikidata-Sprint, Patch-For-Review, Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), DBA, Wikidata, Commons, Contributors-Team, Wikimedia-log-errors, MW-1.30-release-notes (WMF-deploy-2017-08-08_(1.30.0-wmf.13)), Russian-Sites, Wikimedia-General-or-Unknown, Performance, MediaWiki-Watchlist
Bawolff added a comment to T177966: Add CORS-enabled, cacheable way to access contents of Data namespace.

Correction: the response is cached according to the maxage specified in the request; however, I’m not sure if this works if pages are edited or purged (as far as I can tell, the browser doesn’t validate its cached data), so it can be hard to choose the right maxage. (This workaround also requires that you parse and transform the canonical URI, which is ugly.)

Wed, Oct 11, 7:24 PM · MediaWiki-General-or-Unknown, Wikidata, User-Daniel
Bawolff closed T73386: the Sanitizer allows only ASCII and a some punctuation in extension tag attributes as Resolved.
Wed, Oct 11, 7:13 PM · MW-1.30-release-notes (WMF-deploy-2017-07-18_(1.30.0-wmf.10)), Patch-For-Review, I18n, MediaWiki-Parser
Bawolff closed T73386: the Sanitizer allows only ASCII and a some punctuation in extension tag attributes, a subtask of T30980: parser tags such as <ref>, <poem>, <timeline> etc. cannot be localized, as Resolved.
Wed, Oct 11, 7:13 PM · Parsoid, Cite, RTL, Patch-For-Review, I18n, MediaWiki-Internationalization
Bawolff added a comment to T177974: Drop #wikimedia-codereview channel.

My vote is redirect to #wikimedia-dev

Wed, Oct 11, 6:29 PM · Patch-For-Review, wikimedia-irc-freenode
Bawolff added a comment to T177974: Drop #wikimedia-codereview channel.

Dropping irc channels is not really an operations thing. The channel founder would be the one who'd have to drop it.

Wed, Oct 11, 6:09 PM · Patch-For-Review, wikimedia-irc-freenode
Bawolff added a comment to T171027: "Read timeout is reached" DBQueryError when trying to load specific users' watchlists (with +1000 articles) on several wikis.

In T171027#3673060, @Lydia_Pintscher wrote:

This is a hugely political issue. Let's please not do this unless necessary.

Right now, ORES is unusable on Watchlist for English, Russian and probably some other big wikis. It causes delays of 30 seconds to a minute when users have more than 3 days set. I'm told Wikidata is a likely culprit. If that's correct (I can't say it is or isn't), then by that standard, some kind of change appears to be "necessary," and, as Risker says, some kind of escalation appears both justified and required.

Wed, Oct 11, 4:30 PM · MW-1.31-release-notes (WMF-deploy-2017-10-03 (1.31.0-wmf.2)), User-notice, MediaWiki-extensions-WikibaseRepository, Wikidata-Sprint, Patch-For-Review, Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), DBA, Wikidata, Commons, Contributors-Team, Wikimedia-log-errors, MW-1.30-release-notes (WMF-deploy-2017-08-08_(1.30.0-wmf.13)), Russian-Sites, Wikimedia-General-or-Unknown, Performance, MediaWiki-Watchlist
Bawolff added a comment to T173770: Code Review Hours advertised but not taking place?.

I personally find real time code reviews useful in some circumstances:

  • if there is something really complicated or tricky happening, going over it in irc can help to make sure all the cases are covered (not really relavent to this ticket since that is rare and generally applies to experianced contribs who are easy to contact over irc)
  • for very new contributors, where we are not really reviewing the patch so much as advising people how to contribute - real time communication can be very helpful.
  • if there are problems with the patch, real time means a very small feedback loop. Issue is identified and fixed immediately instead of problem noted than fixed a week later and then relooked at 2 weeks later by which time the reviewer has totally forgotten context/doesnt care anymore. (Part of this is a cultural issue where reviewers are discouraged from "helping" get a patch to a ready state because they are then no longer qualified as a neutal reviewer)
  • [i suspect] having code review office hours means time gets specificly set aside to do code review. Well this is a poor substitute for actually setting time aside, I suspect its better than the status quo.
Wed, Oct 11, 5:52 AM · Developer-Relations

Tue, Oct 10

Bawolff added a comment to T177895: Allow logged in users to disable MediaWiki:Common.js and MediaWiki:Common.css.

From a security prespective, the main risk (that a per-user off switch could address) is that these features allow making an xss "permenant" (excluding the risk of malicious admin). An option by itself wouldnt prevent that as a malicious person could just turn it back on. Would need to make the user do something like reenter password before reenabling

Tue, Oct 10, 11:29 PM · Security-Team, MediaWiki-User-preferences
Bawolff added a comment to T177895: Allow logged in users to disable MediaWiki:Common.js and MediaWiki:Common.css.

From a security prespective, the main risk (that a per-user off switch could address) is that these features allow making an xss "permenant" (excluding the risk of malicious admin). An option by itself wouldnt prevent that as a malicious person could just turn it back on. Would need to make the user do something like reenter password before reenabling

Tue, Oct 10, 11:26 PM · Security-Team, MediaWiki-User-preferences
Bawolff added a comment to T177707: don't dispatch changes to all affected pages for highly used items.

"Open question: Where should the cut-off initially be?" - the problem I have here is that it's particularly useful to see changes to highly-used pages, as it's those same pages that need to be watched closer to make sure that vandalism is quickly reverted. E.g. if a country name is vandalised, that needs to be caught quickly. If that's not feasible, then I'm not sure I see the benefit of having a middle-region, perhaps it should only appear for the directly linked page... Or maybe it should show in RelatedChanges rather than RecentChanges.

Tue, Oct 10, 7:59 PM · MW-1.31-release-notes (WMF-deploy-2017-10-17 (1.31.0-wmf.4)), Patch-For-Review, MediaWiki-extensions-WikibaseClient, Wikidata-Sprint, Wikidata
Bawolff added a comment to T176441: [Outreachy R_15 Proposal] Show new file versions and description changes made on WikimediaCommons on the Watchlist.

Any implementation approach you wish to follow? Could you include this in the proposal? I mean how you would solve this problem.

Tue, Oct 10, 6:35 PM · Outreachy (Round-15), Crosswiki, Commons, Contributors-Team, Multimedia, GlobalUsage, MediaWiki-Watchlist

Sat, Oct 7

Bawolff added a comment to T171027: "Read timeout is reached" DBQueryError when trying to load specific users' watchlists (with +1000 articles) on several wikis.

The introduction of wikidata events on recentchanges has converted the "light" recentchanges table into a monolithical 500GB table:

commonswiki]> SHOW TABLE STATUS like 'recentchanges'\G
*************************** 1. row ***************************
           Name: recentchanges
           Rows: 617078906
 Avg_row_length: 566
    Data_length: 349283375366
   Index_length: 20766761170
 Auto_increment: 965208270

This was a) Not discussed previously with us DBAs b) created huge performance issues c) Made maintenance impossible d) break recentchanges functionality for users e) break watchlist functionality for users f) after report of breakage almost 3 months ago, no workaround/mitigation as been done g) we are close of running out of space on several main database servers, breaking all of Wikipedia h) propose to create even newer indexes, which only makes all of the above problems worse.

Given all of the above, I administratively will take the emergency decision (because "things are broken)" of finding out which functionality created this issue- revert it on code and purge all new rows created. Once that has been done, the owners of the functionality can requests it to be enabled again, after a strategy not breaking production is proposed. I am switching this to unbreak now to reflect how bad things are, and that I am taking leadership to get something finally done.

Sat, Oct 7, 5:51 PM · MW-1.31-release-notes (WMF-deploy-2017-10-03 (1.31.0-wmf.2)), User-notice, MediaWiki-extensions-WikibaseRepository, Wikidata-Sprint, Patch-For-Review, Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), DBA, Wikidata, Commons, Contributors-Team, Wikimedia-log-errors, MW-1.30-release-notes (WMF-deploy-2017-08-08_(1.30.0-wmf.13)), Russian-Sites, Wikimedia-General-or-Unknown, Performance, MediaWiki-Watchlist

Wed, Oct 4

Bawolff triaged T176995: Monitor any sql syntax error issues, and send email alerting if they happen as Normal priority.
Wed, Oct 4, 5:08 PM · Security
Bawolff added a comment to T149424: Security review the Extension:WikipediaExtracts.

I'm curious if this would be better served by $wgEnableScaryTranscluding ?

Wed, Oct 4, 4:58 PM · MediaWiki-extensions-WikipediaExtracts, Security-Reviews

Tue, Oct 3

Bawolff added a comment to T173891: Create core ip_changes view for replicas.

The table is now live and populated on all wikis, so I've repurposed this ticket for creating the replicas view. Hope that is OK. Any update on that? Anything I can do to help? People have been asking about this :)

Tue, Oct 3, 8:28 PM · cloud-services-team (Kanban), Data-Services, Security, Community-Tech, DBA
Bawolff closed T158119: Add Security.md to MediaWiki Core? as Resolved.
Tue, Oct 3, 8:22 PM · MW-1.31-release-notes (WMF-deploy-2017-10-10 (1.31.0-wmf.3)), Patch-For-Review, MediaWiki-Documentation, Documentation, Security-Team, Security

Mon, Oct 2

He7d3r awarded T125589: Allow tools to have their own ".tools.wmflabs.org" subdomain a Like token.
Mon, Oct 2, 4:36 PM · Cloud-Services, Toolforge, Security-Team

Fri, Sep 29

Bawolff added a comment to T177105: Several JS tools do not load on Wikisource.

All the eval()s in the callstack in the first error is kind of weird though. I wonder if corrupted ResourceLoaderStorage is a possibility. But that wouldn't make sense with error being intermittent.

Fri, Sep 29, 9:26 PM · JavaScript, Wikisource
Bawolff added a comment to T177105: Several JS tools do not load on Wikisource.

The problem is not ONE tool, but quite a lot of scripts do not load. And yes, it is the French Wikisource.

On the URL given above, I get

Use of "importScriptURI" is deprecated. Use mw.loader instead. load.php?debug=true&lang=fr&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin=monobook&version=0cg1aij:10861 
get @ load.php?debug=true&lang=fr&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin=monobook&version=0cg1aij:10861

Use of "mw.toolbar" is deprecated. 9load.php?debug=true&lang=fr&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin=monobook&version=0cg1aij:10861 
get @ load.php?debug=true&lang=fr&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin=monobook&version=0cg1aij:10861

Please, load LanguageConverter from [[meta:User:He7d3r/Tools/LanguageConverter.js]]. wikisource.org/w/index.php?title=User:He7d3r/Tools/LanguageConverter.js&action=raw&ctype=text/javascript:2 
(anonymous) @ wikisource.org/w/index.php?title=User:He7d3r/Tools/LanguageConverter.js&action=raw&ctype=text/javascript:2

Use of "wgNamespaceNumber" is deprecated. Use mw.config instead. load.php?debug=true&lang=fr&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin=monobook&version=0cg1aij:10861 
get @ load.php?debug=true&lang=fr&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin=monobook&version=0cg1aij:10861

Use of "mw.toolbar" is deprecated. 2load.php?debug=true&lang=fr&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin=monobook&version=0cg1aij:10861
get @ load.php?debug=true&lang=fr&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin=monobook&version=0cg1aij:10861
Fri, Sep 29, 8:56 PM · JavaScript, Wikisource
Bawolff added a comment to T177105: Several JS tools do not load on Wikisource.

Realistically, this is probably the fault of those gadgets in question, and bugs should be filed with their maintainer.

Fri, Sep 29, 6:36 PM · JavaScript, Wikisource
Bawolff added a project to T177105: Several JS tools do not load on Wikisource: JavaScript.
Fri, Sep 29, 6:31 PM · JavaScript, Wikisource

Thu, Sep 28

Bawolff added a comment to T176269: Disallow <templatestyles> tags in non-Template namespaces.

Err, what? That non sequitur sounds like pure FUD.

Hm, I think you have never tried to control the community's vandals and users who can broke everything when they start to work with design or code.

Thu, Sep 28, 7:21 PM · TemplateStyles
Bawolff created T176995: Monitor any sql syntax error issues, and send email alerting if they happen.
Thu, Sep 28, 5:33 PM · Security
Bawolff added a project to T176867: Article suppression should remove the page name from all logs as well: Anti-Harassment.

@TBolliger Is this something your team would be interested in taking on.

Thu, Sep 28, 5:03 PM · Anti-Harassment, Stewards-and-global-tools, MediaWiki-Revision-deletion, Vuln-Infoleak, Security-Core, Security
Bawolff closed T176055: Update of QueryPages failing on commons with "MASTER_POS_WAIT() or MASTER_GTID_WAIT() failed: MySQL server has gone away" as Resolved.

Assuming this works, special pages on commons should start updating again on oct 5.

Thu, Sep 28, 4:31 PM · MW-1.31-release-notes (WMF-deploy-2017-10-03 (1.31.0-wmf.2)), Patch-For-Review, DBA, Wikimedia-General-or-Unknown, Commons, MediaWiki-Special-pages

Wed, Sep 27

Krinkle awarded T125589: Allow tools to have their own ".tools.wmflabs.org" subdomain a Orange Medal token.
Wed, Sep 27, 3:57 PM · Cloud-Services, Toolforge, Security-Team
Bawolff closed T175450: Support suppression (oversight) of newsletters as Resolved.

With that in mind im going to close this bug. Having revdel kill all the logs automatically sounds like a very reasonable feature request, but its not a newsletter issue.

Wed, Sep 27, 3:06 AM · Stewards-and-global-tools, WorkType-NewFunctionality, MediaWiki-extensions-Newsletter, Security-Extensions, Security
MichaelSchoenitzer awarded T125589: Allow tools to have their own ".tools.wmflabs.org" subdomain a Love token.
Wed, Sep 27, 1:05 AM · Cloud-Services, Toolforge, Security-Team

Tue, Sep 26

Bawolff added a comment to T176769: "No edit forms" when attempting to edit task.

Also happening for me on T176055

Tue, Sep 26, 10:21 PM · RelEng-Archive-FY201718-Q1, User-Matthewrbowker, Phabricator
Bawolff added a comment to T176269: Disallow <templatestyles> tags in non-Template namespaces.

At the very least i expect people will want it on their user pages because users seem to like making overly ornate user pages. I could also imagine people using it in the portal namrspace.

Tue, Sep 26, 9:28 PM · TemplateStyles
Bawolff added a comment to T174126: Security review for the ReadingLists extension.
> This seems to have many hardcoded assumptions about lists being small (e.g. Reording requiring to submit the order of all items on a list, with the api unworkable if lists have > 1000 entries. Some queries not having LIMIT clauses. Paging using OFFSET clauses instead of range conditions in the WHERE. Some parts not even having paging at all).

I specifically said I will block any deployment to production if lists get larger than 100 items/rows as there was not allocated hardware for this functionality. I still stand by that statement, no matter if it has been ignored by the development team or not.

Tue, Sep 26, 3:29 PM · Reading-Infrastructure-Team-Backlog (Kanban), Wikipedia-Android-App-Backlog, Security-Reviews, Reading List Service
Bawolff added a comment to T155725: Security review for StopForumSpam.

I was thinking that, maybe, we could do a deploy of this extension to the Beta Cluster, where we're having a continuous spamming problem, once @Bawolff issues in the security review are addressed, so we can test it there and prepare for deployment on production wikis? According to https://www.mediawiki.org/wiki/User:Legoktm/StopForumSpam_effectiveness, more than 20% of IPs blacklisted on SFS are also blocked on Wikimedia wikis so it seems like a good resource in anti spamming activities.

Tue, Sep 26, 2:16 PM · MediaWiki-extensions-StopForumSpam, Stewards-and-global-tools, Security-Reviews
Bawolff added a comment to T174126: Security review for the ReadingLists extension.

IMO the RESTBase part doesn't require a security review: it's basically just a web proxy that converts between slightly different URL styles.

Tue, Sep 26, 12:08 AM · Reading-Infrastructure-Team-Backlog (Kanban), Wikipedia-Android-App-Backlog, Security-Reviews, Reading List Service

Mon, Sep 25

Bawolff moved T174126: Security review for the ReadingLists extension from Backlog to Done on the Security-Reviews board.

Review of a1b8a6cc70e. (Just the ReadingList extension. I haven't reviewed anything RESTBase related or client side related)

Mon, Sep 25, 8:32 PM · Reading-Infrastructure-Team-Backlog (Kanban), Wikipedia-Android-App-Backlog, Security-Reviews, Reading List Service
Bawolff added a comment to T176533: Re-enable stacktraces on Wikimedia wikis ($wgShowExceptionDetails = true);.

Which patch used for disabling (moving from true to false)?

Mon, Sep 25, 6:20 PM · Security-Reviews, Wikimedia-Site-requests

Sun, Sep 24

Bawolff added a comment to T152157: MediaWiki should log login history.

We should log history of users' logins.

Log user agent string, time, IP of successful logins on ALL wikis.

Make it view-able in account info each wiki.

Sun, Sep 24, 7:17 PM · MediaWiki-extension-requests, Security-General

Sat, Sep 23

Bawolff added a comment to T171027: "Read timeout is reached" DBQueryError when trying to load specific users' watchlists (with +1000 articles) on several wikis.

They're not fully redundant, since rc_type for Wikidata is RC_EXTERNAL (from core, thus not Wikidata-specific).

Sat, Sep 23, 1:35 AM · MW-1.31-release-notes (WMF-deploy-2017-10-03 (1.31.0-wmf.2)), User-notice, MediaWiki-extensions-WikibaseRepository, Wikidata-Sprint, Patch-For-Review, Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), DBA, Wikidata, Commons, Contributors-Team, Wikimedia-log-errors, MW-1.30-release-notes (WMF-deploy-2017-08-08_(1.30.0-wmf.13)), Russian-Sites, Wikimedia-General-or-Unknown, Performance, MediaWiki-Watchlist