Taint check checks for possible security issues by tracking html
escaping and more by using phan.
This slows done the phan-job a bit and requires more ram
Keep the DoubleEscaped issues out to make reviewer easier
Adds suppression for false positives
Adds taint-annotation to help taint-check
Removes suppression for code phan now understand better by the tracking
of keys in taint-check
Fix some small issues by adding int cast or htmlspecialchars calls
Bug: T216348
Bug: T268920
Change-Id: I849ac4f120fd15b483e8939d4db45c98dc351259
Deprecate the interfaces in MimeAnalyzer that return lists as
space-separated strings in favor of replacement methods that return
arrays.
Deprecated:
- ::getExtensionsForType( $mime ) : string|null
- ::getTypesForExtension( $ext ) : string|null
- ::guessTypesForExtension( $ext ) : string|null
Added:
- ::getExtensionsFromMimeType( $mime ) : string[]
- ::getMimeTypesFromExtension( $ext ) : string[]
- ::getExtensionFromMimeTypeOrNull( $mime ) : string|null
- ::getMimeTypeFromExtensionOrNull( $ext ) : string|null
- "From" is clearer than "For"[1] and is neatly symmetrical with "To"
(viz. ::mExtToMime and ::mMimeToExt).
- "MimeType" is less ambiguous than "Type", which in this context may
refer either to media type or MIME type.
- "{..}OrNull" is better because it helps users remember to handle a null
return value. Putting the "OrNull" at the end (getXFromYOrNull) is
better than putting it in the middle (getXOrNullFromY) because it's
harder to ignore that way, at the cost of a very slight grammatical
ambiguity.
Usage in Core will updated in a separate commit.
Lastly, this change prepares for the deprecation of mutating the public
'mExtToMime' attribute as a means of registering extensions. It will be
formally deprecated in a follow-up change.
[1]: Positive signal: https://developer.android.com/reference/android/webkit/MimeTypeMap#getMimeTypeFromExtension(java.lang.String)
Bug: T252228
Change-Id: I93bd71ec18492722f05c66e0a2945d93281c3100
Currently, MimeAnalyzer builds the internal mappings of MIME types <=> file
extensions by concatenating several string buffers in mime.type format into a
giant string, and then parsing it. The mapping of MIME types to internal
media types is built up in a similar way, except we use a dubious homegrown
format with undocumented conventions. It's a mess, and an expensive one --
~1.5% of api.php CPU time on the WMF cluster is spent building these buffers
and parsing them. Converting the mappings to PHP associative arrays makes
them much cheaper to load and easier to maintain.
Doing this without breaking compatibility with existing behaviors requires
some delicate footwork. The current mime.types buffer is made up of the
following fragments, in order:
1) MimeAnalyzer::$wellKnownTypes
2) If $wgMimeTypeFile == 'includes/mime.types' (sic!):
the contents of includes/libs/mime/mime.types.
If $wgMimeTypeFile is another file path (e.g., '/etc/mime.types'):
the contents of that file.
If !wg$MimeTypeFile, this fragment is blank.
3) MimeAnalyzer::$extraTypes (populated by extensions via hook).
The mime.info buffer is built up in the exact same way, except it's
MimeAnalyzer::$wellKnownInfo, $wgMimeInfoFile, and MimeAnalyzer::$extraInfo.
What this means in effect is that some built-in MediaWiki MIME mappings are
"baked in" (anything in MimeAnalyzer::$wellKnown*), and others can be
overridden (anything in includes/libs/mime/mime.*).
To avoid breaking backward compatibility, we have to preserve the
distinction. Thus this change has two MIME mappings, encapsulated in two
classes: 'MimeMapMinimal', which contains just the baked-in mappings, and
'MimeMap' which contains both the baked-in and overridable mappings. We also
have to keep the code for parsing mime.types and the ad-hoc mime.info format,
at least for now.
In a FUTURE change (i.e., not here), I think we can:
* Deprecate $wgMimeTypeFile in favor of a new config var,
$wgExtraMimeTypeFile. $wgMimeTypeFile is evil because if you are using to
add support for additional MIME types, you can end up unwittingly dropping
support for other types that exist in MediaWiki's mime.types but not your
file. The new $wgExtraMimeTypeFile would only be used to add new MIME
mappings on top of the standard MimeMappings, which was probably the
original intent for $wgMimeTypeFile.
* Deprecate $wgMimeInfoFile. I don't think we need to provide a replacement,
because extensions can use the hook, and I doubt anyone is using the config
var. But if we wanted to provide an alternative, we could have a
$wgExtraMimeInfoMap that has an array of extra mappings.
* Deprecate MimeAnalyzer::addExtraTypes and MimeAnalyzer::addExtraInfo, and
provide alternative interfaces that take structured input instead of string
blobs.
I tested this by dumping the internal state of MimeAnalyzer before and after
this CL using the script in Ib856a69fe, using both default and custom values
for $wgMimeInfo(File|Type).
Bug: T252228
Change-Id: I9b2979d3c9c0dee96bb19e0290f680724e718891
* Remove code paths that were unreachable for me.
* Remove display_errors/error_reporting overrides.
These can be set as-needed from LocalSettings.php if desired,
and similar (but slightly different) settings are already set
by DevelopmentSettings.php.
* Default to text/plain instead of letting PHP handle it.
This makes makes the result more predictable, instead of varying
by PHP version and underlying OS behaviour. Anything we want to
support is already in our 'mime.types' file, and ours is a
superset of PHP's anyway.
Change-Id: I46608ebd8e225642cfeb804ec32739c2fcbd4d25
When using the PHP built-in webserver with maintenance/dev/start.sh,
requests made to regular files do show in the console output but
requests to .php files do not log anything in the console. It is a bit
annoying since one is left wondering whether the requests are actually
honored.
The reason is the request router maintenance/dev/includes/router.php
does a require of the PHP file and abort the router (return true). That
causes the built-in php server to not produce the access log requests.
Based on the comment note, some earlier PHP version had POST data
stripped preventing login. The related upstream bug is
https://bugs.php.net/bug.php?id=60159:
"Router returns false, but POST is not passed to requested resource"
750eac7e41 introduced the workaround on Nov 24th 2011. PHP 5.4.0 got
released in March 2012 and refers to that bug. The development of our
router thus must have used a development/beta version of PHP 5.4.
Since the fix made it to the PHP final release, there is no need for
workaround anymore.
Bug: T190503
Change-Id: Ia8c4f1610ea0ef5b04ea30d6e91199b8e597065b
Use HTTPS instead of HTTP where the HTTP link is a redirect to the HTTPS link.
Also update some defect links.
Change-Id: Ic3a5eac910d098ed5c2a21e9f47c9b6ee06b2643
* The later resides in /libs with related files.
* Explose MimeAnalyzer as a service.
* Keep MimeMagic::singleton() as a b/c alias.
* MimeMagic::applyDefaultConfig() will bootstrap the service
with all of the old config, extension hook handler, and
detector command shell-out behavior.
Change-Id: Ie2695a52e7a3bcfda9f7fa83659a9ff31b372bc3
Follows-up I1343872de7, Ia533aedf63 and I2df2f80b81.
Also updated usage in text in documentation and the
installer LocalSettingsGenerator.
Most of them were handled by this regex:
- find: (require|include|require_once|include_once)\s*\(\s*(.+?)\s*\)\s*;$
- replace: $1 $2;
Change-Id: I6b38aad9a5149c9c43ce18bd8edbab14b8ce43fa
The PHP_SAPI constant has been available since PHP 4.2.0. It's more
concise to use the constant and has less overhead than a function call.
Furthermore, PHP_SAPI rhymes with "happy", whereas "php_sapi_name"
rhymes with "lame". QED, etc.
Change-Id: Ie8c121cb8fcef50536af8d3f66723b458f0bf9af
- Update maintenance/dev/ to install php inside ~/.mediawiki/php instead of ~/.mwphp
- Tweak README a bit
- Move the router.php into an includes along with two helper .sh files to cut out some of the repetition
2011-12-11 19:45:15 +00:00
Renamed from maintenance/dev/router.php (Browse further)
