Package: glib2.0 / 2.58.3-2+deb10u2

Metadata

Package Version Patches format
glib2.0 2.58.3-2+deb10u2 3.0 (quilt)

Patch series

view the series file
Patch File delta Description
gdbusmessage Fix check on upper limit of message size.patch | (download)

gio/gdbusmessage.c | 2 1 + 1 - 0 !
gio/tests/gdbus-message.c | 72 71 + 1 - 0 !
2 files changed, 72 insertions(+), 2 deletions(-)

 gdbusmessage: fix check on upper limit of message size

There was a typo in the figure checked against. Add a unit test.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
Bug: https://gitlab.gnome.org/GNOME/glib/issues/1642
mainloop test Fix race conditions.patch | (download)

tests/mainloop-test.c | 37 20 + 17 - 0 !
1 file changed, 20 insertions(+), 17 deletions(-)

 mainloop-test: fix race conditions

* Wait for adder threads before deallocating crawler_array and
  context_array to avoid use after-free and data race.
* Handle spurious wakeups around g_cond_wait.
* Avoid starting recurser_idle without context.

Bug: #1530

closures test Avoid timeout on ARM64 CPUs.patch | (download)

tests/refcount/closures.c | 12 12 + 0 - 0 !
tests/refcount/meson.build | 7 7 + 0 - 0 !
2 files changed, 19 insertions(+)

 closures test: avoid timeout on arm64 cpus

