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.

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:

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

@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:

1. 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.
2. I've never done a full security patch and deploy before, by myself.

Hey everybody-

Hey Jon-

Thanks, @Aklapper.

@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.

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.

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.)

@Bawolff, @JBennett, @Reedy or @chasemp will need to grant you access to Security, as I believe they are currently the only folks w/ Phab permissions to do so.

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.

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.

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.

Apologies, but this is going to be delayed a bit due to other ongoing issues. Still hopeful I can turn it around sometime soon.

@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.

@MMiller_WMF Ok, sounds good. I believe a local Privacy Policy like this would override the standard Terms of Use, Cookie statement and Data retention guidelines, which should be fine. Thanks.

This is looking good. I think the important things left are:

@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.

Tagging @JBennett for approval (so I can start doing Brian and Sam things)

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.

@Aklapper - mw core: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/master/includes/password/PasswordPolicyChecks.php

@Bawolff I do for Security-Team but apparently not for Security...

I believe @Reedy has the magical powers to do this, and maybe @JBennett? There's also this one: T204853.

Seems like there's been a decent effort to get SecurePoll to play nicely w/ the seccheck plugin: T202365, https://gerrit.wikimedia.org/r/460211/

Sounds good, thanks.

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.

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.

Not sure why, but adding

(Tagging @JBennett for any approval issues)