Debian Patches

Status for glib2.0/2.84.4-3~deb13u3

Patch Description Author Forwarded Bugs Origin Last update
01_gettext-desktopfiles.patch Call gettext if .desktop file does not have inline translations
Patch from OpenSUSE via Ubuntu, original author unknown. Martin Pitt and
Vincent Untz appear to be the main authors.

Reworked slightly by Philip Withnall to avoid exposing new public API
for the non-standard keys.		 Philip Withnall <withnall@endlessm.com> yes upstream 2017-11-23
debian/02_gettext-desktopfiles-ubuntu.patch Provide backwards compatibility for 01_gettext-desktopfiles.patch for X-{Debian,Ubuntu}-Gettext-Domain

Ubuntu-specific. 01_gettext-desktopfiles.patch was changed to use
X-GNOME-, so this is necessary until all our .desktop files are converted.		 Martin Pitt <mpitt@debian.org> no 2009-02-24
debian/03_disble_glib_compile_schemas_warning.patch Disable confusing (to users) warning about deprecated schema paths
Disable a warning when compiling schemas which are installed
into 'deprecated' locations. Users see this very often due to
glib-compile-schemas being called from libglib2.0-0's trigger and it is
not very useful for them.		 Iain Lane <iain.lane@canonical.com> not-needed 2012-09-10
debian/gdesktopappinfo-Try-using-x-terminal-emulator-for-Termina.patch gdesktopappinfo: Try using x-terminal-emulator for Terminal=true apps

Debian Policy provides x-terminal-emulator as an interface for launching
a preferred terminal, for some definition of "preferred". However, the
x-terminal-emulator alternative is a system-wide choice, so in situations
where for example a GNOME user and a KDE user share a computer, only one
of them can have the terminal that will match their desktop environment's
appearance and behaviour conventions as the x-terminal-emulator.

As a result, we still try to use a GTK-based terminal as a higher
preference than x-terminal-emulator. This is done on the assumption
that when apps are launched using GLib interfaces, they are most likely
to have been launched from a GTK application or GTK-based desktop
environment, and therefore a GTK-based terminal will be the best fit for
the desktop environment's conventions and appearance.

I've somewhat arbitrarily sorted x-terminal-emulator as less preferred
than KDE's Konsole, but more preferred than rxvt and various xterm
variants which are not associated with a particular desktop environment.		 Simon McVittie <smcv@debian.org> not-needed debian 2023-02-04
workarounds/timer-test-use-volatile-for-locals.patch timer test: use 'volatile' for locals
GCC seems to be failing to follow the letter of the C spec by allowing extra
precision in floating point values to persist across assignments which are
optimised away.

Force its hand by using 'volatile' on the locals in question.		 Ryan Lortie <desrt@desrt.ca> yes upstream 2014-03-04
workarounds/gwakeuptest-Be-less-parallel-unless-invoked-with-m-slow.patch gwakeuptest: Be less parallel unless invoked with -m slow
This is a workaround for test failures on the reproducible-builds
infrastructure, where a multi-threaded stress-test sometimes takes longer
to finish on x86_64 than it would have done on slow architectures like
arm and mips on the official Debian autobuilders. It is not clear why.

This change will make this test more likely to pass, but less likely to
detect bugs.		 Simon McVittie <smcv@debian.org> no debian 2017-12-18
workarounds/closures-test-Skip-on-arm-unless-flaky-tests-are-allowed.patch closures test: Skip on arm* unless flaky tests are allowed
Choosing the right number of iterations to avoid either taking literally
hours on some hardware, or getting spurious failures when one thread
starves another, seems to be too hard to get right in practice.
Make this test opt-in so that its failures aren't release-critical.
We can run it as a separate autopkgtest that is marked flaky.		 Simon McVittie <smcv@debian.org> not-needed debian 2019-01-03
workarounds/Disable-some-tests-on-slow-architectures-which-keep-faili.patch Disable some tests on slow architectures which keep failing the tests

[smcv: Modified to use g_test_skip() instead of omitting those test cases
completely, and allow them to be re-enabled with a Debian-specific
environment variable]		 Martin Pitt <martin.pitt@ubuntu.com> no 2012-09-27
workarounds/Skip-test-which-performs-some-unreliable-floating-point-c.patch Skip test which performs some unreliable floating point comparisons
[smcv: Modified to use g_test_skip() instead of omitting those test cases
completely, and allow them to be re-enabled with a Debian-specific
environment variable]		 Iain Lane <laney@debian.org> no upstream 2014-03-18
workarounds/Skip-unreliable-gdbus-threading-tests--by-default.patch Skip unreliable gdbus-threading tests by default
test_threaded_singleton() test to reproduce a race condition between
last-unref of the global singleton GDBusConnection and g_bus_get_sync().