Closures use a 16-bit atomic reference count, which is really slow
on certain ARM64 CPUs such as the Cortex-A57 (glib#1316). This is
non-trivial to solve, since the public struct field cannot be enlarged
to 32-bit while preserving ABI, and 16-bit atomic operations would be new
(and rather niche) API.

Until this can be solved properly (hopefully in GLib 2.59.x), cut down
the number of signal emission cycles and bump up the timeout in the
Meson build system, so that builds won't time out. We can't just take
another zero off the number of signal emission cycles, as was done in the
original version of this patch in Debian, because if we do that it can
result in test failures when the main thread starves the other threads.

ARM64 CPUs are backwards-compatible with 32-bit ARM, and the same
slowdown can be seen when building and testing 32-bit code on these
CPUs, so check for both 32- and 64-bit ARM.

Bug-Debian: https://bugs.debian.org/880883
gfile Limit access to files when copying.patch | (download)

gio/gfile.c | 11 6 + 5 - 0 !
1 file changed, 6 insertions(+), 5 deletions(-)

 gfile: limit access to files when copying

file_copy_fallback creates new files with default permissions and
set the correct permissions after the operation is finished. This
might cause that the files can be accessible by more users during
the operation than expected. Use G_FILE_CREATE_PRIVATE for the new
files to limit access to those files.

Bug: https://gitlab.gnome.org/GNOME/glib/merge_requests/876
Bug-CVE: CVE-2019-12450
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929753
keyfile settings Use tighter permissions.patch | (download)

gio/gkeyfilesettingsbackend.c | 5 3 + 2 - 0 !
1 file changed, 3 insertions(+), 2 deletions(-)

 keyfile settings: use tighter permissions

When creating directories, create them with 700 permissions,
instead of 777.

Closes: #1658
credentials Invalid Linux struct ucred means no informati.patch | (download)

gio/gcredentials.c | 42 39 + 3 - 0 !
1 file changed, 39 insertions(+), 3 deletions(-)

 credentials: invalid linux struct ucred means "no information"

On Linux, if getsockopt SO_PEERCRED is used on a TCP socket, one
might expect it to fail with an appropriate error like ENOTSUP or
EPROTONOSUPPORT. However, it appears that in fact it succeeds, but
yields a credentials structure with pid 0, uid -1 and gid -1. These
are not real process, user and group IDs that can be allocated to a
real process (pid 0 needs to be reserved to give kill(0) its documented
special semantics, and similarly uid and gid -1 need to be reserved for
setresuid() and setresgid()) so it is not meaningful to signal them to
high-level API users.

An API user with Linux-specific knowledge can still inspect these fields
via g_credentials_get_native() if desired.

Similarly, if SO_PASSCRED is used to receive a SCM_CREDENTIALS message
on a receiving Unix socket, but the sending socket had not enabled
SO_PASSCRED at the time that the message was sent, it is possible
for it to succeed but yield a credentials structure with pid 0, uid
/proc/sys/kernel/overflowuid and gid /proc/sys/kernel/overflowgid. Even
if we were to read those pseudo-files, we cannot distinguish between
the overflow IDs and a real process that legitimately has the same IDs
(typically they are set to 'nobody' and 'nogroup', which can be used
by a real process), so we detect this situation by noticing that
pid == 0, and to save syscalls we do not read the overflow IDs from
/proc at all.

This results in a small API change: g_credentials_is_same_user() now
returns FALSE if we compare two credentials structures that are both
invalid. This seems like reasonable, conservative behaviour: if we cannot
prove that they are the same user, we should assume they are not.

[Philip Withnall: Dropped new translatable string when backporting to
`glib-2-62`.]

Signed-off-by: Simon McVittie <smcv@collabora.com>
GDBus prefer getsockopt style credentials passing APIs.patch | (download)

gio/gcredentialsprivate.h | 18 18 + 0 - 0 !
gio/gdbusauth.c | 27 25 + 2 - 0 !
2 files changed, 43 insertions(+), 2 deletions(-)

 gdbus: prefer getsockopt()-style credentials-passing apis

Conceptually, a D-Bus server is really trying to determine the credentials
of (the process that initiated) a connection, not the credentials that
the process had when it sent a particular message. Ideally, it does
this with a getsockopt()-style API that queries the credentials of the
connection's initiator without requiring any particular cooperation from
that process, avoiding a class of possible failures.

The leading '\0' in the D-Bus protocol is primarily a workaround
for platforms where the message-based credentials-passing API is
strictly better than the getsockopt()-style API (for example, on
FreeBSD, SCM_CREDS includes a process ID but getpeereid() does not),
or where the getsockopt()-style API does not exist at all. As a result
libdbus, the reference implementation of D-Bus, does not implement
Linux SCM_CREDENTIALS at all - it has no reason to do so, because the
SO_PEERCRED socket option is equally informative.

This change makes GDBusServer on Linux more closely match the behaviour
of libdbus.

In particular, GNOME/glib#1831 indicates that when a libdbus client
connects to a GDBus server, recvmsg() sometimes yields a SCM_CREDENTIALS
message with cmsg_data={pid=0, uid=65534, gid=65534}. I think this is
most likely a race condition in the early steps to connect:

        client           server
    connect
                         accept
    send '\0' <- race -> set SO_PASSCRED = 1
                         receive '\0'

If the server wins the race:

        client           server
    connect
                         accept
                         set SO_PASSCRED = 1
    send '\0'
                         receive '\0'

then everything is fine. However, if the client wins the race:

        client           server
    connect
                         accept
    send '\0'
                         set SO_PASSCRED = 1
                         receive '\0'

then the kernel does not record credentials for the message containing
'\0' (because SO_PASSCRED was 0 at the time). However, by the time the
server receives the message, the kernel knows that credentials are
desired. I would have expected the kernel to omit the credentials header
in this case, but it seems that instead, it synthesizes a credentials
structure with a dummy process ID 0, a dummy uid derived from
/proc/sys/kernel/overflowuid and a dummy gid derived from
/proc/sys/kernel/overflowgid.

In an unconfigured GDBusServer, hitting this race condition results in
falling back to DBUS_COOKIE_SHA1 authentication, which in practice usually
succeeds in authenticating the peer's uid. However, we encourage AF_UNIX
servers on Unix platforms to allow only EXTERNAL authentication as a
security-hardening measure, because DBUS_COOKIE_SHA1 relies on a series
of assumptions including a cryptographically strong PRNG and a shared
home directory with no write access by others, which are not necessarily
true for all operating systems and users. EXTERNAL authentication will
fail if the server cannot determine the client's credentials.

In particular, this caused a regression when CVE-2019-14822 was fixed
in ibus, which appears to be resolved by this commit. Qt clients
(which use libdbus) intermittently fail to connect to an ibus server
(which uses GDBusServer), because ibus no longer allows DBUS_COOKIE_SHA1
authentication or non-matching uids.

Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://gitlab.gnome.org/GNOME/glib/issues/1831
Add a test for GDBusServer authentication.patch | (download)

gio/tests/gdbus-server-auth.c | 491 491 + 0 - 0 !
gio/tests/meson.build | 8 8 + 0 - 0 !
2 files changed, 499 insertions(+)

 add a test for gdbusserver authentication

In particular, if libbdus is available, we test interoperability with
a libdbus client: see GNOME/glib#1831. Because that issue describes a
race condition, we do each test repeatedly to try to hit the failing
case.

Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941018
gdbus server auth test Create temporary directory for Uni.patch | (download)

gio/tests/gdbus-server-auth.c | 76 48 + 28 - 0 !
1 file changed, 48 insertions(+), 28 deletions(-)

 gdbus-server-auth test: create temporary directory for unix socket

This avoids failure to listen on the given address on non-Linux Unix
kernels, where abstract sockets do not exist and so unix:tmpdir is
equivalent to unix:dir.

Unlike the corresponding commit in GLib 2.63.1, this backport continues
to use unix:tmpdir addresses on Linux kernels, because GLib didn't
implement unix:dir until version 2.61.2.

Bug: GNOME/glib#1920
Fixes: 9f962ebe "Add a test for GDBusServer authentication"
Signed-off-by: Simon McVittie <smcv@collabora.com>
gdbus server auth test Include gcredentialsprivate.h.patch | (download)

gio/tests/gdbus-server-auth.c | 7 7 + 0 - 0 !
1 file changed, 7 insertions(+)

 gdbus-server-auth test: include gcredentialsprivate.h

Otherwise we'll never test the EXTERNAL-only mode, because that relies
on testing the private macros
G_CREDENTIALS_UNIX_CREDENTIALS_MESSAGE_SUPPORTED and
G_CREDENTIALS_SOCKET_GET_CREDENTIALS_SUPPORTED.

Fixes: 9f962ebe "Add a test for GDBusServer authentication"
Signed-off-by: Simon McVittie <smcv@collabora.com>
01_gettext desktopfiles.patch | (download)

glib/gkeyfile.c | 72 72 + 0 - 0 !
glib/gkeyfile.h | 4 4 + 0 - 0 !
2 files changed, 76 insertions(+)

 if a .desktop file does not have inline translations,
 fall back to calling gettext

Patch from OpenSUSE via Ubuntu, original author unknown. Martin Pitt and
Vincent Untz appear to be the main authors.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=569829
Bug-Ubuntu: https://launchpad.net/bugs/3935
81 skip monitor test on non linux.patch | (download)

gio/tests/monitor.c | 2 2 + 0 - 0 !
1 file changed, 2 insertions(+)

 skip the monitor test on non-linux as it currently hangs

0001 timer test use volatile for locals.patch | (download)

glib/tests/timer.c | 4 2 + 2 - 0 !
1 file changed, 2 insertions(+), 2 deletions(-)

 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.

Bug: https://gitlab.gnome.org/GNOME/glib/issues/820
gwakeuptest Be less parallel unless invoked with m slow.patch | (download)

glib/tests/gwakeuptest.c | 17 13 + 4 - 0 !
1 file changed, 13 insertions(+), 4 deletions(-)

 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.

Signed-off-by: Simon McVittie <smcv@debian.org>
Bug-Debian: https://bugs.debian.org/884659
debian/02_gettext desktopfiles ubuntu.patch | (download)

glib/gkeyfile.c | 20 20 + 0 - 0 !
1 file changed, 20 insertions(+)

 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.

debian/03_disble_glib_compile_schemas_warning.patch | (download)

gio/glib-compile-schemas.c | 4 4 + 0 - 0 !
1 file changed, 4 insertions(+)

 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.

debian/04_homedir_env.patch | (download)

docs/reference/glib/running.xml | 18 18 + 0 - 0 !
glib/gutils.c | 10 9 + 1 - 0 !
2 files changed, 27 insertions(+), 1 deletion(-)

 handle the g_home environment variable

g_get_home_dir() now respects the HOME environment variable but we'll keep
G_HOME for now as packages in Debian rely on it.

Modified from an earlier patch by Josselin Mouette.

debian/06_thread_test_ignore_prctl_fail.patch | (download)

glib/tests/thread.c | 7 5 + 2 - 0 !
1 file changed, 5 insertions(+), 2 deletions(-)

 do not fail the /thread/thread4 test if prctrl() fails

This happens on the Debian buildds.

debian/61_glib compile binaries path.patch | (download)

gio-2.0.pc.in | 2 1 + 1 - 0 !
gio/meson.build | 2 1 + 1 - 0 !
2 files changed, 2 insertions(+), 2 deletions(-)

 adjust path to glib-compile-schemas in the pkg-config file

This is because gio-querymodules and glib-compile-schemas have been put in
a private, versioned directory in libglib2.0-0 to avoid a dependency loop.

debian/90_gio modules multiarch compat.patch | (download)

gio/giomodule.c | 3 3 + 0 - 0 !
1 file changed, 3 insertions(+)

 gio: add fallback directory for pre-multiarch compatibility

debian/Look for gio launch desktop in libdir glib 2.0.patch | (download)

gio/Makefile.am | 1 1 + 0 - 0 !
gio/gdesktopappinfo.c | 4 2 + 2 - 0 !
gio/meson.build | 1 1 + 0 - 0 !
3 files changed, 4 insertions(+), 2 deletions(-)

 look for gio-launch-desktop in $(libdir)/glib-2.0

In Debian, we install it in the shared library package to avoid
needing a circular dependency between libglib2.0-0 and
libglib2.0-bin.

debian/closures test Skip on arm unless flaky tests are allowed.patch | (download)

tests/refcount/closures.c | 8 8 + 0 - 0 !
1 file changed, 8 insertions(+)

 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.

Signed-off-by: Simon McVittie <smcv@debian.org>
Bug-Debian: https://bugs.debian.org/880883
Bug-Debian: https://bugs.debian.org/917983
debian/Disable some tests on slow architectures which keep faili.patch | (download)

gio/tests/socket.c | 8 8 + 0 - 0 !
glib/tests/mainloop.c | 24 24 + 0 - 0 !
glib/tests/timeout.c | 9 9 + 0 - 0 !
3 files changed, 41 insertions(+)

 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]

Co-authored-by: Simon McVittie <smcv@debian.org>
debian/Skip test which performs some unreliable floating point c.patch | (download)

glib/tests/timer.c | 6 6 + 0 - 0 !
1 file changed, 6 insertions(+)

 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]

Co-authored-by: Simon McVittie <smcv@debian.org>
Bug: https://gitlab.gnome.org/GNOME/glib/issues/820
debian/Skip unreliable test_threaded_singleton by default.patch | (download)

gio/tests/gdbus-threading.c | 6 6 + 0 - 0 !
1 file changed, 6 insertions(+)

 skip unreliable test_threaded_singleton() by default

This test aims to reproduce a race condition between last-unref of the
global singleton GDBusConnection and g_bus_get_sync(). 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().

Demote test_threaded_singleton() to be run as one of the "flaky"
autopkgtests, but not at build time or in the part of the autopkgtest
run that gates progress into testing.

Bug: https://gitlab.gnome.org/GNOME/glib/issues/1515