Member of the Security-Team. My user-sbassett board should be fairly up-to-date, though we also track some other work within Asana these days.
User Details
- User Since
- Sep 12 2018, 3:52 PM (237 w, 1 d)
- Roles
- Administrator
- Availability
- Available
- IRC Nick
- sbassett
- LDAP User
- SBassett
- MediaWiki User
- SBassett (WMF) [ Global Accounts ]
Wed, Mar 29
Tue, Mar 28
Mon, Mar 27
Declining this as I think it is likely a relic of the past. We still have the the mediawiki-i18n-check-docker running for twn messages, phan-taint-check running under phan for most php repos (which can find problematic message usage like this), bugs like T200997 seemingly mostly resolved and still-active efforts like T2212.
It might not be terrible to port Whispers' rule regular expressions over to client-side js, but that kind of defeats the point of leveraging an upstream project IMO. As far as JS-ish things that currently exist, this Node fork of Yelp's detect-secrets looks pretty unmaintained at this point. And this eslint plugin seems more entropy-focused than problematic, basic string patterns (e.g. password=).
Wed, Mar 22
Tue, Mar 21
Sure, it's just that, as also mentioned within the security review (T324989), we can't iframe external content within Wikimedia production. And in this case, anything under wmcs or toolforge would be considered external content. So that would be a blocker to getting OWID into Wikimedia production. Hence the suggestion of developing a microservice to deliver any relevant OWID content which could live within Wikimedia production.
Mon, Mar 20
So there are at least a few CLI tools - git secrets, whispers, gitleaks - that we (sec team) have experimented with for our manual reviews. It would be nice to maybe leverage one of these established tools with a hypothetical Phab plugin.
Confirmed 2fa enabled for @nfraison:
ext:StopForumSpam also echos back a user's IP address via the following error message (if they're disallowed access by the extension): https://github.com/wikimedia/mediawiki-extensions-StopForumSpam/blob/master/i18n/en.json#L13. It is unclear to me if this sort of thing will be disallowed under the new IP Masking policies.
@Aklapper - seems like there are no objections here, with at least one blessing from the Release-Engineering-Team?
Tue, Mar 14
The Security-Team are the ostensible drivers of this work, but we have no resources or plans to work on it, so I'll mark it declined for now.
Added an update to remove a noisy rule: https://github.com/wikimedia/eslint-config-wikimedia/pull/490#issuecomment-1468547357.
Thanks, @MarcoAurelio. Some initial notes on the proposed questions/metrics:
Ping @thcipriani @brennen et al to see if there are any objections to this request. Thanks.
Ok, I've revised the policy description (the warning, specifically): https://phabricator.wikimedia.org/project/manage/4570/. Let me know if there are any additional concerns.
Mon, Mar 13
Done. Logstash seems happy and I confirmed the verb switch in the log messages.
Fri, Mar 10
Note that on ShoutWiki this table is shared between all wikis; WMF may or may not want to do the same.
Thu, Mar 9
Wed, Mar 8
Hey @hashar et al - Any reason not to make this task public at this point? Thanks.
Mon, Mar 6
Thanks, @sguebo_WMF for the privacy review. I'm going to block this review for now on the above issues being acknowledged and either accepted by the correct level of WMF staff per our current risk management framework or mitigated in some other fashion to reduce the assessed risk level.
Regardless of T309900#8462082 (and the currently open, related change set), I'm personally fine putting es.wikiversity in enforce mode, given its relatively lower traffic and the fact that it's fairly trivial to disable ext:SFS if it causes problems or proves mostly ineffective. Thoughts, @Reedy?
Thu, Mar 2
Wed, Mar 1
Tagging Privacy Engineering for an opinion/risk rating about the following. I'm not certain there's precedent for this on Wikimedia production or that wmcs would completely satisfy any privacy concerns for proposed, embedded content like this.
Feb 27 2023
The vast majority of these seem to have been fixed over the years? A quick code search reveals a few rawParams(...)->text(...) calls. Sourcegraph finds some others with its structural search of our github mirrors. A few of these are likely true positives, maybe, though the rest have either been noted as exceptions via // @phan-suppress-next-line SecurityCheck-XSS comments or are in unit test files.
Feb 24 2023
To be honest, I don't know if this and similar issues matter much unless a more formal strategy around Technical-Debt is implemented and code stewardship/maintenance is reassessed. Phabricator in aggregate is pretty noisy and, as others have noted, is without commonly-shared standards around its usage for things like task priority, which I'm not sure is even solvable. I do like @Bawolff's suggestion (in his wikitech-l response) - as an initial step - to separate various teams (wmf, community, both) from actual codebases or projects within Phabricator, in relation to what is being prioritized and worked upon. I believe that would help with various misunderstandings like "the Security-Team works on every task tagged with Security". This would be a significant change though and likely difficult to propagate.