test_method_calls_in_thread() checks that multiple threads can all make
method calls to the same proxy.

However, test setup intermittently times out with:

# GLib-GIO-DEBUG: run 0: refcount is 2, sleeping
Bail out! GLib-GIO-FATAL-ERROR: connection had too many refs

The current theory upstream is that this might be a reference leak in
test_delivery_in_thread().

Furthermore, test teardown is now often failing when destroying the test
bus.

Demote these tests to be run as part of the "flaky" autopkgtests, but
not at build time or in the part of the autopkgtest run that gates
progress into testing.		 Simon McVittie <smcv@debian.org> no upstream 2019-01-04
workarounds/gvariant-test-Don-t-run-at-build-time-on-mips.patch gvariant test: Don't run at build-time on mips
DEB_ALLOW_FLAKY_TESTS is not quite right here, because we don't know
that the test would fail if left for long enough - the problem is that
it doesn't get there, because generating random floating-point numbers
is very slow on some of our mips hardware. However, it has the right
practical effect.		 Simon McVittie <smcv@debian.org> no upstream 2019-07-26
workarounds/gdbus-server-auth-Normally-skip-flaky-DBUS_COOKIE_SHA1-te.patch gdbus-server-auth: Normally skip flaky DBUS_COOKIE_SHA1 tests
These intermittently fail on the buildds, but the failure cannot be
reproduced in a debugging environment.

We do not expect to use D-Bus over TCP on non-Windows platforms: we use
an AF_UNIX socket, which is much more robust and secure. However, when
using AF_UNIX, DBUS_COOKIE_SHA1 is unnecessary, because we can use the
more reliable EXTERNAL authentication.		 Simon McVittie <smcv@debian.org> not-needed 2020-11-19
workarounds/Skip-memory-monitor-dbus-test-if-not-specifically-request.patch Skip memory-monitor-dbus test if not specifically requested
This seems to be unreliable, particularly on non-x86.		 Simon McVittie <smcv@debian.org> no debian 2021-10-24
workarounds/tests-Skip-debugcontroller-test.patch tests: Skip debugcontroller test
This is known to be flaky upstream.		 Simon McVittie <smcv@debian.org> not-needed 2022-02-15
workarounds/testfilemonitor-Skip-if-we-are-avoiding-flaky-tests.patch testfilemonitor: Skip if we are avoiding flaky tests
See https://gitlab.gnome.org/GNOME/glib/issues/1634		 Simon McVittie <smcv@debian.org> no 2020-02-25
debian/girepository-Describe-the-Debian-specific-cross-prefixed-.patch girepository: Describe the Debian-specific cross-prefixed names Simon McVittie <smcv@debian.org> not-needed 2024-02-28
gfileutils-Preserve-mode-during-atomic-updates.patch gfileutils: Preserve mode during atomic updates
If g_file_set_contents{_full,} is replacing an existing file, require
that the tmpfile have the same mode as the existing file.

This prevents the umask from taking effect for consistent writes to
existing files.

Closes GNOME/dconf#76

(cherry picked from commit 3cc0c0de33bc4b461e89b05d142e1ecf5f474317)

it seems reasonable to keep it for trixie anyway
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4608		 Wesley Hershberger <wesley.hershberger@canonical.com> no upstream glib-2-84 branch, after 2.84.1 2025-04-22
gconvert-Error-out-if-g_escape_uri_string-would-overflow.patch gconvert: Error out if g_escape_uri_string() would overflow
If the string to escape contains a very large number of unacceptable
characters (which would need escaping), the calculation of the length of
the escaped string could overflow, leading to a potential write off the
end of the newly allocated string.

In addition to that, the number of unacceptable characters was counted
in a signed integer, which would overflow to become negative, making it
easier for an attacker to craft an input string which would cause an
out-of-bounds write.

Fix that by validating the allocation length, and using an unsigned
integer to count the number of unacceptable characters.

Spotted by treeplus. Thanks to the Sovereign Tech Resilience programme
from the Sovereign Tech Agency. ID: #YWH-PGM9867-134


