There's a lot of log entries that look like:

@Niharika Do you currently have 2FA enabled in phabricator (If not please enable)

In T173891#3546429, @kaldari wrote:

The table should not be in dumps - it could contain revision deleted IPs.

@Bawolff: How are revision deleted IPs currently dealt with in dumps?

Should the data be made available on the labs replicas and/or dumps: Yes, nothing in the table is private data

In T155678#3545164, @Addshore wrote:

In T155678#3545113, @Bawolff wrote:

How about Flow?

Its worked well enough for Project:Support_desk

I can't even figure out how to search for solutions to problems / answers to questions there :/

How about Flow?

In case its helpful here: While working on a bug about what tables to classify for labs, I categorized the db tables at T103011#3536648 - the "useless" category mostly contains things that probably should be dropped.

In T173468#3533188, @Legoktm wrote:

In T173468#3530348, @ArielGlenn wrote:

How often would we want this dump generated? And just ot be sure, there is no possibility that an entry in the globalblock table could be hidden or otherwise not visible to the public, right?

Weekly sounds reasonable to start with. And, I believe so. It would be good to have @Bawolff or someone else from Security-Team to confirm though.

Oh, that might be my fault. I suspect this is a side effect of 7730dee63b1 (Transcluded special pages are now always treated as if they come from 127.0.0.1 to prevent data leaks, and be nicer to caching)

I suspect this is due to thumbor.

In T172650#3531682, @chasemp wrote:

I think we should remove the restrictive security ACL here. This is a policy and notification issue rather than a sensitive security issue.

In T170907#3527646, @Audiohazel wrote:

Ok. Do I need to create MFA for the vcoleman account on LDAP? How do I do that?

In T135963#3529071, @Catrope wrote:

@Bawolff What's the status of this? At least from this task it looks like it's been stalled for quite a while?

The image issue should probably just have an alt text set to the empty string (in ExtensionDistributor/includes/specials/SpecialBaseDistributor.php )

I think its very unlikely we will provide redacted sql files for the entire db. (Roughly) Equivalent data in xml format is available at https://dumps.wikimedia.org

In T132022#3522767, @MarcoAurelio wrote:

Sorry for the offtopic but does Newsletter have CheckUser integration? If not, it must have it.

It looks like abusefilter stops the edit, but not the custom newsletter table edits

In T132022#3522439, @Bawolff wrote:

In theory content handler should make abuse filter integration autoamtic. We should test to see if that actually works properly

In theory content handler should make abuse filter integration autoamtic. We should test to see if that actually works properly

This seems done as newsletter now uses content handler, and that automatically adds check user entries.

In T173237#3522260, @Reedy wrote:

Isn't this essentially the same as https://en.wikipedia.org/w/api.php?action=query&list=allusers&auprop=groups|implicitgroups|rights|editcount|registration&aulimit=max

on https://www.mediawiki.org/wiki/Project:Support_desk?useskin=timeless

Arguably it might make sense to have different rights on test then on real wikis

I'm not sure how i feel about this, but... if we do something like this, I think it would make sense to do foo@wikipedia.invalid so its clearly a non-real email address.

In the end, no private info was revealed, so this can be public again?

In T172878#3513053, @GoldRingChip wrote:

Yes, I’ve tried. But the problem is that I can’t use TFA and it needs to work to disable it. I have a Token, a Secret Key, and 4 scratch codes. All the scratch codes have been used, and the TFA process doesn’t send a new code to my device.

——
Mark Adler

@Ragesoss says this could be closed

For reference, google translate was

My initial reaction would be that this is probably working as intended, but I'm not really sure what the privacy model for tool labs is.

ok cool, please let me know when all that happens.

rm tag Security . imo that tag should probably not be used for tracking bugs unless the thing they are tracking is a specific issue

Ok, I'm going to make a decision to call this wontfix. At the time this was reported in 2013 it was a legit bug imo, but at this point, an XSS against IE6, which can't even view most modern websites due SSLv3 only, when using an obscure (?) apache configuration, is simply not a bug. People on IE6 have so many other problems to worry about, its not worth caring about their security against an XSS.

Hmm, the cdb thing is perhaps not the best data structure, really we should use bloom filters instead.

Addressed with https://github.com/SemanticMediaWiki/SemanticMediaWiki/pull/2590.

In T147199#3498842, @Quiddity wrote:

In T147199#3498052, @Bawolff wrote:

perhaps in the error page, the "use Firefox!" should be directly linked to the firefox 52 esr download page. The easier for users to find the link, and the less clicks the user has to go through, the more likely they will actually do it.

+1 to that. The next issue of Tech/News (draft, but will be frozen for translators in ~20 hours) points directly to the ESR page.
However, note that Firefox ESR 52 is ending support in Q2 of 2018, IIUC from the FAQ
But there are no decent alternatives for WinXP, at all.

To answer my own question: https://github.com/wikimedia/wikiba.se

Is the site in a git repo somewhere?

perhaps in the error page, the "use Firefox!" should be directly linked to the firefox 52 esr download page. The easier for users to find the link, and the less clicks the user has to go through, the more likely they will actually do it.

I approve on behalf of Security-Team

If we want to flat outban this sort of thing, we could use csp to do it.

In T171293#3460852, @MarcoAurelio wrote:

I don't think we can deploy this to more wikis taking into count what it is happening at T31596 and T124841. Pinging @Bawolff for advice.

No need for ears to bleed, I just want to ensure that the potential impact of sql injections are not underestimated, or underestimated by other people who might be reading the comments on this bug.

It's very bad, no doubt, but this db is read-only and public so there's no real harm.

In T134863#3451521, @hashar wrote:

The CentralAuth patch for SECURITY XSS in Special:GlobalGroupPermissions has NOT been cherry picked to REL1_29.

List of patches: https://gerrit.wikimedia.org/r/#/q/fadb367ad16a228cc

I'm going to resolve this bug. There's literally nothing we can do here.

Everything merged and publicly announced.

Everything done and publically announced.

Now that I made this public, I don't know if I should change the status of this bug, maybe remove the security tag and have it off the Security workboard? I don't think it should be closed, since its a valid bug in the MediaWiki-extensions-SimpleSecurity project, but it maybe should not be cluttering up Security - i don't really know.