The following sniffs are failing and were disabled:
* MediaWiki.Commenting.MissingCovers.MissingCovers
Change-Id: I07b2cf945f44fd5532812a712f7dd40d2f208be2
While there is currently no demonstrated vulnerability, this provides
additional hardening against SPECTRE-like attacks, and any potential
future timing attacks.
Bug: T184156
Change-Id: I2b5cc177bded1a9b5600d77116e67817841204be
When passing an array from PHP to Lua, stringify integer array keys
beyond the range a lua_Number can represent.
When passing a table from Lua to PHP,
* Avoid exponential encoding for integer keys beyond 1e14, so Zend PHP
will interpret them as integers.
* Always encode integer keys as integers, so HHVM will interpret them as
integers.
* Detect collisions, e.g. { [0] = 'foo', ["0"] = 'bar' }
Bug: T186240
Change-Id: I078068ed57df078248a307608381614bdfc70801
For integers from Lua to PHP, make sure they won't use exponential
notation that will confuse unserialize(), and pass the integer size from
PHP so Lua can know which numbers are representable as integers.
For doubles in both directions, increase the precision to avoid
truncation of the least significant bits.
Change-Id: Icfaff71cab0ee1aac04acf752d108049b5569380
When we're making a call from Lua to PHP, serialization errors should be
propagated to whatever in Lua made the call. That works fine.
But when we're returning data in response to a call from PHP, if there's
a serialization error we need to catch it and tell PHP about it.
Otherwise PHP just gets a useless "the interpreter exited".
Change-Id: Iaac498fa2e486631d38e2366977b360140756519
This extension requires 1.31 (it follows the release branches compatibility
policy), so we can remove a lot of legacy checks and code.
Change-Id: Ieb42073010caffb1f6811d3a2f629aa60c1d2034
The two lualib/ustring generation scripts run independently of MediaWiki, so
the new wfIsCLI() isn't usable there.
Bug: T184043
Change-Id: I217657d12e16a7b76dc814be5fed03540c461e7c
Before this, tools like Phan and others read
`Scribunto_LuaLibraryBase::register()` returns `\Lua` type
from the document comment,
but it actually returns `array` type since the implementation
of this function should returns the value of
`Scribunto_LuaEngine::registerInterface()` which returns
`array` type.
Change-Id: I25beea963444b715bed7b2890475c0c812949520
PHP 7.2 made the questionable decision to raise a warning for
count( null ). So test for null explicitly before calling count in the
one place where null is expected.
Bug: T181891
Change-Id: I94146c14b63e32ad1e9f2ab9de9ebc403b251102
The core {{urlencode:}} parser function doesn't encode various
characters in WIKI mode that it does in other modes. mw.uri.encode
should match that.
Bug: T174239
Change-Id: I2be0811cf39c02c5c0ad3433e4b0ef9030350e24
The following sniffs are failing and were disabled:
* MediaWiki.Commenting.FunctionComment.MissingDocumentationProtected
* MediaWiki.Commenting.FunctionComment.MissingDocumentationPublic
* MediaWiki.Commenting.FunctionComment.MissingParamComment
* MediaWiki.Commenting.FunctionComment.MissingParamName
* MediaWiki.Commenting.FunctionComment.MissingParamTag
* MediaWiki.Commenting.FunctionComment.MissingReturn
* MediaWiki.Commenting.FunctionComment.ParamNameNoMatch
* MediaWiki.Commenting.FunctionComment.WrongStyle
The following sniffs now pass and were enabled:
* MediaWiki.Commenting.FunctionComment
* MediaWiki.Usage.ReferenceThis.Found
Change-Id: I1074884ab6810dd082b1baebb25d02b997424818
This makes it easier for people to use luasandbox and brings it in line
with how we currently take advantage of other PHP extensions if they're
available (e.g. wikidiff2). People can still explicitly use
luastandalone if they want to.
Bug: T128144
Change-Id: I585019be4dfeb0e2614d91dc3fb7eac0a3bd4bab
Make the language cache size configurable, and increase the default from
20 to 30. It needs to be fairly small on default installations, but can
be essentially unlimited if $wgLocalisationCacheConf['manualRecache'] is
true.
Bug: T85461
Change-Id: Idb17691b30b0d2565a1624e5159df7d9b795764d
I252ec046 noticeably broke things by adding a dependency on the pcntl
functions, which tend not to be present under Apache.
It also subtly broke exit handling by using proc_close()'s return value,
which PHP mangles in such a way that we can't tell the difference
between an actual XCPU kill and exit( SIGXCPU ). This one wasn't noticed
because the pcntl functions interpret everything proc_close() is going
to return as a signal kill and we didn't test the 'exited' code path.
I'm not sure what was going on in I57cdf8aa since it provides no details
about what it was trying to fix, but that would have broken signal
handling in the other way: Ibf5f4656 worked because proc_open() on Linux
executes the command by passing it to /bin/sh -c, and that shell is
going to turn any signal that kills Lua (e.g. the SIGXCPU) into an exit
status of 128+signum.
To avoid proc_close()'s broken return value while also avoiding the
race, we can loop on proc_get_status() until $status['running'] is
false.
To have signals that kill Lua actually be interpreted as signals, we
have two options: add an "exec" in front of the command so proc_open()'s
/bin/sh -c is execed away, or detect shell-style signal reporting and
convert it. We may as well do both.
Bug: T128048
Change-Id: I8a62e1660fe1694e9ba5de77d01960c1ab4580aa
normalization-data.lua is updated to Unicode 6.3.0.
upper.lua and lower.lua are updated to match HHVM 3.12.1's mb_strtoupper
and mb_strtolower. I don't know what version of Unicode that might be,
but it seems old.
Bug: T86096
Change-Id: I1a0c8be2756f86db5f36dd67319a1f79aea98b3e
https://www.mediawiki.org/wiki/Extension:Scribunto says that master
requires 1.25+, so let's remove checks for stuff that was added before
that.
* PPFrame::getTTL() was in 1.24.
* PPFrame::setTTL() was in 1.24.
* PPFrame::isVolatile() was in 1.24.
* Parser::fetchCurrentRevisionOfTitle() was in 1.24.
* ObjectCache::getLocalServerInstance() was added in 1.27, so restore the call to ObjectCache::newAccelerator() as BC.
This also removes BC with the php-luasandbox extension older than 1.6, which
was released before MediaWiki 1.22.
Bug: T148012
Change-Id: I36e37f3b65d0f167e1d28b00e0842d9721feee31
An empty pattern isn't "safe" since it could match in between the
bytes of a UTF-8 character.
Also, it turns out there's a bug in PHP <5.6.9 preg_replace() that we
need to work around too.
Change-Id: I282e5909e4663461d60c5386693db182de2fd44c
Provides a simple wrapper for PHP's hash() and
hash_algos() functions.
I will add docs to the Lua reference manual once
this is merged.
Bug: T142585
Change-Id: I6697463974a175e99f9b77428a1085247165ebc9
For the PHP implementation, return the codepoints as a table instead of
multiple return values that get table-ified in Lua, to avoid hitting
too-many-values stack limits.
For the pure-Lua version, inline most of ustring.codepoint instead of
calling it to avoid what's effectively "{ unpack( stuff ) }".
Bug: T118687
Change-Id: I105f388cc23ab55d4124739700ef89d5354b7dbc
mw.ustring is really really slow. I've discovered that in a lot of modules
on enwiki, upwards of 2/3 of the total runtime gets used when mw.html
calls mw.ustring.gsub. This change checks whether any Unicode characters
are present, and if not, calls string.gsub instead.
Change-Id: Ia50061584be3901ae7428354c449236225c318db
Core strip markers were changed in T110143 to include characters that
are normally encoded in attributes, however we want to pass them through
here so they can be unstripped correctly in the output wikitext.
This fix makes "Strip markers in CSS" parser test pass again.
Bug: T110143
Bug: T135961
Change-Id: I1353931a53c668d8a453dfa2300a99f59fdb01c5
The following continue to be ignored:
* Generic.Arrays.DisallowLongArraySyntax.Found, because I'm not sure
Scribunto is ready to abandon old version support in master.
* MediaWiki.ControlStructures.AssignmentInControlStructures.AssignmentInControlStructures,
because it's overly strict for its purpose.
Squiz.Classes.ValidClassName.NotCamelCaps isn't ignored globally, we
just ignore it explicitly every place it's needed.
Change-Id: I307668da6ef7b3e23da19b1fd1e08914239b99b3
Such a configuration is completely broken, but it's easy enough to
detect and avoid here.
Bug: T131910
Change-Id: I0bf108ec191a59f5506c0cdab00f3e5e68158ed5
This also makes some updates to make-normalization-table.php to handle
the move of UtfNormal to a separate library.
Bug: T126427
Change-Id: Id4985c3ca441cf92f08ba1f1af85c762ba43d7d2
