This was spotted when running tests on Travis (PHP 7.3 nighly, trusty).
Two expressions inside preg_replace() contained non-escaped "-" inside [],
where this "-" meant an actual "-" character.
The warning is because "-" has special meaning inside [] ("a-z" for range),
and things like [\w-.] are considered "invalid range".
Solution is to escape "-" like this: [\w\-.]
Change-Id: I41cc217081f00f54d957b6d8052ee209412f5ff6
Uses new PHP 5.6 syntax like ...parameter unpacking and
calling anything looking like a callback to make the code more readable.
There are much more occurrences but this commit is intentionally limited
to an easily reviewable size.
In one occurrence, a simple conditional instead of trickery was much more readable.
This patch finishes all the easy stuf in the core, the remainder is either unobvious
or would result in smaller readability gains. It will be carefully dealt with in
further commits.
Change-Id: I79a16c48bfb98b75e5b99f2f6f4fa07b3ae02c5b
file_get_contents() started supporting a negative offset in 7.1+. But
we really just want to start with 0.
Also fix the order of arguments to assertSame() so that the expected
value is first.
Bug: T182366
Change-Id: I84c92652de5b51a43f6e2b58cd235d2889093453
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
Clean up use of @codingStandardsIgnore
- @codingStandardsIgnoreFile -> phpcs:ignoreFile
- @codingStandardsIgnoreLine -> phpcs:ignore
- @codingStandardsIgnoreStart -> phpcs:disable
- @codingStandardsIgnoreEnd -> phpcs:enable
For phpcs:disable always the necessary sniffs are provided.
Some start/end pairs are changed to line ignore
Change-Id: I92ef235849bcc349c69e53504e664a155dd162c8
* Remove some creation dates, they are not protected by GPL
* Remove duplicate @defgroup API
* Remove @ingroup from some @file doc comments on class files. It is not
useful to list class files alongside classes in the doxygen module menu.
Add @ingroup to some more class files that had @ingroup on their file,
that was probably the author's intent.
* In PackedOverlayImageGallery, use the file comment as a class comment
* Don't put @defgroup and @file in the same comment. @defgroup makes the
whole doc comment describe the group.
* Instead of putting AnsiTermColorer in two groups, use hierarchical
groups.
Change-Id: If54f6e0b2bc1ea6de42045885cf836ee67b8e961
Previously warnings about the sha1 of an uploaded file being
the same as an existing file were stripped if the existing
file was in local storage - this was to avoid duplicate
warnings if a file with the same name had already been found
and had the same content. Now the warning is only stripped
for local files with the same name as the uploaded file.
Bug: T180691
Change-Id: I455df30085c05320dca976b9f7f8fb711a083271
In some cases, the error messages have changed slightly, mostly because
of capitalisation & punctuation.
In a few other cases (mainly UploadStashNotLoggedInException), the content
has also slightly changed (removed mention of the __METHOD__ it occurred in)
Bug: T178291
Change-Id: I184067f2d7fe0a0a2df1114d2525fd9ab95b6c86
With the introduction of CommentStore, selects from various table
require certain joins or column aliases for proper operation. The
upcoming actor table change, and the suggested title table change, will
add more such requirements.
Change-Id: Ic8213bff74b8350b15cd271d0ef252e63e7e79bd
These methods also don't access any of the class
properties and could one day be factored out into
some file checking service.
This also means that individual checks can be used for
the attached task if made protected.
Bug: T163500
Change-Id: I7cf912507ee02c35b6a666d7ed48fcab001316d3
Only allow ENTITY declarations inside the doctype internal
subset. Do not allow parameter entities, recursive entity
references are entity values longer than 255 bytes, or
external entity references. Filter external doctype subset
to only allow the standard svg doctypes.
Recursive entities that are simple aliases are allowed
because people appear to use them on commons. Declaring
xmlns:xlink to have a #FIXED value to the xlink namespace
is allowed because GraphViz apparently does that so its
somewhat common.
This prevents someone bypassing filter by using default
attribute values in internal dtd subset. No browser loads
the external dtd subset that I could find, but whitelist
just to be safe anyways.
Issue reported by Cassiogomes11.
Bug: T151735
Change-Id: I7cb4690f759ad97e70e06e560978b6207d84c446
$this->nbytes does not exist and is never written to.
It is probably intended that this uses the local $nbytes.
Change-Id: I8e923a27625d04c81b2e272a597d40d59397851f
It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345"
except where it doesn't, so let's just standardise on the real numbers.
Change-Id: I6f59febaf8fc96e80f8cfc11f4356283f461142a
This change is similar to If9ce05045ada1e3f55e031639e4c4ebc2a216de8
Having verifyChunk inside doStashFile was annoying. We'd have to
catch the exception in UploadBase::tryStashFile in order to convert
it to a proper Status object instead of the generic one that is
currently built there.
I felt like UploadBase::tryStashFile shouldn't have to be aware of
this exception, so I moved that catch into a new
UploadFromChunks::tryStashFile.
It makes no sense to perform that check twice when running
tryStashFile, so I got rid of it in doStashFile. But that also
meant we had to add it to a few other (now deprecated) places calling
doStashFile... But they should be cleaned up at some point anyway.
This will make sure we get error output like this:
"code":"filetype-bad-ie-mime",
"key":"filetype-bad-ie-mime",
"params":["text/html"]
instead of:
"code":"stashfailed",
"key":"Cannot upload this file because Internet Explorer would detect it as \"text/html\", which is a disallowed and potentially dangerous file type.",
"params":[]
Bug: T32095
Change-Id: I2fa767656cb3a5b366210042b8b504dc10ddaf68
&$this triggers warnings in PHP 7.1. Simply renaming the variable before
passing it by reference avoids the warning, without breaking backwards
compatibility.
Bug: T153505
Change-Id: I78ea04a01ecce82294837e92c2a05b00ffb6e0f6
This code is gross, and my changes do not really make it better,
but it works more correctly more often.
Bug: T147720
Change-Id: If9ce05045ada1e3f55e031639e4c4ebc2a216de8
Inkscape mangles namespace definitions created by Adobe Illustrator
(apparently it can't parse custom entities or something, maybe just
in 'xmlns' attributes). These files are still valid SVG, and not
a security issue (although Illustrator probably won't like them),
so it's okay to allow them.
Added tests with some example files.
* buggynamespace-original.svg
File generated by Illustrator (edited by hand to reduce filesize).
Based on <https://commons.wikimedia.org/w/?curid=16495597>.
* buggynamespace-okay.svg
The original file, opened and saved in Inkscape (no other changes).
* buggynamespace-okay2.svg
The original file, opened and saved in Inkscape twice.
* buggynamespace-bad.svg
The original file, edited by hand to remove custom entities.
This is not valid XML and should be rejected (although it's valid
when parsed as HTML, and some image viewers might display it).
* buggynamespace-evilhtml.svg
An SVG file using an entity declared namespace for a namespace
we want to ban. Based on buggynamespace-original.svg.
Bug: T144827
Change-Id: I0eb9766cab86a58d729f10033c64f57d2076d917
