This is already documented and updated on gitlab-ci.yml's
"There are five "TYPES" of pipelines on our CI" section so
maintaining two explanations is pointless and not future-proof.
Rather than having to hold Ctrl to switch to edit mode, users can now
just click the start point from the end node to create a connected path.
This makes the Path tool consistent with similar tools in GIMP
(such as Free Select, Scissor Select, and Cage Transform tools) as well
as other programs with a Path tool.
For some GUI elements, we may not want to restrict
the color options to the image mode (for instance,
grid colors on a grayscale or indexed image).
This patch adds a "user_context_aware" boolean
to GimpColorPanel so it can be passed on to set
the same boolean already in GimpColorDialog.
This allows GUI elements like GimpGridEditor to
optionally give full color choices to users,
independent of the image mode.
The behavior of the text tool was such that an undo is pushed only when a single property changes, which is obviously not expected, because, e.g. if part of the text uses a different font this means that the markup changed and all "properties" stayed the same, so an undo wouldn't be pushed.
...color-picking on the image.
In GIMP 3.0, we now show a GimpColormapSelection when
users open a color dialogue. However, unlike the RGB color
selector it does not respond to color-picking, instead always
defaulting to index 0.
This patch adds code to get the index of the currently selected
color from the palette, and set the ColormapSelection's selected
index to that.
47224ba1 set the number of children in the GtkFlowBox
that holds the toolbox widgets to a constant 3. However,
this means if you only have one or two widgets shown,
there was still a horizontal imbalance.
This patch adds up the number of visible widgets whenever
that is changed, and adjust the maximum number of flowbox
children accordingly. It does add a small amount of padding at
the bottom since the invisible widgets are moved below.
As reported by Seungho Kim our despeckle filter doesn't check for
integer overflow when allocating buffers, nor do we check for failed
allocations.
A potential integer overflow vulnerability exists in the GIMP
"Despeckle" plug-in. The issue occurs due to unchecked multiplication
of image dimensions (width, height) and bytes-per-pixel (img_bpp),
which can result in allocating insufficient memory and subsequently
performing out-of-bounds writes. This could lead to heap corruption and
potential denial-of-service (DoS) or arbitrary code execution in
certain scenarios.
Vulnerability Details
•width and height are of type guint (signed 32-bit int).
•Multiplying width * height * img_bpp can result in a value exceeding
the bounds of gsize.
•g_new() does not perform overflow protection; if the size wraps around,
less memory than needed will be allocated.
•Subsequent pixel processing loops write beyond the allocated memory
region (src, dst).
Proof of Concept (PoC)
Open a specially crafted image with very large dimensions (e.g.,
70,000 x 70,000 pixels) and apply the Despeckle filter. GIMP may crash
due to heap corruption, or undefined behavior may occur.
We applied the suggested changes and in addition adjusted the despeckle
function to be able to set error messages, and check for NULL
allocations.
Small follow-up from !2097. To be fair, looking at this plug-in's code,
we should also go much further, because so many useful types are defined
while we could use GLib types.
But I don't want to get into this cleanup rabbit hole right now.
Selecting a color in GimpColorSelection triggers
gimp_color_selection_color_changed (). In the legacy
Grid plug-in, this led to an infinite signal loop (and crash)
when changing colors when the chain link is active. Changing
one button's color would trigger the other to change, which
would trigger the first one to change again and so on.
This patch resolves the issue by blocking the signal in color_callback ()
when the other button is changed in response to the first, so that
there's no infinite chain of callbacks.
It would be more performant since it allows concurrent access as long as
you only need read access (i.e. as long as the cache won't change, which
is the most common case).
- No need of local_grad_data_new(). Just set default variables in init()
as it should be.
- Also move gimp_gradient_chooser_draw_interior() to the init()
function, so that the new() function is only a wrapper of
g_object_new() which is the proper way to implement new classes.
- Get rid of wrong comment.
This commit message has been rewritten by the reviewer (Jehan) because
the original message was not right. It was originally meant to fix#13189
but it was only doing so as a side effect of getting rid of the slice
API.
We still push it as a second step (with updated message) because it's
not a bad idea to stop using the slice API where we can as it's anyway
no more than a malloc/free synonym since GLib 2.76 and might get
deprecated some day.
Even though this is mostly the same thing now, it's only true since GLib
2.76, yet our AppImage uses GLib 2.74.6. This explains why the chooser
finalization was crashing plug-ins.
Note that I also tried to set the monitor as a weak pointer, but it was
not properly finalized by GDK at disconnection apparently. Anyway
processing the "invalidate" signal is a correct way to do this too.
A further possible improvement may be to store the description of the
monitor in the sessionrc file, and keep these in the GimpSessionInfo
too, so that we can easily retrieve a monitor which is often
disconnected and reconnected.
Making sure that it's private then NULLified at end of construction so
that none tries to use this again later on during the life of the
display shell (it may have become invalid since then, cf. #12542).
Also NULLifying a similar variable stored in GimpImageWindow (though it
was already a private variable not used outside in this case).
Setting NULL monitor to file_open_with_display() and
file_open_from_command_line() work just as well to use the monitor under
the pointer which is what gui_get_display_name() was also doing anyway.
We store an `initial_monitor` in several places, not taking into
consideration that a monitor object can become invalid, e.g. when
disconnecting or turning off a monitor. When the monitor is invalid,
it can cause a crash in `gimp_display_shell_set_initial_scale`.
Instead of referencing the initial monitor, we request the monitor for
our display shell. Since at that point we already know that shell is
valid, we should get a valid monitor too.
