More safety checks for detecting broken xcf files, also based on examining
issue #8230.

After reading an offset where layer, channel, etc. data is stored, we
add a check to make sure that offset is not before where we read the
offset value. Because the data is always written after the offset that
points to it.

(cherry picked from commit a8428692)

Improvements in loading broken xcf files, based on examining issue #8230.
Besides checking for a minimum width and height, GIMP also has a maximum
size we can and should check.

In the case of the image itself, we change invalid dimensions to a size of
1 in hope that the individual layers etc will have the correct size.
For layer, we will also try to go on, but for channel and layer mask, we
will give up.

(cherry picked from commit 24c962b9)

GIMP could crash if the information regarding old path properties read
from XCF was incorrect. It did not check if xcf_old_path succeeded and
kept trying to load more paths even if the last one failed to load.

Instead we now stop loading paths as soon as that function fails.
In case we have a failure here we also try to skip to the next property
based on the size of the path property, in hopes that the only problem
was this property.

(cherry picked from commit 4f99f1fc)

GIMP stopped trying to read the XCF as soon as an invalid parasite was
encountered. However, in this specific case only the parasite data is
invalid, while the rest of the image is not corrupt.

Instead of terminating when we see a corrupt parasite, we skip to the
offset after the parasite. This may still be corrupt, but we can handle
that correctly, see e.g. the XCF in bugzilla issue 685086, which was
the reason of some of the previous changes.

Additionally:
- We add some logging to make it easier to handle future issues in this
  area.
- We add tests for a NULL parasite name, and for reading a different
  amount of parasite data than we expected. In both cases we return
  NULL instead of a parasite.

(cherry picked from commit 5b39bc96)

XMP metadata saved by GIMP 2.8.x or earlier can have duplicate tags
making the XMP data invalid. There's not much we can do without a
whole lot of processing and complicated code and even then no
guarantee we would catch everything.

Instead let's just try to improve the message to the user so they
will be more likely to understand what's going on.

(cherry picked from commit 6df6332f)

In xcf_load_image(), suspend size updates for layer groups before
adding their sublayers, to avoid unnecessary intermediary size
updates.  Resume size updates in reverse order, so that nested
groups are updated before their ancestors, after all layers have
been loaded.

(cherry picked from commit 63df5602)

When dropping a corrupted layer while loading an XCF, make sure to
clear the corresponding XcfInfo fields that point to it, so that
it's not erroneously used later, as we now continue loading the
image even after corrupted layers are encountered.

See, for example, issue #4643, for a corrputed XCF file affected by
this.

(cherry picked from commit d53e701d)

Whereas normal layers of dimension 0x0 are definitely broken, group and
text layers depend on their contents, which will be able to resize the
layer appropriately and fix whatever rendering. This commit allows to
salvage such layers, hence make XCF loading even more resistant to
certain form of file corruption.

This commit (and the previous one) are not theoretical but the result of
discovering some old corrupted file, with an empty group of size 0x0
(saved by GIMP itself, because of some old bug). Rather than destroying
these layer groups, this just allows us to reopen them without any kind
of loss!

(cherry picked from commit 06be0746)

If the problem occurs at one of the first layer, we may end up loading
nearly nothing even though there may be a whole lot of other data in
good state. So instead keep track of the number of failed layer and
channel loading to still display an error popup at the end, because we
still need to alert the user something went wrong. Yet damages are
limited.

Also make sure that layer paths are fixed when some layers could not be
loaded, hence stored paths end up wrong.

(cherry picked from commit 2045fdd2)

Add "gboolean push_undo" parameters to gimp_image_parasite_attach()
and _detach() and use the API also from undo, instead of implementing
attaching/removing manually and forgetting about the signals.

Fixes updating of the image properties color profile page.

(cherry picked from commit 710cfc1f)

Fix xcf-load.c to correct out-of-range item offsets (simply set them
to 0), so XCF files that are broken this way can still be recovered.

This doesn't fix the original bug, just recovering the crash images.

(cherry picked from commit b9265e7c)

Elle Stone authored Oct 22, 2018 and Michael Natterer committed Oct 23, 2018

Add xyY color space to the color spaces for sampling colors.

Also add code to xcf-load.c that makes sure the sample point loading
code handles unknown future GimpColorPickMode values (fall back to
PIXEL pick mode).

(cherry picked from commit 298cc570)

The value is later CLAMP()ed correctly, but fix the call in xcf-load.c
anyway.

(cherry picked from commit ac5f44eb)

Rename XCF property PROP_SAMPLE_POINT to PROP_OLD_SAMPLE_POINT and add
new PROP_SAMPLE_POINT.

The new property saves the sample point's pick mode plus some padding
for whatever else we might want to add. Always save the old property
too so nothing changes for older GIMP versions, and avoid loading the
old property if the new one was loaded before.

(cherry picked from commit 47a008be)

... (valgrind reports Invalid read)

Add gimp_babl_is_valid(), which takes a GimpImageBaseType and a
GimpPrecision, and determines whether the image-type/precision
combination is valid.  Use this function to validate that loaded
XCFs use a valid type/precision combination, before trying to
create the image.  Otherwise, we get a CRITICAL, and eventually a
segfault, when the combination is invalid.

