I work on the MediaWiki Security Team.
Sat, Sep 21
To answer my own question, i did a quick test - Currently its 26751 bytes compressed. Super aggressive gzip (zopfli) could in theory bring that down to 25532 bytes for a saving of 1219 bytes. More sane would be brotli, which could bring down to 23763 bytes for a saving of 2988 bytes.
Interesting. Thanks for sharing this. I wonder if this is an area that would benefit from more aggressive compression. The data is cached from what i understand so it doesnt have to be compressed on the fly, and getting as much as possible in that initial window seems important
Fri, Sep 20
As an additional check, is the included google analytics also intentional in light of T201022?
Is it intentional that wikimediafoundation.org is loading resources from wikimediafoundation-org-preprod.go-vip.net ?
Wed, Sep 18
I think a more fruitful starting place for this sort of thing would be doc.wikimedia.org - its probably simpler as a semi static thing, and i think at these early stages it has more relavent info than discourse does at present (although ideally search would search all the things)
Sun, Sep 15
Im sorry, i dont mean to be harsh, but you are very far away from the expected level of familarity with mw code and quite frankly skill, expected of someone with +2 rights
Fri, Sep 13
In any case, critical errors thrown in DeferredUpdates should not be invisible per default on 3rd party installations. This ticket should stay open until that problem is resolved.
Thu, Sep 12
This is kind of an obscure aspect of CORS, and i certainly haven't tested it, so i might be wrong, but: https://fetch.spec.whatwg.org/#credentials says "Credentials are HTTP cookies, TLS client certificates, and authentication entries (for HTTP authentication). [COOKIES] [TLS] [HTTP-AUTH] ". My reading of that, combined with "A CORS non-wildcard request-header name is a byte-case-insensitive match for Authorization. would be that allow-credential just affect browser managed credentials, and if you explicitly put Authorization in the allowed headers (must be explicit, it is not included with a wildcard), then you can override the value of the Authorization header. But I haven't tested it, and CORS is complex, so I may be misunderstanding.
But if your authentication is coming from an Authorization header, and no cookies are involved, the Access-Control-Allow-credentials would have no effect, as that only controls browser level credentials (cookies, TLS certs, http basic auth, etc)
If the API allows for authorization with the authorization code grant (or some other authorization mechanism that is stateless and does not force the client app to expose it's own secrets), then it is safe to add Access-Control-Allow-Credentials. >However, if the user adds the credentials the Access-Control-Allow-Origin will need to be specific to the Origin requested. Since credentialed requests are not cached anyways, this shouldn't be a problem.
the server is not aware of the logged-in statethe clients authorization token is not transferred to the server in an automated way
Storing session state on server side (whether in memcached or whatever) instead of as an encrypted blob on the client has lots of upsides
Wed, Sep 11
Tue, Sep 10
Sun, Sep 8
Tue, Sep 3
Mon, Sep 2
Sun, Sep 1
So roughly what needs to be done here:
Fri, Aug 30
Aug 22 2019
https://www.mediawiki.org/wiki/Special:Code/MediaWiki/r80434 in the old numbering scheme = 3b84269eb2612e in the new numbering scheme
Aug 21 2019
Aug 20 2019
Aug 19 2019
Hmm, this is the second issue with revdel & Special:Redirect :( [The other one being T187638]. Guess we need to be careful with this page
@Bawolff How about using the existing approach for large categories, and one based on page_random for smaller categories? Determining category size has to be efficient, as we are doing it every time a category page is shown (for pagination purposes
Yes, i was speaking a bit informally. I meant a constant number of queries which read one-ish rows which would technically be O(log n) due to the logrithmic time of looking up an arbitrary item in a B-tree
Aug 18 2019
P.s. for historical background see T27931 where the suggestion to use the search backend also came up (probably more practical now that we movedfrom lucene to cirrus)
Aug 16 2019
Note. Only happening on my talk page not happening on other pages. Maybe related to having a new msg on my talk
Aug 8 2019
Aug 3 2019
One of the commonly proposed schemes if you only need equality comparison is to use deterministic encryption (Abbreviated as DTE-encryption in the paper). If you don't have the private key, deterministic encryption basically has the same properties as the HMAC construction you proposed. The linked paper discusses some attacks on encrypted db's, using medical information as an example. It mostly concerns itself with systems that allow range queries, but section 5 talks about deterministic encryption. It describes 2 attacks, the first one (frequency) is pretty straight forward. Applied to this bug, it would be something along the lines of: Take all the IP edits from the last month before switching to the hashed IP scheme. The IP that edited the most is probably the same as the hashed IP in the next month that edited the most. Then take the second most common IP, and so on.
I do not believe there is a perfect solution, only less-terrible ones. If we are searching for a perfect solution, I think we will be searching forever.
Aug 2 2019
If you extend RedirectSpecialPage it happens automatically. Otherwise override isListed() method
I kind of disagree. I don't think subsequent pages of results should start at 1. If we knew how many results came before on previous pages, then I would think this is a good idea, but since we don't, i think unordered lists are less confusing.
Just as an aside, the ideal way to demonstrate fb surveliance is taking place, would be to attach a HAR file that shows what network connections are made, although doing this does require some technical knowledge it would be pretty unambigious.
I think this is fine. Logging when it matches an abusive pattern isn't a privacy issue, because it's not correlating reader behavior, since the url isn't a page being read - it's abuse.
Jul 31 2019
The form seems a little underfilled out... There was basically one production error which arguably was intentional behaviour (albeit maybe a poor design choice not to suppress it)
Jul 19 2019
Related to this, is potentially the old feature request for translatable category names, which at one point commons really wanted, although i havent heard much about it recently (one suggested solution was to basically switch up the display title based on user language to the various redirects to the category, although i think there were some concerns that that is hacky, but the discussikn was a long time ago and i dont entirely remember)
Jul 18 2019
Partial read restrictions are rather poorly implemented in mediawiki. They prevent direct page views but there are lots of indirect ways to leak page contents. There has been little interest in fixing this in the past as its not something that wikimedia uses. There has been mixed interest from (corporate) third parties with some really wanting it but a minority viewing lack of functional read restrictions to be a killer feature (due to perverse incentives in the corporate environments those users use mediawiki in).
Lastly, AbuseFilter should implement the userCanhook to control access to the filters (i.e. if a filter is marked as Private, it should prevent read for all unprivileged users of both the content and the discussion page). The private filters will also need to be filtered out of the database replicas (that are available on Toolforge and as dumps).
Jul 17 2019
Jul 16 2019
Does maybe ci have less memory available? (When i used to test on my old laptop with low ram when ram ran out things slowed to a crawl (presumably lot of swapping)
Looking at the code, what you're describing can't really happen. Are you sure you didn't just set $wgSpamRegex to something else in LocalSettings.php, and the problem went away when you added $wgSpamRegex = false; at the end of LocalSettings.php because it overrided the previous code in LocalSettings.php?
Note, the default has been an array since 2008 - 06e3d0e3777
Where SESSION_ID is the users session id. This would create a new mask every time the user's session was generated (i.e. each new device and browser, etc.). This would, of course, break the social contract of what the mask represents, but would be technically trivial to implement as the masks would function identically to the IP masks.
From a Wikipedia anti-vandal perspective, I suspect the hardest sell would be not being able to see patterns related to ranges/ip-distance, at a glance.
Jul 6 2019
Jul 2 2019
Jun 25 2019
So yeah, I guess this counts as passes security review as none of those issues were security related. May need additional security review if the extension changes significantly. Should still get approval from Rel engineering before deploy.
Jun 21 2019
Main reason its restricted is it used to be autoconfirm but enwiki got mad (if i recall)
Jun 12 2019
May 22 2019
May 17 2019
May 14 2019
May 10 2019
So I guess this isn't quite ready for a security review given previous comment, but some thoughts
This is old enough now to no longer be relevant.
Ah, that's confusing. Thanks.
The threat model here is kind of debatable. Its unclear what security goals we are trying to accomplish with the displaytitle restrictions, and thus I'm unsure (unsure in the sense of actually do not know, not unsure in the sense of disagreeing) if further restrictions on it are justified.
May 9 2019
May 8 2019
wikititle:/// is supposed to prevent query paramters from being used, however it could probably be bypassed if they are percent encoded due to T96274 (e.g. https://en.wikipedia.org/wiki/Main_Page%3faction=history%26curid=2120 is interpreted by our servers incorrectly )