This will be a neat reminder for some of the hidden environment
variables helpful to debug GIMP in some cases, as well as some other
tricks, which we often have to tell people or even which we forget (or
don't even know sometimes) ourselves.
This will be less annoying to just remember to check this file if we
forget the name of some environment variable than to try and grep the
git log or the code.
If someone adds another environment variable which changes some behavior
of the code, please add it here. Also if you know some other helpful
tricks, share with all. Thanks.
Since commit a427213fb8, the special glib value "help" does not work
anymore as a helper (listing the list of available flags).
This means that to use GIMP_DEBUG environment variable, one has to
either know them all by heart or check the app/gimp-log.c file.
This commit still leaves "help" as a normal flag for GIMP_LOG_HELP
domain in GIMP, but creates instead "list-all" as the new helper value.
Moreover as a fallback, setting a random value to GIMP_DEBUG with no
valid flags in it will also output the list of available flags. This
way, one doesn't even have to remember a specific string to obtain the
list.
Replace the "lock brush size to zoom" paint option with a "lock
brush to view" option, which links the entire brush transform to
the view transform, so that the brush remains invariant in display
space under scaling, rotation, and reflection.
Add support for reflecting brushes as part of their transformation.
The reflection is performed as the last step of the transformation,
across the vertical axis.
The option to reflect the brush is not exposed in the UI, or
through the PDB, but is intended to be used for linking the brush
transformation to the view transformation, in the next commit.
When you move an endpoint in the Blend Tool, angle and distance
information are especially important, in case you want to draw a
gradient with specific values.
Currently Blend tool only shows the vector coordinates whose usefulness
is a bit of a question. Now it will also show distance (in current shell
unit) and angle!
fopen() modes "wb+" and "w+b" are aliases of the same opening mode
(truncate/create in binary read/write). But it turns out that Windows
implementation does not understand "wb+". The alias "w+b" works fine in
my tests.
There should be absolutely no code change semantic in this commit. If
there is, that's a mistake and it's on me. I only cleaned up the syntax
in the C file which basically was following none of GIMP coding style
(tabs everywhere, brackets at end of lines, nearly no space anywhere so
all the code was a compressed mess which was hard to read, indentation
absolutely wrong everywhere, etc.).
I cleaned it up with a bunch of regexp search-and-replace followed by a
lot of manual cleaning and verification as well.
I also tested with various FLI files found on the web, and they were
loading fine in GIMP. So I believe/hope that I didn't mess up somewhere,
but it looks as the cleaning went all fine.
It is possible to trigger a heap overflow while parsing FLI files. The
RLE decoder is vulnerable to out of boundary writes due to lack of
boundary checks.
The variable "framebuf" points to a memory area which was allocated
with fli_header->width * fli_header->height bytes. The RLE decoder
therefore must never write beyond that limit.
If an illegal frame is detected, the parser won't stop, which means
that the next valid sequence is properly parsed again. This should
allow GIMP to parse FLI files as good as possible even if they are
broken by an attacker or by accident.
While at it, I changed the variable xc to be of type size_t, because
the multiplication of width and height could overflow a 16 bit type.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Add an offset_angle parameter to gimp_constrain_line(), which
offsets the radial lines by a given angle.
Add gimpdisplayshell-utils.[ch], with two new functions:
- gimp_display_shell_get_constrained_line_offset_angle():
Returns the offset angle to be passed to
gimp_constrain_line(), in order to constrain line angles in
display space, according to the shell's rotation angle and
flip mode.
- gimp_display_shell_constrain_line(): A convenience function
which calls gimp_constrain_line() with the said offset angle.
Use the new functions in all instances where we constrain line
angles, so that angles are constrained in display space, rather
than image space.
The only exception is GimpEditSelectionTool, which keeps
constraining angles in image space, since it's not entirely obvious
that we want to constrain angles of dragged layers/selections in
display space.
This reverts commit 06d24a79af.
The CVE is still fixed but now in a different way. Commit 4fa0cd4dcf
passes instead the accurate string length when using the string, hence
making it work even when not NUL-terminated. This has the advantage of
having the GBR file loaded in the end, despite such file format error. I
am personally not persuaded this is the best path since a file with such
an error may either be corrupted, or worse may have been constructed on
purpose to be harmful, so rejecting it directly may be the safe choice.
Nevertheless I may also be too doubtful and maybe trying to save a
slightly corrupted file may be the nicest choice indeed.
The file formats GBR and PAT contain names which are supposed to be
NUL-terminated within the files. If no such terminating NUL byte
exists, the parsers of GBR and PAT trigger an out of boundary read
during utf-8 conversion.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Some g_message() stay when they are used as debug or warning message
(without actually cancelling load action). But all fatal errors now use
g_set_error().
... in PSP importer.
Check if declared block length is valid (i.e. within the actual file)
before going further.
Consider the file as broken otherwise and fail loading it.
According to some spec on the web, 16-bit RGB is also valid. In this
case, the last bit is simply ignored (at least that's how it is
implemented right now).
... TGA importer.
Be more thorough on valid TGA RGB and RGBA images.
In particular current TGA plug-in can import RGBA as 32 bits (8 bits per
channel) and 16 bits (5 bits per color channel and 1 bit for alpha), and
RGB as 15 and 24 bits.
Maybe there exist more variants, but if they do exist, we simply don't
support them yet.
Thanks to Hanno Böck for the report and a first patch attempt.
Милош Поповић