XmlTypeCheck's use of xml_parse for filtering SVG's sometimes left xml
entities unexpanded, which can lead to false-negatives when the
callback was used for filtering. Update XmlTypeCheck to use XMLReader
instead, tell the library to fully expand entities, and rely on the
library to error out if it encounters XML that is likely to cause a DoS
if parsed.
Bug: T88310
Change-Id: I77c77a2d6d22f549e7ef969811f7edd77a45dbba
The former is by far the most common.
Skipped:
* resources/lib/jquery.ui/jquery.ui.datepicker.js
* resources/src/mediawiki.special/mediawiki.special.upload.js
Change-Id: I73c93797e745128ba703e4865080c36784caa474
* Filter <style> elements
* Normalize style elements and attributes before filtering
* Add checks for attributes that contain css
* Add unit tests for html5sec and reported bugs
Bug:69008
Change-Id: I732eece710f1bfaaeea1e5de541fcd4cfb375de7
These are classes that provide facilities for use by any caller, are
independent of user interface, and have a limited set of dependencies on
the rest of MediaWiki. See the README file for a more precise
definition.
These classes cannot go in includes/libs because of a dependency on the
MediaWiki framework, such as wfDebug() or MWException, but they are
otherwise similar. I thought it would be useful to put them in their own
directory, to make them more discoverable, and as part of a general
program of reducing clutter in the base includes/ directory.
I've probably missed a few classes which could be included here, but the
following classes were considered and were rejected for now:
* Fallback: single caller only
* GitInfo: getViewers() has inappropriate dependencies
* HttpFunctions: depends on configuration, $wgTitle
* PoolCounter: depends on configuration
* CacheHelper: depends on IContextSource, wfMemc()
Also moved a couple of classes into libs/ instead, where that seemed to
be more appropriate.
Change-Id: I274cff805b7d694b728a89b764a049cd62d320fe
