It have been so annoying to check the commit diff on GitLab and
noticing that it is widely different from the one on the IDE.
After all, there is a reason for the Coding Style prohibiting tabs...
This was tested with both in-house MacPorts, in-house HomeBrew and
legacy CircleCI builds and I confirmed it works (it is needed only
by the in-house MacPorts builds).
Resolves#16076
As reported by chamal, it is possible to craft a
Jeff's Image Format image with header values that
are larger than the file size. This can lead to buffer
overflows when loading the data. This patch adds
bounding checks based on the size of the stream.
Resolves#16075
As noted by chamal, it is possible to cause a buffer overflow
in a crafted SFW file. This patch adds bounds checks to prevent
this from occurring.
See: 21895406db
Due to gexiv2 rebuilding it now links to exiv2 0.28.8 released recently.
As a result, gimp-console started to fail with Windows error 3221226505 at
splash image generation, because exiv2 from msys2 don't have our workaround.
Let's fix by bumping our custom build so gexiv2 can find it properly.
Resolves#16058
Per mzfr's observations, this patch adds more
safeguards to PVR import. Memory for data and pixels
is allocated and checked rather than using arrays.
Twiddled patterns are increased to 2048 and we
verify the dimensions are in that range before trying
to access. If users share an image that is larger than
that, we can increase this limit further.
Resolves#16056
Per mzfr, we should check if the cursor exceeds the
icon total size in icns_slurp () (per OSX icons) as we
do already in icns_decompress ().
Additionally, we were not deleting the temp_image created
to load each icon, and in fact we were making an unnecessary
blank temp_image before receiving the one from the PNG &
JPEG2000 procedures. This patch fixes both problems.
Per mzfr, we should dynamically allocate memory
for the PAA plug-in pixel data rather than rely on the image
being small enough for an array to store its information.
Resolves#16052
Per mzfr, the pixel array for 4bpp TIM textures needs to
be allocated twice as large since each byte in the file
stores two pixel indexes when opened.
Resolves#16051
As reported by mzfr, it is possible to crash the FITS plug-in
if a large enough image is read in. This patch implements their
suggestions of using g_try_malloc () over malloc () (and checking
if it returns NULL), as well as verifying the width & height are
within GIMP's image range.
Resolves#5553
As noted by Massimo, in the Sparkle plug-in there is an
extra gegl_buffer_iterator_add () that is not used in the following
gegl_buffer_iterator_next (iter) loop. Since this adds dest_buffer
which is also written to in the loop in the fspike () functions,
it can cause data to be overwritten. This patch removes the
unneeded extra function call.
While it's possible to set mnemonics on GimpResourceChooser
properties (brushes, gradients, palettes, etc), the accelerator
itself wouldn't work because the label wasn't connected to the
button widget.
The buttons are created externally and connected in
_gimp_resource_chooser_set_clickable (). This patch adds a call
to gtk_label_set_mnemonic_widget () if there is a label, so that
pressing the accelerator key on the label triggers the button
click function.
My use case was loading a 0-bytes swatches palette. This would crash
GIMP. And so would likely a zip archive suffixed .swatches with no .json
file in it, or a corrupted archive which would return ARCHIVE_FATAL when
attempting to read entries…
This patch fixes these edge cases. It also better handle the various
return values of libarchive. E.g. we should not abandon reading when we
get ARCHIVE_RETRY; and ARCHIVE_WARN is also a success case (despite
having some warning message).
Finally I break from the archive reading loop at the first JSON file, so
that we don't leak memory if there are several JSON file. It does raise
the question if this palette format allows such use case (several
palettes in a single .swatches archive).
The sample in the description of !2613 was failing to load with a bunch
of criticals. That was because when profiles == NULL, we would call
json_reader_end_member() while we never called the associated
json_reader_read_member(). Inverting the order of tests fix this.
