I'm not sure how worthwhile this would be if we ever got a decent password strength meter deployed. Though digging through the history, that might be a big if.
If we're looking to abandon https://gerrit.wikimedia.org/r/475798/, my vote would be to instead go with https://gerrit.wikimedia.org/r/478395/, as it does a good job of balancing both security and usability IMO.
Thu, Dec 6
Thanks for all of the quick follow-up on this. https://gerrit.wikimedia.org/r/477972 looks good as additional hardening and the new test within test/mt/Yandex.test.js runs well. I think this is looking pretty good, and would like to leave the SAFE_FOR_JQUERY flag implementation up to you and the Language Team to discuss further, as I believe I've probably provided as much relevant feedback within https://gerrit.wikimedia.org/r/477459/ as I can. Also, thanks for the information regarding the specific implementation of the Youdao service. I'm going to review that a bit more, but for now I'm not seeing any issues there, as it seems to be a more restrictive (fewer html tags/markup) version of the 1) reduce html 2) send to MT service 3) expand translated html process.
Interesting - thanks for the context and history, @Anomie.
Trust-and-Safety might have some additional thoughts here, as they currently manage the operational work around OATHAuth at the moment. Though the tasks @Tgr mentioned should alleviate most of their concerns, I'd imagine.
A bit out of scope for this task, but have we ever considered creating alternative captchas (math, image classifying, etc?)
A summary of where I think we're at right now:
Wed, Dec 5
This need to fix via: https://github.com/gwicke/kad/pull/1
This is coming from service-runner and affecting all services. We have asked services team to update the dependencies
Tue, Dec 4
Mon, Dec 3
@Bawolff and I are deploying this now.
@santhosh et al-
@Daimona, @Huji - I checked that T210329.patch applies locally to the abusefilter master branch. Looks good. Not sure if @Bawolff or @Reedy are around right now, but we do have the security deployment window today at 22:00 UTC, so just a shade under two hours away (https://wikitech.wikimedia.org/wiki/Deployments#Monday,_December_03). I've got deployment rights and have done config deployments before, so I could probably do this, but:
- I don't have CU anywhere, so the best I'd be able to test is locally. The patch doesn't look volatile, but if anything looked amiss in the logs, I'd have to revert immediately.
- I've never done a full security patch and deploy before, by myself.
Thu, Nov 29
Wed, Nov 28
Tue, Nov 27
Mon, Nov 26
Tue, Nov 20
@Jdforrester-WMF The Security-Team discussed that item today as well, and perhaps filing it as a separate task related to this issue. Given some of the feedback above, it might be wiser to pursue that approach as opposed to this one.
@Catrope - sounds good, thanks.
Well you are proposing removal of functionality that's only displaying public data. This does need to be balanced against the value of that functionality.
Is that a bad thing? Increasing obscurity and potentially deterring certain behaviors while reassuring legitimate users seems like a good thing.
Mon, Nov 19
She may have two wikitech accounts. The one she's linked to Phab is Marble: https://phabricator.wikimedia.org/p/mmarble/. So I'd guess that's correct - @mmarble, can you confirm which wikitech is your primary? Then I'd imagine we can close this out.
Agreed. I'm also happy to mentor anyone for this task, as far as working on mw code, CR in gerrit, etc.
If we're just talking about three instances here (lines 89, 112, 117) in PasswordPolicyChecks.php (all I see atm), could this be a Google-Code-in-2018 task? I feel like, given the severity, this could potentially be done publicly in gerrit.
I'll start on this. @Catrope - just to confirm, everything there is for this extension is already at: https://github.com/wikimedia/mediawiki-extensions-TheWikipediaLibrary (aside from Flow, which it integrates with)? No pending or near-future commits atm? Thanks.
Thu, Nov 15
Wed, Nov 14
Right. I'm on the Security-Team and I'd imagine we'd be fine giving any SRE member rights to Security. I just tagged the folks above as they are 1) also on the Security-Team and 2) have full rights to add members to Security (I currently do not.)
Tue, Nov 13
Nov 7 2018
Thanks for the update and info - still learning my way around some of these components. This all sounds fine. And yes, if you wouldn't mind adding me as a reviewer when any additional patches are submitted to gerrit prior to launch, that'd be great.
@Krenair - that's correct, re: her wikitech username.
Nov 6 2018
Security Review Summary - November 2018
Overall, this extension looks pretty good. No PHP or JS package/module vulnerabilities as reported by npm audit and security-checker. No DoS vectors or http leaks. And it looks like many of the items elicited here and here are fine or a non-issue for this extension. I did find a few minor things noted below:
This will be completed today. I spent most of yesterday reviewing it and just have a couple more items I wanted to check. So far nothing major to report.
Nov 2 2018
fwiw, I'm not seeing anything egregious within r/469211. I've got the extension enabled in mw-vagrant and am going to pen-test a bit more. Should have full results early next week.
Nov 1 2018
Apologies, but this is going to be delayed a bit due to other ongoing issues. Still hopeful I can turn it around sometime soon.
Oct 31 2018
@ema Looks like I'm in (sbassett@stat1007:~$)
Nevermind, I see T208431 now (thanks, @Krenair). Looks like that's in progress.
Did you get added to the wmf LDAP group? Not seeing you here: https://gerrit.wikimedia.org/r/plugins/gitiles/operations/puppet/+/refs/heads/production/modules/admin/data/data.yaml, which I think you should be? You'd probably want to create a ticket like T204382 for that. I think you can just use the standard task request form: https://phabricator.wikimedia.org/maniphest/task/edit/form/1/ and then add LDAP-Access-Requests and Security-Team to the tags and someone will get to it.
Oct 30 2018
This is looking good. I think the important things left are:
Oct 29 2018
@Catrope- still hope to have this completed by tomorrow or this Weds (apologies - recent security incident fallout). One initial step I was reminded of by @Bawolff that is quasi-security-related - have the new privacy and data retention policy statements (for surveys, etc.) been approved by legal yet?
@jijiki - I think I just need deployment and analytics-privatedata-users. I modeled it off of what @Bawolff has here, which should be all I'd need for now: https://phabricator.wikimedia.org/source/operations-puppet/browse/production/modules/admin/data/data.yaml.
Oct 26 2018
Tagging @JBennett for approval (so I can start doing Brian and Sam things)
Oct 24 2018
Hey @Catrope - I should be able to look at this soon and have a review by the 29th for you. I'll focus on the patch (469211) and let you know if I have any questions. Thanks.
Oct 23 2018
Oct 17 2018
Oct 16 2018
Oct 11 2018
Oct 5 2018
Oct 4 2018
Sounds good, thanks.
Oct 2 2018
Hmm, a handful of flake8 fails unrelated to my patch: https://integration.wikimedia.org/ci/job/tox-docker/4084/console. I could add the check codes to the ignore list in tox.ini, but I'm probably not the right person to make that call.
Not sure exactly what issues this ticket meant to address, but I was able to get the docker env working for the current master branch of wikimetrics with a few modifications to docker-compose.yml and wikimetrics/config/queue_config.yaml, under docker 18.06.1-ce using the rev 3 compose file format (https://docs.docker.com/compose/compose-file/compose-versioning/). I know this is a low-priority item at the moment, but I wanted to get this working for some sec rev work I'm performing (though sadly, the meta and Google OAuth config tokens seem to maybe not be working within my local dev env.) Happy to submit this patch in gerrit if it helps solve some of these issues.
Sep 21 2018
FWIW, as a recent staff addition,
I don't recall signing anything resembling an NDA within my new-hire paperwork. apparently that was in my Terms of Employment sheet.
Sep 20 2018
Sep 18 2018
Not sure why, but adding
Sep 17 2018
(Tagging @JBennett for any approval issues)