Backport 2.86: Changed the translatable error message to re-use an
existing translatable string, to avoid adding new translatable strings
to a stable branch. The re-used string doesn’t perfectly match the
error, but it’s good enough given that no users will ever see it.		 Philip Withnall <pwithnall@gnome.org> yes debian upstream upstream, 2.86.3, commit:9bcd65ba5fa1b92ff0fb8380faea335ccef56253 2025-11-13
fuzzing-Add-fuzz-tests-for-g_filename_-to-from-_uri.patch fuzzing: Add fuzz tests for g_filename_{to,from}_uri()
These functions could be called on untrusted input data, and since they
do URI escaping/unescaping, they have non-trivial string handling code.		 Philip Withnall <pwithnall@gnome.org> yes debian upstream upstream, 2.86.3, commit:7e5489cb921d0531ee4ebc9938da30a02084b2fa 2025-11-13
gvariant-parser-Fix-potential-integer-overflow-parsing-by.patch gvariant-parser: Fix potential integer overflow parsing (byte)strings

The termination condition for parsing string and bytestring literals in
GVariant text format input was subject to an integer overflow for input
string (or bytestring) literals longer than `INT_MAX`.

Fix that by counting as a `size_t` rather than as an `int`. The counter
can never correctly be negative.

Spotted by treeplus. Thanks to the Sovereign Tech Resilience programme
from the Sovereign Tech Agency. ID: #YWH-PGM9867-145		 Philip Withnall <pwithnall@gnome.org> yes debian upstream upstream, 2.86.3, commit:3e72fe0fbb32c18a66486c4da8bc851f656af287 2025-11-25
gvariant-parser-Use-size_t-to-count-numbers-of-child-elem.patch gvariant-parser: Use size_t to count numbers of child elements
Rather than using `gint`, which could overflow for arrays (or dicts, or
tuples) longer than `INT_MAX`. There may be other limits which prevent
parsed containers becoming that long, but we might as well make the type
system reflect the programmer’s intention as best it can anyway.

For arrays and tuples this is straightforward. For dictionaries, it’s
slightly complicated by the fact that the code used
`dict->n_children == -1` to indicate that the `Dictionary` struct in
question actually represented a single freestanding dict entry. In
GVariant text format, that would be `{1, "one"}`.

The implementation previously didn’t define the semantics of
`dict->n_children < -1`.

Now, instead, change `Dictionary.n_children` to `size_t`, and define a
magic value `DICTIONARY_N_CHILDREN_FREESTANDING_ENTRY` to indicate that
the `Dictionary` represents a single freestanding dict entry.

This magic value is `SIZE_MAX`, and given that a dictionary entry takes
more than one byte to represent in GVariant text format, that means it’s
not possible to have that many entries in a parsed dictionary, so this
magic value won’t be hit by a normal dictionary. An assertion checks
this anyway.

Spotted while working on #3834.		 Philip Withnall <pwithnall@gnome.org> yes debian upstream upstream, 2.86.3, commit:6fe481cec709ec65b5846113848723bc25a8782a 2025-11-25
gvariant-parser-Convert-error-handling-code-to-use-size_t.patch gvariant-parser: Convert error handling code to use size_t
The error handling code allows for printing out the range of input bytes
related to a parsing error. This was previously done using `gint`, but
the input could be longer than `INT_MAX`, so it should really be done
using `size_t`.

Spotted while working on #3834.		 Philip Withnall <pwithnall@gnome.org> yes debian upstream upstream, 2.86.3, commit:dd333a40aa95819720a01caf6de564cd8a4a6310 2025-11-25
gfileattribute-Fix-integer-overflow-calculating-escaping-.patch gfileattribute: Fix integer overflow calculating escaping for byte strings

The number of invalid characters in the byte string (characters which
would have to be percent-encoded) was only stored in an `int`, which
gave the possibility of a long string largely full of invalid
characters overflowing this and allowing an attacker-controlled buffer
size to be allocated.

This could be triggered by an attacker controlled file attribute (of
type `G_FILE_ATTRIBUTE_TYPE_BYTE_STRING`), such as
`G_FILE_ATTRIBUTE_THUMBNAIL_PATH` or `G_FILE_ATTRIBUTE_STANDARD_NAME`,
being read by user code.

Spotted by Codean Labs.		 Philip Withnall <pwithnall@gnome.org> yes debian upstream upstream, 2.86.3, commit:4f0399c0aaf3ffc86b5625424580294bc7460404 2025-12-04
gtimezone-Handle-etc-localtime-symlink-pointing-to-anothe.patch gtimezone: Handle /etc/localtime symlink pointing to another symlink
To resolve a timezone identifier from /etc/localtime we should traverse its
symlink recursively until we find a target under $TZDIR, then the identifier
is that target minus the $TZDIR path prefix.		 Alessandro Astone <alessandro.astone@canonical.com> yes debian upstream upstream, 2.87.3, commit:7073c4872d96b78bfa9396b38e18e8043308550f 2026-01-20
gtimezone-Use-var-db-timezone-zoneinfo-as-the-default-TZD.patch gtimezone: Use /var/db/timezone/zoneinfo as the default TZDIR for macOS

