Tue, Mar 21
Hmm, this is the second time I've heard of using foo = '0' vs foo = 0 in queries adjusting the query plan. Maybe we should just have ints be ints in the db abstraction layer.
Recent logs suggest we may need to add "media-src 'self'" for webm files.
Wed, Mar 15
So the console output does say: https://integration.wikimedia.org/ci/job/mwext-mw-selenium-composer-jessie/2083/consoleFull
Warning: Could not find APCu, XCache or WinCache. 11:18:58 Object caching is not enabled.
Looking at the code more closely, what might be happening.
I wonder if we could add browser tests for this somehow (i dont know much about browser tests).the behaviour seems complex enough that testing would be good.
(see also T49162)
Tue, Mar 14
Ok, so current uses of SMW+friends on Wikitech is:
If this was me, I would close it as won't fix
Mon, Mar 13
To clarify, this is something that's wanted/would be useful to checkusers?
To clarify, paladox was asking for the full address of Wikimedia Foundation on irc, which made it sound like he was filling out some sort of form that is expected to be filled out by an official representantive of the foundation. I don't know if that's actually the case, or what this is really about at all.
This sounds more like a job queue error than a MSSQL server support error. Could you verify that your job queue is working correctly?
[This bug is pretty dead, so maybe irrelevant now] FWIW, I just attended EMWCon, there was a suprising number of corporate users who use MSSQL support and seem happy with it.
Sun, Mar 12
Hmm. Looks like the testing CSP policy would block the mobile tracking beacon since wikimediafoundation.org is not a valid img-src when viewing from m.wikimediafoundation.org
@kaldari To clarify, what's the status of this bug? Perhaps it should be closed, and someone could file a new bug if/when people actual intend to use this extension.
@Southparkfan : Do you still want re-review on this?
Review of 00f527cadfbf (Mon Oct 24, 2016). Overall looks good from a security perspective. My only major concern is potential incompatibility with any other extension which adds a namespace tab. There are some minor coding convention things that need to be fixed. The code is a tad dense, and could perhaps benefit from splitting into finer grained functions and having more comments.
[rm tag security-review. That should only be on the parent bug requesting the security review]
Tue, Mar 7
Just as a note, since these are all minor non-exploitable issues, they should not prevent putting the skin on betawiki (They should be fixed before deploying to a real wiki).
Review of 9613a9d4bc. Overall this looks good. I'm excited to see this be a skin on Wikimedia wikis. Some very minor issues with double escaping and not escaping "safe" values.
Mon, Mar 6
Security review passed. Everything looks good. (For reference, I looked at c9241268d38d)
Review of 094b110932df of StopForumSpam.
Sun, Mar 5
Fri, Mar 3
Thu, Mar 2
I think there is too much fuss being made over this bug. As a temporary solution until some larger table refactoring takes place (which i assume we want to do all at once) - both the increase field size solution is totally fine and the hash if field size doesnt fit is totally fine. I dont think the drawbacks that either solution hasreally actually matter.
Wed, Mar 1
ArielGlenn did this - https://wikimediafoundation.org/wiki/Special:AbuseFilter/1
Why 255 bytes for the ip address? If that represents a number, ipv4 and ipv6 have, respectively, 32 and 128 bits. If with hexadecimal you mean a string with the hexadecimal representation (and you need to be inefficient because manipulation needs, which is ok but please explicitly say so, it should be enough with 13 (18 with useless separators) bytes for ipv4 and 33 (40 with separators) for ipv6 (more with scope identifier, etc., but the point really is much less than 255 bytes). If you want to store something else there, like ranges, please specify, or any other format, please clarify. It looks like you put varchar(255) arbitrarily, which is a really bad idea, specially for old versions of mysql, that we sadly have to support.
Tue, Feb 28
Sorry folks I think I made a mistake here. The h4 does indeed appear to already be properly escaped (since Html::element escapes things).
I'm not worried about collisions. I'm worried about bloating an already huge table with more data for no practical reason.
Sun, Feb 26
Sat, Feb 25
Im not an expert on crypto so its possible im misinterpreting the paper, but I believe that https://www.iacr.org/archive/crypto2004/31520306/multicollisions.pdf suggests such constructions arent really much more secure then just using sha256.
Fri, Feb 24
Thoughts on if its worth it to ban the prefix of the shattered files on upload? The attack scenario seems very minor at this point, but it might help put users' minds at ease.
I guess theres always the question of what happens when someone makes an even longer collation name.
As more and more issues come up related to which wiki the notification is generated on (also things like the user would have to alter their pref on every wiki to be effective) I wonder if the design decision of where to generate the notice should be revisited. Maybe it should be jobqueued away to the user's home wiki.
Wed, Feb 22
We could just hash only in the case that the key is too long.
Are we still giving pre-release notice to third parties? I don't think we remembered to do that last release.
btw, https://www.mediawiki.org/wiki/Extension:FileExporter is a 404. Did you mean to link to somewhere else?
So is the image just not being added to normal image links? Because global image links should be automatic on any image usage.
I have no idea what that project is. I don't believe I had any involvement with that project at any point in time. With that in mind I'd like to unassign from self
Security does not matter here (no user input but configuration) and collisions are non-existing for such a small set of values.
Feb 22 2017
If there are issues with changing the field size, we could potentially just hash it if it doesnt fit.
Feb 21 2017
Feb 16 2017
Nemo_bis is a well known trusted person. While the other rights may be more appropriate, this should be resolved through normal channels as we have no reason to believe nemo would abuse his access or otherwise is a security risk.
Feb 15 2017
Actual, thinking about this further, its not clear that this would be faster than the dedicated table + query. They may have similar performance.
For reference, yuvipanda just submitted: https://gerrit.wikimedia.org/r/#/c/337898
For reference 139-128 = 11 which means segmenatation fault.
Some background at: https://stackoverflow.com/questions/35780397/understanding-service-worker-scope
I'm guessing this used the cuc_ip_hex_time timestamp, on cuc_ip_hex and cuc_timestamp. Here's the EXPLAIN:
Feb 14 2017
Feb 12 2017
This looks good. Review passed.
Feb 11 2017
So maybe, just maybe, we could get away with replicating rev_timestamp in our table, too?
Id actually be suprised if the index on cuc_timestamp came into play. That should only happen if the time range was small enough that filtering by timestamp was more efficient than filtering by ip address (mysql can only use indexes for one range in a query except in certain obscure circumstances that dont apply here). In any case you can check which index was used by running EXPLAIN.
Feb 9 2017
I have no objections for what its worth, although I'm not sure what the details are behind it not being enabled in the first place.
The problem is ultimately about doing a range query in 2-dimensions (time and ip space). If you truly need it to scale well with widely varying ranges in both dimensions, consider looking into full text indexes (e.g.elastic search), maybe, or perhaps whatever we do for gps coordinates. But that makes actually making the feature much more complicated.
Actually, for the above example, the most efficient thing to do (for ipv6 when the cidr range is a multiple of 16) would be just rev_user_text like "2602:306:%" dito for any ipv4 multiple of 8.
For the query you have above:
SELECT rev_id,rev_page,rev_text_id,rev_timestamp,rev_comment,rev_user_text,rev_minor_edit,rev_deleted,rev_len,rev_parent_id,rev_sha1,rev_content_format,rev_content_model,page_namespace,page_title,page_is_new,page_latest,page_is_redirect,page_len,(SELECT GROUP_CONCAT(ct_tag SEPARATOR ',') FROM `change_tag` WHERE ct_rev_id=rev_id) AS `ts_tags` FROM cu_changes LEFT JOIN `revision` ON (cuc_this_oldid = rev_id) INNER JOIN `page` ON (page_id = rev_page) WHERE (cuc_ip_hex BETWEEN 'v6-26020306000000000000000000000000' AND 'v6-26020306FFFFFFFFFFFFFFFFFFFFFFFF') AND (rev_timestamp > '20161101212048') ORDER BY rev_timestamp DESC LIMIT 51;