Just to clarify, despite being disclosed and announced today, Gadgets is a bundled extension, so the fix was released as part of MediaWiki 1.39.8 / 1.40.4 / 1.41.2 / 1.42.1.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Wed, Jul 10
Mon, Jul 8
Thu, Jun 27
Wed, Jun 26
Just mentioning this discussion I opened, wondering if an hidden gadget will surely become loaded for everyone if the "default" keyword is added afterwards, i.e. not at the time the gadget definition was created.
Mon, Jun 24
In T204201#9915821, @Od1n wrote:Would it be difficult to bring compatibility with AJAX previews… if ever it's feasible?
In T63007#9192707, @Krinkle wrote:In T63007#9192636, @Izno wrote:[…] but |namespace=-1 also would fit how special pages are dealt with (if that isn't already supported).[…]
namespace=-1 should already work indeed. The reason I suggest also supporting specials as an action is because a number of gadgets enhance the functionality of wikitext textareas, which appear on action=edit in many different namespaces, and on special pages like Special:Upload. action=edit would mean we (correctly) avoid loading the gadget on page views, but also (currently) makes it impossible to load on Special:Upload. namespaces=0,-1 would correctly load both on edit page and upload page, but would also load during page views. From a routing perspective, special pages are the equivalent of action="" or action=null, but to avoid hardcoding that or locking into no other possibilities in the future, I was thinking action=specials could represent that for completion within the Gadgets extension.
Sun, Jun 23
So (unless I'm mistaken), basically the rule is "RL may find the category if its wikicode tag exists in the currently displayed content". For instance:
Sat, Jun 22
Fri, Jun 21
Change #1047718 merged by jenkins-bot:
[integration/config@master] Add Scribunto as a phan dependency for Gadgets extension
Thu, Jun 20
This can be done now using the new categories option. The interface messages on top of change list pages (watchlist-summary, recentchanges-summary, recentchangeslinked-summary, histlegend) can be customised to include the category.
Change #1047718 had a related patch set uploaded (by SD0001; author: SD0001):
[integration/config@master] Add Scribunto as a phan dependency for Gadgets extension
Wed, Jun 19
Change #1047603 had a related patch set uploaded (by SD0001; author: SD0001):
[mediawiki/extensions/Gadgets@master] Add lua library for retrieving gadgets metadata
Jun 11 2024
In T241524#9873840, @Tgr wrote:The cache purge probably just requires queueing a links update job with the right parameters; I think that would be the same with a parser function (which would presumably be tracked in the templatelinks table).
In T204201#9877960, @Od1n wrote:Another issue: I have a case with a gadget ("Diaporama" here) that is defined with a "categories" condition, but this gadget may also be loaded using mw.loader.load()/ mw.loader.using() (by this script), on a page that does not have the category.
In T204201#9877960, @Od1n wrote:Another issue: I have a case with a gadget ("Diaporama" here) that is defined with a "categories" condition, but this gadget may also be loaded using mw.loader.load()/ mw.loader.using() (by this script), on a page that does not have the category.
In T204201#9873811, @SD0001 wrote:If you mean during preview, yes it will load if the last saved revision of the page had the category wikicode. What section you're editing is irrelevant.
Another issue: I have a case with a gadget ("Diaporama" here) that is defined with a "categories" condition, but this gadget may also be loaded using mw.loader.load()/ mw.loader.using() (by this script), on a page that does not have the category.
Jun 9 2024
Most of those issues could probably be fixed by using the ContentAlterParserOutput hook instead of BeforePageDisplay, to detect the relevant categories and add the gadgets to the parser output.
I don't think this should be closed just yet. This is still the "more correct" approach. The categories stuff is just a hack to avoid introducing new wikitext.
In T204201#9861245, @Od1n wrote:About the conditional loading based on categories: If we edit a section (instead of the entire page) and the category wikicode is outside the section, will the gadget be loaded, or not?
The category detection does not work when using quick preview and visual editor.
tested on fr:Moulinet_(échecs), Diaporama gadget is loaded in all cases but these two
Jun 6 2024
Similarly, if the action if a history view, will the page categories be known?
Jun 4 2024
About the conditional loading based on categories: If we edit a section (instead of the entire page) and the category wikicode is outside the section, will the gadget be loaded, or not?
Change #1036653 merged by jenkins-bot:
[mediawiki/extensions/Gadgets@REL1_41] SECURITY: Improve regular expression performance
Change #1036654 merged by jenkins-bot:
[mediawiki/extensions/Gadgets@REL1_40] SECURITY: Improve regular expression performance
Change #1036652 merged by jenkins-bot:
[mediawiki/extensions/Gadgets@REL1_42] SECURITY: Improve regular expression performance
Change #1036655 merged by jenkins-bot:
[mediawiki/extensions/Gadgets@REL1_39] SECURITY: Improve regular expression performance
Jun 2 2024
May 31 2024
This should already be possible. The gadget description messages which are used in preferences support full wikitext.
May 28 2024
Change #1036655 had a related patch set uploaded (by SBassett; author: SBassett):
[mediawiki/extensions/Gadgets@REL1_39] SECURITY: Improve regular expression performance
Change #1036654 had a related patch set uploaded (by SBassett; author: SBassett):
[mediawiki/extensions/Gadgets@REL1_40] SECURITY: Improve regular expression performance
Change #1036653 had a related patch set uploaded (by SBassett; author: SBassett):
[mediawiki/extensions/Gadgets@REL1_41] SECURITY: Improve regular expression performance
Change #1036652 had a related patch set uploaded (by SBassett; author: SBassett):
[mediawiki/extensions/Gadgets@REL1_42] SECURITY: Improve regular expression performance
May 27 2024
Change #1030565 merged by jenkins-bot:
[mediawiki/extensions/Gadgets@master] SECURITY: Improve regular expression performance
May 26 2024
In T357197#9833165, @TheDJ wrote:In T357197#9833164, @Xover wrote:You can't make that call with a broad brush like "all of MediaWiki" (or rather, you can only do so extremely conservatively), but when we're talking Gadgets we're inherently at a level of granularity where the community not only can, but is actually best situated to make calls like that.
A granularity that however runs inside the same execution pathways of mediawiki, and thus mixes in with all the other code. It is cool you want to do some redecorating, but we are living in the same house. If you poke a hole in the roof, the whole house has a leak, not just your room.
In T357197#9833165, @TheDJ wrote:Like I get the desire, but you also have to look at the impact of that desire for others.
In T357197#9833164, @Xover wrote:You can't make that call with a broad brush like "all of MediaWiki" (or rather, you can only do so extremely conservatively), but when we're talking Gadgets we're inherently at a level of granularity where the community not only can, but is actually best situated to make calls like that.
In T357197#9586503, @Nux wrote:[…]
May 23 2024
Big +1 for this I've now hit this issue on two important widely used gadget efforts and have had to resort to creating my own i18n solution or hardcoding strings in a certain language which is not ideal :/
May 22 2024
May 16 2024
@Majr: Removing task assignee as this open task has been assigned for more than two years - see the email sent to all task assignees on 2024-04-15.
Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome! :)
If this task has been resolved in the meantime, or should not be worked on by anybody ("declined"), please update its task status via "Add Action… 🡒 Change Status".
Also see https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator. Thanks!
@Jdlrobson: Removing task assignee as this open task has been assigned for more than two years - see the email sent to all task assignees on 2024-04-15.
Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome! :)
If this task has been resolved in the meantime, or should not be worked on by anybody ("declined"), please update its task status via "Add Action… 🡒 Change Status".
Also see https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator. Thanks!
@SD0001: Removing task assignee as this open task has been assigned for more than two years - see the email sent to all task assignees on 2024-04-15.
Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome! :)
If this task has been resolved in the meantime, or should not be worked on by anybody ("declined"), please update its task status via "Add Action… 🡒 Change Status".
Also see https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator. Thanks!
May 14 2024
Change #1030565 had a related patch set uploaded (by SBassett; author: SBassett):
[mediawiki/extensions/Gadgets@master] SECURITY: Improve regular expression performance
In T363773#9797030, @sbassett wrote:A basic patch implementing @Bawolff's new regexp from above:
01-T363773.patch1 KBDownload
I feel like this is likely low-risk to where it could just go through gerrit since, to exploit this on Wikimedia projects, one would need to first compromise an int-admin account in order to edit MediaWiki:Gadgets-definition.
In T363773#9788169, @R4356th wrote:In T363773#9783948, @mmartorana wrote:If anyone wants to write a patch with @Bawolff enhanced regex to address these issues, we would be pleased to review it and deploy it.
I believe we could move ahead with this, @Bawolff.
May 11 2024
Apologies for the late response.
May 9 2024
If anyone wants to write a patch with @Bawolff enhanced regex to address these issues, we would be pleased to review it and deploy it.
May 6 2024
May 4 2024
I was wondering today why on earth a gadget defined on MediaWiki:Gadgets-definition cannot be loaded using mw.loader.load(). This should have been documented on mediawiki.org; better late than never.
May 3 2024
Change #1014636 merged by jenkins-bot:
[mediawiki/extensions/Gadgets@master] Replace EditFilterMergedContent hook with ContentHandler override
I do wonder what the WMF's PCRE backtrack limit is, however.
In T363773#9762681, @Bawolff wrote:A better version that i think is equivalent is:
/^==+ *([^*:\s|]+)\s*(?<!=)==+\s*$/This is still vulnerable according to the redos checker (2nd order poly). However when i tried to actually test it, I wasn't able to really trigger a dos even when giving it 100's of mb of data.
May 2 2024
Ah, i guess i was wrong here.
Apr 30 2024
In T363773#9759292, @Bawolff wrote:I imagine you would need an input quite a bit bigger than $wgMaxArticleSize before third order polynomial became problematic
In T363773#9759292, @Bawolff wrote:I imagine you would need an input quite a bit bigger than $wgMaxArticleSize before third order polynomial became problematic
In T363773#9758168, @sbassett wrote:Just a note, recheck (which checks for more than problematic star heights, backtracking, etc.) came up with the following findings:
- (\r\n|\r|\n)+ - safe
- ^==+ *([^*:\s|]+?)\s*==+\s*$ - vulnerable, 3rd order polynomial
- ^\*+ *([a-zA-Z](?:[-_:.\w ]*[a-zA-Z0-9])?)(\s*\[.*?\])?\s*((\|[^|]*)+)\s*$ - safe
In T363773#9756003, @Bawolff wrote:Is this really a security issue? Only people with interface-admin rights can edit this page. I think someone trusted enough to decide what javascript to run for all users is also trusted enough not to try a ReDOS attack. Not to mention the mitigating factor of the PCRE backtrackling limit.
In T363773#9756017, @Bawolff wrote:First one has nothing after the repeated subexpression that can possibly not match to force backtracking
Just a note, recheck (which checks for more than problematic star heights, backtracking, etc.) came up with the following findings:
- (\r\n|\r|\n)+ - safe
- ^==+ *([^*:\s|]+?)\s*==+\s*$ - vulnerable, 3rd order polynomial
- ^\*+ *([a-zA-Z](?:[-_:.\w ]*[a-zA-Z0-9])?)(\s*\[.*?\])?\s*((\|[^|]*)+)\s*$ - safe
In T363773#9756013, @DannyS712 wrote:For (\r\n|\r|\n)+ how about [\r\n]+?
Actually, looking closer, I do not think any of these regexes are actually evil. It doesn't look like to me that any of them would have exponential backtrack behaviour (I'm not an expert on ReDOS and don't have super good intuition on this class of vulnerability, so i may be mistaken).
For (\r\n|\r|\n)+ how about [\r\n]+?
Is this really a security issue? Only people with interface-admin rights can edit this page. I think someone trusted enough to decide what javascript to run for all users is also trusted enough not to try a ReDOS attack. Not to mention the mitigating factor of the PCRE backtrackling limit.
Apr 29 2024
Apr 24 2024
I don't think there are hackathon-sized improvements to MediaWiki core specifically that would help here.
Apr 23 2024
How does this sound?
Some remarks:
- This should not be a separate Special:GadgetPreferences but part of Special:Preferences in Gadgets section, when entire usage of one particular tool can be toggled. If this tool is activated, the preferences GUI should appear immediately below (and vanish if toggled off).
- The JSON spec should be subpage like MediaWiki:Gadget-myTool/preferences.json, while site configuration might be MediaWiki:Gadget-myTool.json and implementation is at MediaWiki:Gadget-myTool.js
- Texts do need localization mechanism. A global root may contain English, French, Japanese and German, and on Commons users will expect their user language. Further translations need to be added easily by global collection of local languages.
Apr 22 2024
With MultiGadgetRepo, adoption will be gradual with users having full autonomy at the individual gadget level. This means adopting a JSON gadget is as easy as creating the appropiate page (JSON will have precedence over the entry from the legacy definition page). And switching back would involve deleting or moving said page, or changing its content model, so as to not be loaded.
This task isn't actionable because there is no Gadget Manager (yet) in the Gadgets extension. Closing in favour of T31398: Implement Gadget Manager, which tracks implementing it. Naturally, that new implementation will not use jQuery UI.
For those interested in implementing this, there is code for a Gadget Manager implementation already, and can be found in the RL2 branch of the mediawiki/extensions/Gadgets repo. This is from the 2011 prototype that @Catrope and myself worked on at the time.
Apr 18 2024
Thanks for that info. Perhaps we should turn this into a ticket about renaming requiresES6.
Now that 1) ES6 is the Grade A JavaScript requirement for MediaWiki and 2) the validator now supports ES6 (T75714), this means we no longer need the "requiresES6" flag for the gadgets extension, correct?
Apr 7 2024
Apr 6 2024
The proposed patch on Gerrit addresses precisely these problem - it introduces feature parity between gadgets and user scripts ("user gadgets"). All ResourceLoader features available to gadgets like loading dependencies, allowing multiple source pages, specifying peers for FOUC-free CSS loading, CommonJS module support, and conditional loading (based on namespaces, content models, skins, etc), would become available to 'user gadgets'.