I work on the MediaWiki Security Team.
There's a lot of log entries that look like:
@Niharika Do you currently have 2FA enabled in phabricator (If not please enable)
Should the data be made available on the labs replicas and/or dumps: Yes, nothing in the table is private data
How about Flow?
Mon, Aug 21
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.
Sun, Aug 20
Fri, Aug 18
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.
Thu, Aug 17
Wed, Aug 16
Tue, Aug 15
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
Mon, Aug 14
Sun, Aug 13
It looks like abusefilter stops the edit, but not the custom newsletter table edits
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.
Sat, Aug 12
Arguably it might make sense to have different rights on test then on real wikis
Thu, Aug 10
I'm not sure how i feel about this, but... if we do something like this, I think it would make sense to do email@example.com so its clearly a non-real email address.
In the end, no private info was revealed, so this can be public again?
Wed, Aug 9
@Ragesoss says this could be closed
Tue, Aug 8
For reference, google translate was
Mon, Aug 7
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.
Sat, Aug 5
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.
Thu, Aug 3
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.
Wed, Aug 2
I approve on behalf of Security-Team
If we want to flat outban this sort of thing, we could use csp to do it.
Mon, Jul 31
Fri, Jul 28
Jul 21 2017
Jul 19 2017
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.
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.