Use the same function to validate the arguments of
gimp_image_new().

(cherry picked from commit a0a62656)

(cherry picked from commit d4ff57c7)

luz.paz authored Apr 25, 2018 and Jehan committed Apr 25, 2018

Found via `codespell` and grep.

and minor whitepace cleanup.

Symmetries are saved in a parasite, which is backward compatible.

Remove the impromptu boundary invalidation when converting a
channel to a selection mask in xcf_load_channel_props(), as this
happens implicitly when stealing the channel's buffer, since
commit 38d4aa81.

Since commit d0ae244f, which
connects GimpChannel instances to their buffer's "changed" signal,
the XCF loading code that steals a channel's buffer when converting
it to a selection mask (which happens when loading an XCF with a
saved selection mask) is unsafe, since fails to perform the
necessary cleanup and setup of the buffer in the old and new
channel objects, respectively.

Perform the buffer transfer using the new
gimp_drawable_steal_buffer(), which does the same thing in a safe
manner.

If the XCF is truncated in the middle of selection mask data,
don't unref the currently loading channel because we can't
unref the image's selection.

When loading tile data, avoid copying the data into the GEGL
buffer when the tile is empty (i.e., all its bytes are 0), so that
GEGL doesn't allocate memory for it unnecessarily.

The number of pixels is "tile_size / bpp", not "tile_size / n_components".

It was always supposed to be like that, but simply forgotten.
Fortunately, big-endian machines are almost extinct...

The new code is triggered with XCF version >= 12, but we will start
using that only after code review.

this commit changes just those which make no difference to
functionality: property and object member defaults that get overridden
anyway, return values of g_return_val_if_fail(), some other stuff.

When loading tiles from an XCF, reject tiles whose on-disk size is
greater than 1.5 times the size of an uncompressed tile -- a limit
that is already present for the last tile in the buffer.  This
should allow for the possibility of negative compression, while
restricting placing a realistic limit.

Currently, no limit is placed on the on-disk tile data size.  When
loading RLE- and zlib-compressed tiles, a buffer large enough to
hold the entire on-disk tile data, up to 2GB, is allocated on the
stack, and the data is read into it.  If the file is smaller than
the reported tile data size, the area of the buffer past the end
of the file is not touched.  This allows a malicious XCF to write
up to 2GB of arbitrary data, at an arbitrary offset, up to 2GB,
below the stack.

Note that a similar issue had existed for earlier versions of GIMP
(see commit d7a9e607), however,
since prior to 2.9 the tile data buffer was allocated on the heap,
the potential risk is far smaller.

The layer blend space, composite space, and composite mode
properties have a special AUTO value, which may map to different
concrete values based on the layer mode.  Make sure we can change
this mapping in the future, without affecting existing XCFs (saved
after this commit), by encoding these properties as follows:

When saving an XCF, if the property has a concrete (non-AUTO)
value, which is always positive, encode it as is.  If the property
is AUTO, which is always 0, encode it as the negative of the value
it actually maps to at the time of saving (note that in some cases
AUTO may map to AUTO, in which case it's encoded as 0).

When loading an XCF, if the encoded property (stored in the file)
is nonnegative, use it as is.  Otherwise, compare the negative of
the encoded property to the value AUTO maps to at the time of
loading.  If the values are equal, set the property to AUTO;
otherwise, use the concrete value (i.e., the negative of the value
stored in the XCF).

Note that XCFs saved prior to this commit still load fine, it's
simply that if we change the AUTO mapping in the future, all their
AUTO properties will keep being loaded as AUTO, even if the
resulting concrete values will have changed.

We were still saving channel colors in 8 bit, this additionally
saves/loads the color as float values. Still save the old PROP_COLOR
for compatibility.

Both in the GimpImage API and in the GUI. The toggle in the save
dialog now controls ZLIB compression directly. Changed the various
info labels accordingly. Ditch the XCF parasite that saved the XCF
compat mode.

Change the xcf_read_foo() functions to take the XcfInfo* instead of
a GInputStream*, and make them advance the info->cp offset by
themselves. Makes xcf-load.c a lot more readable.

Step one, without changing anything in the saved XCFs yet:

Abstract reading and writing of file offsets away into their own
xcf_read_offset() and xcf_write_offset() functions, which take
"goffset" instead of "guint32". Also change xcf_seek_pos() to take a
goffset argument.

Change all file offset variables in xcf-load.c, xcf-write.c and struct
XcfInfo to goffset, and add new member "bytes_per_offset" to XcfInfo,
which is currently always 4.

and make NORMAL_LEGACY immutable.

...they say it's going to get worse before it gets better...

Largely based on a patch by Ell, with the enum type renamed and
various small changes. Adds another axis of configurability to the
existing layer mode madness, and is WIP too.

"Broken" sounds like it needs fixing, but it's legacy compat stuff
that will have to stay for all eternity.

with proper value names. Mark most values as _BROKEN because they use
weird alpha compositing that has to die. Move GimpLayerModeEffects to
libgimpbase, deprecate it, and set it as compat enum for GimpLayerMode.
Add the GimpLayerModeEffects values as compat constants to script-fu
and pygimp.