[00:48:25] tgr: Hmm. https://grafana.wikimedia.org/dashboard/db/authentication-metrics?panelId=9&fullscreen looks worrying at first, but https://en.wikipedia.org/wiki/Special:Log/newusers tells me it's just the graph is broken somehow. [00:53:10] an hour and a half later... https://i.imgur.com/Owg9GVS.png :D [00:57:33] anomie: ouch [00:57:51] could I have simply forgotten to add that? I don't see any logging code [00:59:57] anomie: btw, https://logstash.wikimedia.org/#dashboard/temp/AVU30htfivsygkP39w-o might be AuthManager-related (or not; sure would be nice to have stack traces) [01:01:34] Seems unlikely, that function is a hook for APIEditBeforeSave and EditFilterMergedContent hooks. [01:06:00] anomie: oh, I'm using authmanager-stats as the channel name for the login/signup events and authmanager for the rest [01:10:15] half changed log channels :) [01:11:10] the other half of the change would be https://gerrit.wikimedia.org/r/#/c/289775/1/includes/AuthManagerStatsdHandler.php but there it's called authmanager-stats [01:11:46] um, authevents [01:54:59] the account creation stats don't seem to be recovering :( [01:55:43] and for account creation the api stats seem broken as well [01:56:00] it's too late for me to try to figure that one out, though [01:56:41] the missing index warnings did disappear, at least [01:57:50] are people actually unable to sign up? [01:58:00] or is it just that we think the instrumentation is broken somehow? [02:05:14] ori: I made an account no problem -- https://en.wikipedia.org/wiki/User:Bd808-test-post-authmanager [03:43:08] I wonder why the metrics are off, then [03:52:34] TimStarling: any reason why 'revisionsize' triggers setFlag( 'vary-revision' )? [03:54:06] there's a revisionsize? [03:54:30] * TimStarling updates [04:05:15] ori: I always hated those, I suspect it's a huge reason for the 35% uncacheable stashes [04:08:33] maybe revisions expand and contract with changes to humidity and temperature, like wood [04:08:44] stashing REVISIONDAY/REVISIONMONTH could be smarter about the using ttl for those and check alignment...though it would need to know which magic was used (e.g. id/timestamp won't work) [04:09:47] ori: any idea how often 'revisionid' is used? It doesn't seem vary useful to the end-user, though I imagine bizzare uses are spread out everywhere [04:10:00] * AaronSchulz keeps hearing the "fractal of a bad design" phrase in his head [04:11:12] AaronSchulz: I prefer "MediaWiki is all edge cases" [04:12:32] speaking of fractals and edges, https://en.wikipedia.org/wiki/Coastline_paradox [04:20:35] AaronSchulz: this often: https://dpaste.de/NfHh/raw [04:21:02] that's NS 0 across WMF [04:21:45] most of them are about the feature [04:27:14] ori: https://gerrit.wikimedia.org/r/#/c/293677/1 btw [04:27:53] what do you want to do about REVISIONID, though? instead of removing it outright, you could convert it into some fixed number or the previous revision's ID [04:29:17] too bad it wasn't just armored and done in post-processing [04:29:35] this would limit what template could do (e.g. using a template based on the ID value), but it could still be displayed [04:31:24] too bad it was done at all! [04:36:40] oh ok, there's a revisionsize variable but no CoreParserFunction [04:37:50] } elseif ( $this->ot['wiki'] || $this->mOptions->getIsPreview() ) { [04:38:03] yeah, it's trying hard [04:38:21] if it does actually manage to not change after the page is saved, then it doesn't need vary-revision [04:38:25] TimStarling: why does the output type matter? It seems to use null for the prepareContentForEdit() parse [04:39:29] because {{subst:revisionsize}} is meant to do something in particular, I guess [04:39:58] yeah I'm thinking about subst...which I'm not even sure how that works [04:40:13] maybe it picks a number such that when shown, the final size is correct ;) [04:41:20] * AaronSchulz stares down the fractals [04:41:49] you could just have it return mInputSize unconditionally, then it wouldn't need vary-revision [04:42:06] and it would always be efficient, and editors would be able to understand what it is meant to do [04:42:09] I'm trying to think if that would break anything, but doing that makes stashing work with vary off [04:42:17] which is nice [04:42:55] I can imagine changing {{REVISIONID}} would break things, but {{REVISIONSIZE}}? [04:43:09] it's not like we run the parser on the Content-Length header [04:43:40] Content-Length: {{REVISIONSIZE}} [04:44:09] Last-Modified: {{#time:r}} [04:44:34] * AaronSchulz waits for ori to find the user JS proving Tim wrong ;) [04:55:09] https://en.wikipedia.org/w/index.php?title=Special:Search&limit=20&offset=20&ns10=1&search=%7B%7BREVISIONUSER%7D%7D&searchToken=53bqeqruqosxvrqpv2peqnjtz [04:55:10] hehe [05:54:03] why don't we make the advanced search interface the default interface for Special:Search? [05:55:27] if you click on the magnifying glass, you get redirected to https://en.wikipedia.org/w/index.php?search=&title=Special%3ASearch&go=Go [05:55:52] that's not very useful, it's just a bigger input box and a bigger magnifying glass [06:12:33] easy change, https://gerrit.wikimedia.org/r/293682 [11:17:39] ori: metrics should be fixed [11:18:07] anomie: API account creations are still at zero [11:18:19] I guess that just means no one is using the new API yet [11:18:47] and trying to use the old one is a parameter error, not an account creation error, and that's not recorded anywhere [11:19:23] it would be worth tracking, though, in case some client gets in a loop like it happened in the past [13:12:08] tgr: It looks like we're actually getting a fair number of hits to the new action=createaccount. Mobile apps would be my guess. But there's no logging to your 'authmanager' channel in ApiAMCreateAccount, or ApiClientLogin. [13:12:50] I'll add that later [16:26:07] tgr: bd808 i moved the meeting to about 4 hours from now. did it come through? that time work for you? [16:26:22] dr0ptp4kt: yup [16:33:55] dr0ptp4kt: bd808: half an hour earlier would be even better if it's all the same for you two, but this time works too [16:34:23] tgr: i'll see if i can get other meetings moved cc bd808 [16:34:34] I'm open all afternoon so whatever works for the tow of you is fine [16:34:37] tgr: ...so that i can move it that 30 minutes earlier [16:34:38] *two [16:34:47] dr0ptp4kt: do'nt worry about it if it's complicated [18:05:55] okay, end of days. need to disable mbstring :P [19:17:08] itshappening.gif [19:36:34] ugh https://gerrit.wikimedia.org/r/#/c/280945/ doesn't backport to 1.27 clean [19:36:38] sadface.gif [19:46:22] anomie, tgr: is $wgGrantPermissionGroups something that extensions should be setting? I'm adding $wgGrantPermissions support to extension.json right now, not sure if I also need to add the groups one [19:47:19] ostriches: pretty sure it wouldn't merge clean on master either [19:47:26] Nope :) [19:47:27] I was just getting to that [19:48:38] legoktm: in the unlikely case that an extension creates a new grant that doesn't fit in any of the existing groups [19:50:28] ok [19:52:38] legoktm: Yes, an extension may add entries to $wgGrandPermissionGroups. [19:59:29] oh, yeah, anomie us right, any extension that creates a new grant will need that [19:59:35] checkuser for example [20:00:13] ostriches: gotta run for a meeting, if the backport is urgent, anomie can probably help [20:01:00] it's going to have a massive amount of conflicts plus you'd need to grep for all new instances of DisableAuthManager that have been added since that patch was last updated; there are a few [20:01:50] * anomie starts working on it [20:04:40] The hope had been rc.1 this afternoon [20:12:41] anomie, tgr: thanks, https://gerrit.wikimedia.org/r/293806 [20:21:21] ostriches: https://gerrit.wikimedia.org/r/293872 [20:23:42] +2 on parent, will let jenkins do its thing then will +2 that too [20:25:05] Krinkle: Hiiii https://phabricator.wikimedia.org/T131318#2372793 :) [20:33:43] legoktm: https://gerrit.wikimedia.org/r/#/c/293874/ :) [20:36:23] ostriches: doesn't seem to fix it for me...? [20:36:56] https://paste.fedoraproject.org/377321/55910101/raw/ [20:37:08] It finds "Different parameter count: TitleIsCssOrJsPage: Doc: 2 vs. Code: 3" for me [20:37:11] which it didn't before [20:37:39] Hooks::run( 'TitleIsCssOrJsPage', [ $this, &$isCssOrJsPage ], '1.25' ); [20:38:09] Hmm, so it did something [20:38:10] maybe it's interpreting the 1.25 as a parameter? regex is really not one of my strong points :/ [20:38:10] Lol [20:38:21] We should use tokenizer [20:39:25] sounds good to me :D [20:40:49] https://gerrit.wikimedia.org/r/#/c/293751/ was trivial, found it earlier [20:41:30] ostriches: need to remove the if ( $sort ) ... :P [20:42:34] one sec [21:16:25] legoktm: We should also fix this thing so it can tell when a hook's been properly deprecated/removed. [21:16:44] "Documented and not found" is fairly useless when it's supposed to be gone :p [21:38:42] dapatrick: have you seen https://www.helpnetsecurity.com/2016/06/10/mozilla-will-fund-code-audits/ ? [21:39:02] ori: Anyone can edit wikipedia. Can have money? [21:39:23] legoktm: Ugh, playing with tokens is a rabbit hole :p [21:39:38] tl;dr: Mozilla will pay for a professional security firm to audit the codebase and will help implementing fixes [21:39:42] "Projects that want Mozilla’s help must be open source/free software and must be actively maintained, but they have a much better probability to being chosen if the software is commonly used and is vital to the continued functioning of the Internet or the Web." [21:39:52] I think MediaWiki qualifies [21:51:54] ostriches: if the hook was removed, the docs should be too :P [21:53:09] Probably :p [21:53:53] ori: Must be worth a punt [21:54:01] yeah [21:56:39] Phile a security team ish task? [21:57:12] Actually, I will [21:57:56] <3 [21:58:14] I could just fill out the google doc too [21:58:25] One step at a time, give something to point people at [22:00:39] * ori points people at Reedy [22:01:39] Project website: * [22:01:39] This needs to be somewhere we can obtain the source code. [22:01:42] * Reedy squints [22:04:19] "Has the project had a security source code audit before? If so, when and how extensively? *" [22:04:30] I think we have, ish? [22:07:39] there was one last year? [22:08:37] I found https://www.mediawiki.org/wiki/Security_auditing_and_response [22:09:06] https://phabricator.wikimedia.org/tag/security-reviews/ [22:09:32] I suspect it's not a big issue [22:10:22] Reedy: https://www.mediawiki.org/wiki/Wikimedia_Security_Team/Check/iSEC_Assessment_2014 [22:10:26] <3 [22:12:05] Submitted [22:17:17] Hmm https://phabricator.wikimedia.org/project/view/1261/ [22:17:44] 1 maybe fixed, 1 backported (but open until release), 1 installer bug, 1 maint script bug, 1 tracking issue. [22:18:06] MaxSem: You almost got a patch for mbstring fun? [22:18:30] ostriches, in progress [22:19:32] Thx! [22:29:42] ori, Reedy: I did see it, yes. [22:30:22] ostriches: I'll check it out on Sunday or first thing Monday. [22:30:48] Ok thx [22:31:21] Ok, if we get a patch in for the installer I think that can make an rc.1 [22:31:25] Reedy, you submitted MediaWiki for this MOSS program? [22:31:34] Yup :) [22:32:31] Do you have a copy of your form submission? [22:33:06] I can get one [22:33:07] And I can edit it [22:34:39] Reedy, Did you happen to run it by Legal (who's supported prior audit activity) or anyone else on any other teams? [22:35:06] Nope [22:35:19] Well, the perf team (ala ori) agreed on the idea [22:35:31] Not sure it matters too much about legal, unless they're targetting Wikipedia et al [22:35:42] MW code is free for anyone to access [22:37:18] Can't stop them doing it on their own installs [22:39:13] Reedy Right. I'm aware. [22:53:52] err, I supported filing a task with the security team [22:54:01] not submitting it without their review [23:18:10] I don't see a need in an rc.1 today :\ [23:18:19] It's already going on 5pm on the west coast. [23:18:24] Who's gonna really use it over the weekend? [23:19:07] NURDS! [23:26:55] peace out nurds, i'm gonna start my weekend. [23:28:05] ostriches: I would have :P [23:28:09] enjoy your weekend though :) [23:28:35] There's branches 😁 [23:28:42] I could tag it I suppose [23:28:47] Compromise? [23:29:23] nah, the debian thing is set up to auto-download tarballs from releases.wm.o. don't worry about it, monday is fine :) it would just have shut up a bunch of warnings [23:30:27] https://phabricator.wikimedia.org/T137564 would also make life easier [23:31:24] I could look into that over the weekend [23:31:45] but I wonder how much that will screw with people's installs that are already using git and have repos checked out into those paths [23:31:53] Ouch, possibly [23:31:55] This is true [23:32:29] Anyway, weekend [23:32:32] adios [23:32:45] o/