macOS defines /usr/share/zoneinfo as a symlink to /var/db/timezone/zoneinfo,
and /etc/localtime as a symlink to /var/db/timezone/zoneinfo/<identifier>.

By using /usr/share/zoneinfo as TZDIR, we would break the logic that resolves
/etc/localtime as a relative identifier by stripping the TZDIR prefix.
An absolute path still works as identifier, but we prefer a relative one.

Furthermore, by ensuring that /etc/localtime points to a subdir of TZDIR we
correctly handle the case where /etc/localtime points to a symlink of symlink.		 Alessandro Astone <alessandro.astone@canonical.com> yes debian upstream upstream, 2.87.3, commit:bd04ea91dc533303c064ec1cb627844a4aa09aaf 2026-01-22
CVE-2026-0988.patch gbufferedinputstream: Fix a potential integer overflow in peek()
If the caller provides `offset` and `count` arguments which overflow,
their sum will overflow and could lead to `memcpy()` reading out more
memory than expected.

Spotted by Codean Labs.


(cherry picked from commit c5766cff61ffce0b8e787eae09908ac348338e5f)		 Philip Withnall <pwithnall@gnome.org> no 2025-12-18
CVE-2026-1484-1.patch gbase64: Use gsize to prevent potential overflow
Both g_base64_encode_step() and g_base64_encode_close() return gsize
values, but these are summed to an int value.

If the sum of these returned values is bigger than MAXINT, we overflow
while doing the null byte write.

Spotted by treeplus.
Thanks to the Sovereign Tech Resilience programme from the Sovereign
Tech Agency.


(cherry picked from commit 6845f7776982849a2be1d8c9b0495e389092bff2)

(cherry picked from commit 5ba0ed9ab2c28294713bdc56a8744ff0a446b59c)		 Marco Trevisan <mail@3v1n0.net> no 2026-01-23
CVE-2026-1484-2.patch gbase64: Ensure that the out value is within allocated size
We do not want to deference or write to it

Related to: #3870

(cherry picked from commit 25429bd0b22222d6986d000d62b44eebf490837d)		 "Marco Trevisan (Treviño)" <mail@3v1n0.net> no 2026-01-21
CVE-2026-1485.patch gio/gcontenttype-fdo: Do not overflow if header is longer than MAXINT

In case the header size is longer than MAXINT we may read and write to
invalid locations

Spotted by treeplus.
Thanks to the Sovereign Tech Resilience programme from the Sovereign
Tech Agency.


(cherry picked from commit aacda5b07141b944408c79e83bcbed3b2e1e6e45)

(cherry picked from commit ee5acb2cefc643450509374da2600cd3bf49a109)		 Marco Trevisan <mail@3v1n0.net> no 2026-01-23
CVE-2026-1489-1.patch guniprop: Use size_t for output_marks length
The input string length may overflow, and this would lead to wrong
behavior and invalid writes.

Spotted by treeplus.
Thanks to the Sovereign Tech Resilience programme from the Sovereign
Tech Agency.

(cherry picked from commit 662aa569efa65eaa4672ab0671eb8533a354cd89)		 "Marco Trevisan (Treviño)" <mail@3v1n0.net> no 2026-01-21
CVE-2026-1489-2.patch guniprop: Do not convert size_t to gint
We were correctly using size_t in output_special_case() since commit
362f92b69, but then we converted the value back to int

Related to: #3872

(cherry picked from commit 58356619525a1d565df8cc348e9784716f020f2f)		 "Marco Trevisan (Treviño)" <mail@3v1n0.net> no 2026-01-21
CVE-2026-1489-3.patch guniprop: Ensure we do not overflow size in g_utf8_{strdown,gstrup}()

While this is technically not a security issue, when repeatedly adding
to a size_t value, we can overflow and start from 0.

Now, while being unlikely, technically an utf8 lower or upper string can
have a longer size than the input value, and if the output string is
bigger than G_MAXSIZE we'd end up cutting it silently.

Let's instead assert each time we increase the output length

(cherry picked from commit 170dc8c4068db4c4cbf63c7d27192e230436da21)		 "Marco Trevisan (Treviño)" <mail@3v1n0.net> no 2026-01-21
CVE-2026-1489-4.patch glib/tests/unicode: Add test debug information when parsing input files

On case of failures makes it easier to understand on what line of the
source file we're at, as it might not be clear for non-ascii chars

(cherry picked from commit b96966058f4291db8970ced70ee22103e63679e5)		 "Marco Trevisan (Treviño)" <mail@3v1n0.net> no 2026-01-23

All known versions for source package 'glib2.0'

Links