PHP requires integer typehints to be written "int" and does not
allow "integer" as an alias. This changes type error messages to
match the actual type name and avoids confusing messages like
"must be of the type integer, integer given".
* Fixed bug #62523 (php crashes with segfault when exif_read_data called)
* Fixed the poor test case for #62523, which was a HTML document
Fixing #72819 had the side effect of fixing #62523 by supporting the format as seen in bug62523_1.phpt
* PHP-7.1:
Fix bug #73737 FPE when parsing a tag format
Fix bug #73773 - Seg fault when loading hostile phar
Fix bug #73825 - Heap out of bounds read on unserialize in finish_nested_data()
Fix bug #73768 - Memory corruption when loading hostile phar
Fix int overflows in phar (bug #73764)
* PHP-7.0:
Fix bug #73737 FPE when parsing a tag format
Fix bug #73773 - Seg fault when loading hostile phar
Fix bug #73825 - Heap out of bounds read on unserialize in finish_nested_data()
Fix bug #73768 - Memory corruption when loading hostile phar
Fix int overflows in phar (bug #73764)
* PHP-5.6:
Fix bug #73737 FPE when parsing a tag format
Fix bug #73773 - Seg fault when loading hostile phar
Fix bug #73825 - Heap out of bounds read on unserialize in finish_nested_data()
Fix bug #73768 - Memory corruption when loading hostile phar
Fix int overflows in phar (bug #73764)
Unlike the original patch, this does not return an unknown format in case an unsigned compatible type cannot be found (cases for SINGLE and DOUBLE removed), as these seems rare cases according to the inline comments.
Note, the test does not test if PHP is in debug mode, although the report originally states it only occurs there only.
The fix is based on a patch by hlt99 at blinkenshell dot org
This patch changes processing a little and causes some crafted tags to not be parsed and generate a warning.
This is a slight BC break from earlier versions, since it will no longer return the tags of that it was mismatching (see bug68799.phpt), namely the "WINXP" section and the "Author" tag is no longer returned due to this. Although this BC break is merely only for crafted tags, this can also have some real life effects on pictures re-saved from editors that can cause bad exif data writes, so lets keep it here.
Sony is a little more interesting, as it is have a large range of tags it support in different models. For now I have added all the tags found within the Exif.Sony1 namespace.
There are two factors for this bug fix:
- First of all, the maximum nesting level has been increased to 150 (previously 100), I'm not sure how much an impact this will have, but increasing this value also seems to resolve PHP bug #66443 (Corrupt EXIF header: maximum directory nesting level reached for some cameras.)
- Second, this adds support for most common Panasonic EXIF tags, again this list is based off the Exiv2 website
Note about Panasonic's format:
From what I could find, then the offset was always 12 bytes for such, the signature always had the 'P' capitalized, and the rest lower cased, followed by 3 NULL bytes
@Remi, can you review this? I'm gonna look into Sony (which is huge btw!) and your patch next
