This improvement was done for libgd 2.1.0[1], and the erroneous
calculation has been fixed as of libgd 2.2.0[2].
While we're at it we also add the overflow checks of external libgd;
these are not really necessary, since `.sx * .sy` overflow was already
prevented when the image has been created, and since we're using
`safe_emalloc()` the `struct seg` overflow is also prevented. It
should be noted that `overflow2()` prevents `int` overflow, while
`safe_emalloc()` prevents `size_t` overflow, so the former is more
restrictive. For parity with external libgd, this still appears to be
a good thing.
[1] <https://github.com/libgd/libgd/commit/86a5debede97ded92d644c3e06964c299e1e0810>
[2] <https://github.com/libgd/libgd/commit/e87ec88e1c4db664baf2c42e7fccf3f9dc53f0a6>
We apply the same fix that has been applied to external libgd at least
as of 2.0.29.
To avoid issues regarding minor FreeType rendering differences, the
test case does not compare against an image, but rather checks that all
pixels outside the clipping rect have the background color.
Closes GH-17374.
This is porting the relevant part of a previous upstream commit[1] to
align the behavior of our bundled libgd with upstream. It should be
noted that this only works if the image actually has a transparent
color.
[1] <https://github.com/libgd/libgd/commit/4770e2b2d50c71e60cb073f6bc2e9bc82ec978f7>
Closes GH-17351.
This is not a functional change, but rather a performance improvement,
to avoid unnecessary calls of `gdImageSetPixel()` which would be no-ops
due to positions outside of the clipping bounds.
That bug has been potentially exploitable[1], but the GD extension was
not affected by that, because `gdImageBmpPtr()` is never called. Still
it seems to be reasonable to port the fix; if only to keep bundled and
external libgd synced.
[1] <https://github.com/advisories/GHSA-hc3p-jvff-jfw5>
The issue that BMP RLE occasionally swallowed some pixels[1] had been
fixed long ago in libgd, but apparently it has been overlooked to port
it to our bundled libgd.
We also introduce the test helper `test_image_equals_image()` which
compares in-memory images for equality.
[1] <https://github.com/libgd/libgd/issues/276>
Closes GH-17250.
Prior to libavif 1.1.0, `avifAlloc()` was infallible (it called
`abort()` on OOM conditions); thus, several API functions which used
`avifAlloc()` did not report failure. That changed as of libavif
1.0.0[1], so checking and handling failure conditions can now be done.
However, due to `avifAlloc()` being fallible as of libavif 1.1.0, this
error checking and handling is mandatory to avoid more serious issues.
[1] <https://github.com/AOMediaCodec/libavif/blob/eb02b2ec52df5c0f50b71fbc51321c5ce435aaca/CHANGELOG.md?plain=1#L273-L281>
Closes GH-16434.
Note that this is not actually security related[1], but still a
reasonable sanity check.
"If a function be advertised to return an error code in the event of
difficulties, thou shalt check for that code, yea, even though the
checks triple the size of thy code and produce aches in thy typing
fingers, for if thou thinkest it cannot happen to me, the gods shall
surely punish thee for thy arrogance." – Henry Spencer
[1] <https://github.com/libgd/libgd/issues/697#issuecomment-2369613187>
Ben Ramsey