[00:30:15] ostriches: what lists should get a MW security announcement apart from wikitech and mediawiki-announce? [00:30:44] That's the usual places [00:30:52] mediawiki-announce forwards to wikitech-l, btw. [00:31:13] ah, ok [00:31:39] by the way, what's the process for T148775? [00:31:39] T148775: Rename WikimediaPageViewInfo extension to PageViewInfo - https://phabricator.wikimedia.org/T148775 [00:31:55] should I list that in the new git repo requests? [00:33:49] Ya [00:33:55] And we can push the data to new repo [01:33:19] ostriches: looks like I can't post to -announce [03:25:08] tgr|away: Yeah, it's perma-moderated since it's an announce list. [14:12:02] addshore: Any chance of getting https://gerrit.wikimedia.org/r/#/c/315521/ reviewed soon? [15:40:39] Someone who knows composer better than I.... is this right? https://gerrit.wikimedia.org/r/#/c/317749/ [15:40:54] It's always popping up as untracked for me (and seems to get regenerated all the time) [15:43:56] ostriches: you need to use an older version of composer to work with our stuff [15:44:12] Added a note on the patch and link to the bug [15:44:28] I'm using the one packaged in homebrew :\ [15:44:59] yeah. upstream decided that its our fault and won't let us patch it [15:45:06] they probably are right [15:45:11] So I just have to pretend that file DNE? [15:45:23] It changes a few other files too [15:45:27] Makes it a pita [15:45:30] no, you really need to build vendor using an older composer [15:45:41] 1.1 is fine, right? [15:45:42] https://getcomposer.org/download/1.1.3/composer.phar [15:45:49] because if you don't check it in then things are busted for PHP 5.6+ [15:45:58] ostriches: Just put it in $PATH at higher importance [15:46:24] 1.0.3 is the last one that doesn't have the static stuff [15:46:36] composer self-update 1.0.3 [15:46:38] How much of vendor/ do we actually use in mw-config anyway? [15:46:40] * ostriches sighs [15:46:54] https://getcomposer.org/download/1.0.3/composer.phar [15:47:26] composer mongofill perftools pimple slim twig [15:47:32] All of that for multiversion? [15:47:34] ostriches: the bug on the Wikimedia side is the mass linting of all files [15:48:36] Eh, for xhgui [15:49:10] Seems like wrong place for those files, but w/e [15:49:12] :D [15:49:20] lol [19:21:59] Catchable fatal error: Argument 1 passed to SpecialCiteThisPage::showCitations() must be an instance of Title, null given in /srv/mediawiki/php-1.28.0-wmf.23/extensions/CiteThisPage/SpecialCiteThisPage.php on line 117 [19:26:08] uhh [19:26:25] ostriches: is there a query string or URL to go along with that? I thought I had tested that pretty well [19:27:18] Nope :( [19:27:42] https://logstash.wikimedia.org/app/kibana#/doc/logstash-*/logstash-2016.10.25/hhvm/?id=AVf9QVPNJLU8TfYDmnB3 [19:29:30] oh I'm silly [19:29:36] I figured out how to trigger it [19:29:58] visiting Special:CiteThisPage directly is broken [19:30:18] patch in a few minutes [19:31:20] Awesome thx [19:31:36] Just spotted in group0 dashboard, wanted to get it looked at before we do group1/2 later this week [19:36:25] * legoktm is waiting for his mw-extensions mega repo to finish updating... [19:37:52] protip: `git fetch --recurse-submodules --jobs 8` if you have new enough git [19:37:58] (1.9+, iirc) [19:38:03] Or maybe that's 2.x [19:38:05] Either way [19:38:15] You can fork the fetches :) [19:38:20] I think it's 2.9, and fedora isn't there yet :( [19:40:04] > 807 files changed, 811 insertions(+), 816 deletions(-) [19:40:05] waaat [19:40:27] I think I didn't git pull for like a week [19:40:55] I pushed to all extensions yesterday [19:40:56] :p [19:41:03] ohh [19:45:23] ostriches: https://gerrit.wikimedia.org/r/317869 [19:46:33] merging [19:48:00] Backporting now [19:48:53] thanks [20:12:46] I've got a funny bug/problem with using OAuth and the mwclient python library [20:13:11] it works fine when I'm talking to a local wiki [20:13:28] it also works fine when I use it against meta and mediawiki.org [20:13:47] but it fails every time I try to use the library with wikitech [20:14:06] wikitech says that my nonce has already been used [20:16:57] The big config difference I see is that meta and my local wiki are using RedisBagOStuff for the nonce cache and wikitech is using MemcachedPeclBagOStuff [20:17:31] so I have this weird suspicion that RedisBagOStuff and MemcachedPeclBagOStuff have different behavior for add() [20:17:40] * bd808 goes to see if he can figure that out [20:30:32] AaronSchulz: can you think of a reason that RedisBagOStuff::add() and MemcachedPeclBagOStuff::add() would behave differently for the OAuth nonce check? The usage from OAuth is to call add( $key, 1, $now + 300 ) to check to see if the key has been used in the last 5 minutes. [20:31:00] I can't recreate it failing on first call via eval.php but the python client is failing every time [20:32:11] so either (a) mcpecl is returning false positives or (b) redis is returning false negatives [20:32:17] neither seems good [20:33:42] bd808: any memcached errors in the logs? the OAuth extension does not attempt to distinguish nonce failures from memcached failures [20:34:41] I didn't notice any, but I'll make the failure happen again and look closely [20:34:52] ostriches: re: mediawiki-announce, what do I need to do to get the announcement posted? [20:35:28] My help :) I'll unmod you briefly for you to send, then re-mod [20:36:43] bd808: MemcachedPeclBagOStuff::checkResult logs the result of each MC lookup at the debug level, you should obtain that somehow [20:37:55] I can't think of a different off hand and looking at the code just now [20:40:05] ostriches: cool, could you do that then? [20:41:49] Gimmie 5m [20:42:38] thanks [21:32:59] blerg. when I change things to get debug logging the error goes away [21:33:46] but on the plus side I now know how to get full debug logs from silver and how to do that via the mwclient python library too [21:47:53] those are the best bugs! [21:48:06] presumably something timing-related, then? [21:50:09] you can probably just live-hack the server to raise reporting level to debug on that one channel ('memcached' I think) [22:22:57] I think it may even be weirder than timing. I'm going to try changing a few other things in my app to see if I can narrow it down. It may end up being a strange bug in the mwclient library itself [22:23:36] oh! ha! [22:23:52] the "fix" I did to add headers also disabled oauth [22:24:01] * bd808 fixes the fix [22:34:37] ok, error is back but I have some more logging [22:35:03] add(OAUTH:labswiki:nonce:488657bf1acb0943401ef0b0dc037729:oauth_token=08938a4c5f6f90fc34d1b9eab75647ef&oauth_token_secret=b530a17b017fb4ba2c104c9ba2df46f0db6bcde2:91329269640443186371477434474) is returning NOT STORED [22:35:18] which I kind of already knew [22:35:36] but now I can at least see the full key [22:36:35] there should be a set command in there somewhere with the same key [22:36:57] I actually see the add() called twice [22:37:12] which would certainly cause the bug [22:37:28] request id is the same [22:37:45] so now to figure out why it would get called twice [22:38:56] I'm probably going to have to hack a stack trace into the log [22:57:32] the extension code seems pretty straightforward [22:59:30] the only thing i can imagine is that mwclient somehow sends the OAuth handshake itself as an OAuth request (ie. with an Authorization) header and the nonce gets checked twice, once in the session provider and once in the Special:OAuth application logic [23:00:05] https://gerrit.wikimedia.org/r/#/c/318009/ [23:06:40] nvm, the session provider is never used for non-API requests [23:08:23] legoktm: ty :) [23:08:41] ostriches: np. Were you going to do backports of the listed commits or should I? [23:09:06] I was just suggesting them, I'm not planning to review them right now [23:09:23] * ostriches goes on vacation starting tomorrow @ noon :p [23:11:29] I backported one of them that added 1.28 release notes [23:12:30] ostriches: oh, don't we also have to bump the number in all the other places too? new release notes file, phpversioncheck, etc.? [23:12:59] Version number in defaultsettings was most important :) [23:13:13] Anything else is just a bug I introduced to master in 1.29 😂 [23:15:33] I'll amend your change [23:30:10] tgr: I don't have it all worked out, but the problem is in MWOAuthSessionProvider [23:31:07] it verifies the request which marks the nonce as used and then calls MWOAuthUtils::getLocalUserFromCentralId which ends up trying to verify the request a second time in the same request [23:34:17] oh, you are getting the error in an API request! somehow I assumed it's happening during the authorization [23:40:19] bd808: so I think that bug can be triggered by anything that causes $request->getSession() to be called twice on two different WebRequest objects [23:40:52] which shouldn't normally be happening, but... session import for jobs maybe? [23:41:26] I'm writing up a bug on phab [23:42:02] maybe we can figure it out from the stack traces I have [23:42:21] I can repro on labtestwikitech so its easy to live hack and get more data [23:42:40] OAuthSessionProvider should probably just have an in-process cache for nonces it already found valid [23:42:59] yeah, that would fix it pretty easily