| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This removes the default build of an undocumented feature to disable
Adler32 checksums on those systems where it was the default.
The PR is motived by github #187 however it fixes a much more general
problem (#187 is limited to an issue where libpng "crashes" on some
manufacturer systems). The fix is based on a suggestion by @sgowdev who
is the originator of the issue.
When libpng disables the checking of Adler32 checksums it does so by an
undocumented and therefore possibly unsupported call to a zlib function
which does not exist in some versions of zlib.
Fortunately libpng only does this if the caller of libpng explicitly
asks for it to happen. Unfortunately the call to the undocumented
function is still in the compiled and built libpng and this means that
on some systems (as identified in #187) libpng can fail to load or maybe
even crash.
The libpng authors are currently unaware of any program or system that
uses this feature and none has been identified by the contributors to
In this fix an option is added to *enable* the code so that by default
the code is *disabled* - this is a simple generalization of the
suggestion by @sgowdev.
BENEFITS: the problem is eliminated, users of the functionality, if any,
are idenfified, the functionality can be implemented correctly in the
future or it can be removed. Hardly anyone complains.
COSTS: someone will complain that they have to enable an option in a
libpng build to use a feature that never worked consistently in the
first place.
This patch has been tested both with the option enabled and with it
disabled via pngusr.dfa. Tests, checks pass with cmake and configure,
make distcheck passes on configure.
Reported-by: Stephen Gowen <dev.sgowen@gmail.com>
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
|
|
Import Chromium commit
https://chromium.googlesource.com/chromium/src/+/e87a02987101e2dbe319a4aba6b52470f7624b4a
Add the author to the list of libpng contributing authors.
Portions from the original commit message follow:
***
A recent change to libpng [1] (included in Chromium with the recent
libpng update [2]) turns chunks that are bigger than
PNG_USER_CHUNK_MALLOC_MAX into failures. Although this matches the
intent of PNG_USER_CHUNK_MALLOC_MAX, it also causes images which used to
be viewable in Chromium to fail. Changing to a benign error allows us to
display these images once again. Though it means we do allow libpng to
allocate more than PNG_USER_CHUNK_MALLOC_MAX, it matches the behavior
prior to [2] (when we were using 1.6.22), and it does not regress
crbug.com/117369
[1] https://github.com/glennrp/libpng/commit/347538efbdc21b8df684ebd92d37400b3ce85d55
[2] https://chromium.googlesource.com/chromium/src/+/f82653a473f8de5fc86d0f2ecc75f6237e61946b
***
Bug: https://bugs.chromium.org/p/chromium/issues/detail?id=827754
Co-authored-by: Leon Scroggins III <scroggo@google.com>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
|
|
The check should fail if the EXIF byte-order header doesn't start with
a correct character, or if the two heading characters aren't identical.
Rewrite the check to make the code logic easier to follow.
|
|
The hIST chunks, used for storing image histograms, contain arrays of
16-bit unsigned integers, and the chunk size is expected to be an even
number. Raise a png_chunk_benign_error() if a hIST chunk fails to meet
this expectation.
Reported-by: Eugene Kliuchnikov <eustas@google.com>
|
|
The following pointer subtraction was unnecessary:
((const char*)(ptr)-(const char*)0)
In order to avoid further warnings about casting a wide pointer type
to a narrower integer type, we cast the pointer to the target integer
type through (size_t).
Also fix a comment and reformat the surrounding code.
|
|
|
|
|
|
Problem description:
Imagine a bitstream with an eXIf data segment that has invalid CRC.
If png_crc_finish() fails at line 2090, info_ptr->eXIf_buf is not freed
(despite the free_me setting at line 2062) because png_free_data() is
not called. png_read_info() is actually looping several time over the
png_eXIf chunk, calling png_handle_eXIf() several time in a row without
freeing the buffer.
This patch fixes the problem by leaving info_ptr's content in a clean
state in case of failure, as it is done at line 2084.
|
|
As per the const correctness rules, top-level const-ness of data
in automatic scopes does not propagate outside of these scopes
(unlike const-ness at lower levels, such as pointers to const data).
Previously, const was used liberally, but inconsistently across the
libpng codebase. Using const wherever applicable is not incorrect.
However, _consistent_ use of const is difficult to maintain in such
conditions.
In conclusion, we shall continue to use const only where doing so is
strictly necessary:
1. If a function guarantees that it will not modify an argument
passed by pointer, the corresponding function parameter should be
a pointer-to-const (const T *).
2. Static data should not be modified, therefore it should be const.
Reference:
Google C++ Style Guide
https://google.github.io/styleguide/cppguide.html#Use_of_const
|
|
In v1.6.0, compiler support for const became a requirement.
It should be used consistently. To maintain backwards compatibility,
PNG_CONST is still maintained in deprecated form.
|
|
This information is maintained by the version control system.
|
|
|
|
(Bug report by Thuan Pham, SourceForge issue #278)
|
|
In v1.6.0, size_t became a required type. It should be used
consistently. To maintain backwards compatibility, png_size_t
is still maintained in deprecated form.
|
|
|
|
Some are user facing. Some are in actual code. Most are in source comments. Also, please double check the changes in contrib/tools/pngfix.c
|
|
|
|
in attempt to stop an oss-fuzz "use of ininitialized value" issue
|
|
|
|
|
|
|
|
|
|
|
|
issue #180).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
deflate buffer for each row (Bug report by Andrew Church).
|
|
|
|
|
|
|
|
|
|
|
|
with "II" or "MM".
|
|
|
|
|
|
to account for the minimum 'deflate' stream.
|
|
|
|
issue.
|
|
|
|
|
|
|
|
function (Suggested by Max Stepin).
|
|
|
