Resolves#15968
It is possible to cause a buffer overflow in our ANI
loading code by setting the Name or Artist metadata
files to 0xFFFFFFFF. This patch changes our allocation
code to use g_try_new0 () instead of g_new0 (), and
verifies if it is NULL before trying to read data into it.
As pointed out by Dhiraj, it is possible to set width and
height values in the ICO header that will overflow a 32 bit
integer when loaded in. This patch adds checks using
g_size_check_mul () and g_try_new () to catch these
overflows and prevent them from crashing the plug-in.
We were already considering the plugins under /common but
not the plug-ins that have their own subdirectories. So,
plugin_executables did not match custom_plugin_targets and
the build started to fail on macOS where install_name_tool
neeeds to process the plugins setting the right LC_RPATH.
Resolves#15555
This patch adds some guards for ico_read_int8 (),
which was used for loading palettes and maps
without verifying that it returned the same number
of bytes as what it tried to read in.
This issue was raised by Anders in #15152 and it was a mean one, because
it really looked like file-ani-export was crashing inside
_gimp_procedure_config_end_export() (so after its main run function),
but somehow only when being called from another plug-in (in particular
here, from the file-compressor plug-in). So it looked like a bug
somewhere in libgimp.
It turned out to be a "simple" memory corruption which was not
immediately showing its consequences.
Resolves#13910
Since ICO can store PNGs, it's possible to create an
icon that's much larger than the stated image size and
cause a buffer overflow.
This patch adds a check to make sure the width * height * 4
calculation does not overflow in addition to making sure it
doesn't exceed the maximum allowed size for that icon.
Since the ICO plug-in did not process the image with
gimp_export_options_get_image () before export,
filters were not being merged down and thus not
included in the final image.
This patch adds that feature to ICO, CUR, and ANI
exports.
Resolves#13099
For indexed ICO images, we get the palette from a
temporary image during export. Since the palette is
tied to the image, when we convert the temp image to
RGB and then delete it, the GimpPalette is lost and
the image is exported as pure black.
This patch resolves the issue by calling
gimp_palette_get_colors () to get the actual GeglColors,
then adding them to a new palette with
gimp_palette_new (). As this is separate from the
temporary image, it is retained after the call to
ico_image_get_reduced_buf ().
For plug-in writers reference, these are equivalent:
- (plug-in-threshold-alpha RUN-NONINTERACTIVE image layer threshold))
+ (gimp-drawable-merge-new-filter layer "gimp:threshold-alpha" 0 LAYER-MODE-REPLACE 1.0 "value" (/ threshold 255))
The main difference is that threshold arg was a [0; 255] int whereas
"value" is a [0.0; 1.0] double.
This commit also shows how to run filters in C plug-ins (file-ico here)
as a one-liner too, thanks to the varargs conviency function.
This is a followup of previous commit. We must set the win_subsystem
option on executable() so that the result binary is compiled as a GUI
application (and doesn't output a console every time).
The previous commit is still needed and is what allows us to control
when to actually display a console.
GimpArray (and therefore the int32 array typedef) contains its own size.
We don't need to store the array size in a preceding argument.
Also adding gimp_int32_array_get_values() and gimp_int32_array_set_values()
to edit an existing GimpArray.
This comes with the fact we should start making the GimpArray type more
explicit, because clearly by trying to hide this type so much, it was
too much looking like the int32 array param spec was expecting a C array
(as was visible in the file-ico plug-in where we were getting a C array,
which was a bug only made invisible by the fact we were not setting the
C array back in the config object in the end).
Last but not least, I finally implemented int32 array (de)serialization.
As a side fix, the "images" arg in file-pdf-export-multi procedure is
now a proper image array (not an int32 array), and of course the "count"
arg was removed.
These function names look like they should be applied to a
GimpPaletteEntry, which is a type which doesn't exist in libgimp. This
naming is much more appropriate.
This patch creates a GimpExportOptions class in both
libgimpbase and in libgimp. Currently it is a mostly empty
object, but it will be added to after 3.0 to allow for
additional export options (like resizing on export while
leaving the original image intact)
libgimp/gimpexport.c was removed, and most of its content
was copied into libgimp/gimpexportoptions.c. gimp_export_image ()
was replaced with gimp_export_options_get_image () in all
export plug-ins.
GimpExportProcedure has a new function to set the default
image capabilities for each plug-in on creation. It also sets up
a new callback function, which allows the options to respond to
user setting changes (such as toggling 'Save as Animation' in the
GIF or WEBP Plug-in).
Note that the widgets are still made
with GTK directly. The primary goal of this
initial port is to remove the last usage of
gimp_export_dialog_new (). Future work
will be needed as currently we can not
automatically generate widgets from
array parameters.
With the new API introduced int d1c4457f,
we next need to port all plug-ins using
the argument macros to functions.
This will allow us to remove the macros
as part of the 3.0 API clean-up.
Port all plug-ins to retrieve the layers
directly from the image rather than
having them passed in. This resolves some
issues with introspection and sets the
foundation for future API work.
Though it's not visible and could happily wait for after GIMP 3 release, this
was annoying when grepping. Just did a quick cleanup.
I also removed gimprc.common which is a forgotten remnant from the autotools
build.
Resolves#10932
Since GIMP distinguishes between saving
XCF and exporting image like PNG,
we should change the PDB to show
export rather than save in the function
calls.
If we leave a space between the macro name and opening parenthese for argument
lists, the args are not considered macro args (which will be discovered when
using it). I experienced this issue while testing code on some plug-in
yesterday, so thought I might as well fix all these broken macros for casting to
the specific GimpPlugIn subclass, so that we won't have a next time.
The gimp_procedure_run() already existed, though it was with an ordered
GimpValueArray array of arguments. Its usage feels redundant to the series of
gimp_pdb_run_procedure*() functions (which is confusing), but
gimp_procedure_run() was actually a bit more generic, because it does not
necessarily calls GimpProcedure-s through the PDB! For instance, it can runs a
local GimpProcedure, such as the case of one procedure which would want to call
another procedure in the same plug-in, but without having to go through PDB. Of
course, for local code, you may as well run relevant functions directly, yet it
makes sense that if one of the redundant-looking function is removed, it should
be the more specific one. Also gimp_procedure_run() feels a lot simpler and
logical, API wise.
A main difference in usage is that now, plug-in developers have to first
explicitly look up the GimpPdbProcedure with gimp_pdb_lookup_procedure() when
they wish to call PDB procedures on the wire. This was done anyway in the
gimp_pdb_run_procedure*() code, now it's explicit (rather than calling by name
directly).
Concretely:
* gimp_pdb_run_procedure(), gimp_pdb_run_procedure_config() and
gimp_pdb_run_procedure_valist() are removed.
* gimp_procedure_run() API is modified to use a variable args list instead of a
GimpValueArray.
* gimp_procedure_run_config() and gimp_procedure_run_valist() are added.
* gimp_procedure_run_config() in particular will be the one used in bindings
which don't have variable args support through a (rename-to
gimp_procedure_run) annotation.
Passing (name, type, value) triplets is actually useless because we can get the
type information from the procedure/config anyway. That only adds one more
verification to do. Let's just change the function so that we pass (name, value)
couples instead, pretty much like in `g_object_set()`.
As far as plug-in API is concerned, at least the calling API, order of arguments
when calling PDB procedures doesn't matter anymore.
Order still matters for creating procedures with standard arguments (for
instance, "run-mode" is first, then image, or file, drawables or whatnot,
depending on the subtype of procedure), but not for calling with libgimp.
Concretely in this commit:
- gimp_pdb_run_procedure_argv() was removed as it's intrinsically order-based.
- gimp_pdb_run_procedure() and gimp_pdb_run_procedure_valist() stay but their
semantic changes. Instead of an ordered list of (type, value) couple, it's now
an unordered list of (name, type, value) triplets. This way, you can also
ignore as many args as you want if you intend to keep them default. For
instance, say you have a procedure with 20 args and you only want to change
the last one and keep the 19 first with default values: while you used to have
to write down all 20 args annoyingly, now you can just list the only arg you
care about.
There are 2 important consequences here:
1. Calling PDB procedures becomes much more semantic, which means scripts with
PDB calls are simpler (smaller list of arguments) and easier to read (when
you had 5 int arguments in a row, you couldn't know what they refer to,
except by always checking the PDB source; now you'll have associated names,
such as "width", "height" and so on) hence maintain.
2. We will have the ability to add arguments and even order the new arguments in
middle of existing arguments without breaking compatibility. The only thing
which will matter will be that default values of new arguments will have to
behave like when the arg didn't exist. This way, existing scripts will not be
broken. This will avoid us having to always create variants of PDB procedure
(like original "file-bla-save", then variant "file-bla-save-2" and so on)
each time we add arguments.
Note: gimp_pdb_run_procedure_array() was not removed yet because it's currently
used by the PDB. To be followed.
The various information (width, height, image type and number of layers) are
those of the full image, not of the thumbnail. Make it clear in the docs of
GimpRunThumbnailFunc.
Additionally:
- file-xmc was returning the proper information but variables were wrongly
named, which was confusing.
- Fix file-ico thumbnail proc which was returning the thumbnail width/height.
- In file-darktable, initialize width/height to 0 so that we just don't show any
size when we don't get the information. It's better not to show anything than
completely wrong information (the thumbnail target size).
… than a GimpValueArray.
Similar to other GimpProcedure, move to using a config object. A difference is
that thumbnail procedures are always run non-interactively.
Also fixing WMF load thumbnail procedure: the dimension computation was wrong
when the image was wider than tall.
8bpp and below ICO formats use a 1 bit mask for transparency.
When imported the mask is treated as an additional transparent color.
If the icon used the max palette (e.g. 2 colors for a 1bit icon),
the default export format will become larger than necessary.
This checks if the layer still has 1 bit alpha, and subtracts the
mask color from the count.
GLib has a specific type for byte arrays: `GBytes` (and it's underlying
GType `G_TYPE_BYTES`).
By using this type, we can avoid having a `GimpUint8Array` which is a
bit cumbersome to use for both the C API, as well as bindings. By using
`GBytes`, we allow other languages to pass on byte arrays as they are
used to, while the bindings will make sure to do the right thing.
In the end, it makes the API a little bit simpler for everyone, and
reduces confusion for people who are used to working with byte arrays
in other C/GLib based code (and not having 2 different types to denote
the same thing).
Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
The IART and INAM metadata fields were stored in gchar arrays,
which have a limit of G_MAXSHORT indexes.
However, you can have strings larger than that in the format.
To prevent overflows, they were changed to gchar*. f_read ()'s result
is also checked, and an error is set if it returns 0.
The frame count variable is also now reset per icon block to prevent
overflow as well.
The magics used for detection for CUR and ICO are not very unique and
interfere with the detection of certain types of TGA images.
Since these TGA images are regularly used, it seems better to only base
CUR and ICO detection on the extension, just as we do with TGA version 1
files.
See also issue #7912
- This is unneeded in all import procedures. See previous commit. Note though
that this is not because of a change in previous commit. This was already
useless previously. The file set with this PDB function was overridden by the
core anyway (i.e. even before the previous commits).
In app/file/file-import.c:file_import_image(), the imported file is correctly
set (so there is no need to set it from plug-in, which anyway libgimp's
gimp_image_set_file() was not doing) and the XCF file is reset to NULL
(rendering the call to gimp_image_set_file() in a GimpLoadProcedure useless).
- Similarly, this is a useless call in export procedures because
app/file/file-save.c:file_save() overrides such call too. I could only see one
such case for JPEG export, which was quite useless.
- Finally in other types of plug-ins, setting a non-XCF file extension was
interfering with the save feature (similarly to commit e6e73e14c7). I only
fixed the screenshot implementations doing such a thing.
- I left a few usages which will have to be looked at more in details later.
.ani files require metadata fields to be an even length. If the data
length is odd, an extra 0x00 is added for padding.
This patch updates the export and import code to comply with this
requirement.
Now that we bumped our meson requirement, meson is complaining about
several features now deprecated even in the minimum required meson
version:
s/meson.source_root/meson.project_source_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.source_root. use meson.project_source_root() or meson.global_source_root() instead.
s/meson.build_root/meson.project_build_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead.
Fixing using path() on xdg_email and python ExternalProgram variables:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': ExternalProgram.path. use ExternalProgram.full_path() instead
s/get_pkgconfig_variable *(\([^)]*\))/get_variable(pkgconfig: \1)/ to
fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': dependency.get_pkgconfig_variable. use dependency.get_variable(pkgconfig : ...) instead
GIMP tried to open webp files as ani (animated cursor) files. The reason
for this is that for ani we had set the file magic as the first 4 bytes
should be RIFF.
However, RIFF is a container format, used by many different file formats,
among which is also webp.
This means that checking for RIFF is not specific enough.
Based on the info on http://fileformats.archiveteam.org/wiki/ANI
we will check the 4 bytes starting at offset 8 for ACON, which is
apparently the identifying part for animated icons.
