Package: glib2.0 / 2.58.3-2+deb10u3

Metadata

Package Version Patches format
glib2.0 2.58.3-2+deb10u3 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>
gstrfuncs Add internal g_memdup2 function.patch | (download)

docs/reference/glib/meson.build | 1 1 + 0 - 0 !
glib/gstrfuncsprivate.h | 55 55 + 0 - 0 !
glib/meson.build | 1 1 + 0 - 0 !
glib/tests/strfuncs.c | 23 23 + 0 - 0 !
4 files changed, 80 insertions(+)

 gstrfuncs: add internal g_memdup2() function
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

This will replace the existing `g_memdup()` function for use within
GLib. It has an unavoidable security flaw of taking its `byte_size`
argument as a `guint` rather than as a `gsize`. Most callers will
expect it to be a `gsize`, and may pass in large values which could
silently be truncated, resulting in an undersize allocation compared
to what the caller expects.

This could lead to a classic buffer overflow vulnerability for many
callers of `g_memdup()`.

`g_memdup2()`, in comparison, takes its `byte_size` as a `gsize`.

Spotted by Kevin Backhouse of GHSL.

In GLib 2.68, `g_memdup2()` will be a new public API. In this version
for backport to older stable releases, it’s a new `static inline` API
in a private header, so that use of `g_memdup()` within GLib can be
fixed without adding a new API in a stable release series.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: CVE-2021-27219
Helps: GHSL-2021-045
Bug: https://gitlab.gnome.org/GNOME/glib/-/issues/2319
Bug-Debian: https://bugs.debian.org/982778
glib Use g_memdup2 instead of g_memdup in obvious places.patch | (download)

glib/gbytes.c | 6 4 + 2 - 0 !
glib/gdir.c | 3 2 + 1 - 0 !
glib/gslice.c | 3 2 + 1 - 0 !
glib/gtestutils.c | 3 2 + 1 - 0 !
glib/gvariant.c | 7 4 + 3 - 0 !
glib/gvarianttype.c | 3 2 + 1 - 0 !
glib/tests/array-test.c | 4 3 + 1 - 0 !
glib/tests/option-context.c | 6 4 + 2 - 0 !
8 files changed, 23 insertions(+), 12 deletions(-)

 glib: use g_memdup2() instead of g_memdup() in obvious places
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Convert all the call sites which use `g_memdup()`’s length argument
trivially (for example, by passing a `sizeof()` or an existing `gsize`
variable), so that they use `g_memdup2()` instead.

In almost all of these cases the use of `g_memdup()` would not have
caused problems, but it will soon be deprecated, so best port away from
it

In particular, this fixes an overflow within `g_bytes_new()`, identified
as GHSL-2021-045 (aka CVE-2021-27219) by GHSL team member Kevin Backhouse.

Adapted for GLib 2.58 by Simon McVittie.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: CVE-2021-27219
Fixes: GHSL-2021-045
[Backport to 2.58: Omit changes to ghash.c, will be a separate commit]
[Backport to 2.58: Omit changes to giochannel.c, not needed in this branch]
[Backport to 2.58: Omit changes to uri test, not needed in this branch]
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://gitlab.gnome.org/GNOME/glib/-/issues/2319
Bug-Debian: https://bugs.debian.org/982778
ghash Use g_memdup2 instead of g_memdup.patch | (download)

glib/ghash.c | 3 2 + 1 - 0 !
1 file changed, 2 insertions(+), 1 deletion(-)

 ghash: use g_memdup2() instead of g_memdup()

Backport of part of commit 0736b7c1e7cf4232c5d7eb2b0fbfe9be81bd3baa
to the simpler structure of the GHashTable code in glib-2-58.

Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://gitlab.gnome.org/GNOME/glib/-/issues/2319
Bug-Debian: https://bugs.debian.org/982778
gobject Use g_memdup2 instead of g_memdup in obvious plac.patch | (download)

gobject/gsignal.c | 3 2 + 1 - 0 !
gobject/gtype.c | 9 5 + 4 - 0 !
gobject/gtypemodule.c | 3 2 + 1 - 0 !
gobject/tests/param.c | 4 3 + 1 - 0 !
4 files changed, 12 insertions(+), 7 deletions(-)

 gobject: use g_memdup2() instead of g_memdup() in obvious places
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Convert all the call sites which use `g_memdup()`’s length argument
trivially (for example, by passing a `sizeof()`), so that they use
`g_memdup2()` instead.

In almost all of these cases the use of `g_memdup()` would not have
caused problems, but it will soon be deprecated, so best port away from
it.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Bug: https://gitlab.gnome.org/GNOME/glib/-/issues/2319
Bug-Debian: https://bugs.debian.org/982778
gio Use g_memdup2 instead of g_memdup in obvious places.patch | (download)

gio/gdbusconnection.c | 5 3 + 2 - 0 !
gio/gdbusinterfaceskeleton.c | 3 2 + 1 - 0 !
gio/gfile.c | 7 4 + 3 - 0 !
gio/gsettingsschema.c | 5 3 + 2 - 0 !
gio/gwin32registrykey.c | 8 5 + 3 - 0 !
gio/tests/async-close-output-stream.c | 6 4 + 2 - 0 !
gio/tests/gdbus-export.c | 5 3 + 2 - 0 !
gio/win32/gwinhttpfile.c | 9 5 + 4 - 0 !
8 files changed, 29 insertions(+), 19 deletions(-)

 gio: use g_memdup2() instead of g_memdup() in obvious places
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Convert all the call sites which use `g_memdup()`’s length argument
trivially (for example, by passing a `sizeof()`), so that they use
`g_memdup2()` instead.

In almost all of these cases the use of `g_memdup()` would not have
caused problems, but it will soon be deprecated, so best port away from
it.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Bug: https://gitlab.gnome.org/GNOME/glib/-/issues/2319
Bug-Debian: https://bugs.debian.org/982778
gvariant test Use g_memdup2.patch | (download)

glib/tests/gvariant.c | 9 5 + 4 - 0 !
1 file changed, 5 insertions(+), 4 deletions(-)

 gvariant test: use g_memdup2

This code no longer existed on the glib-2-66 branch, but it's present
in glib-2-58. It's easier to verify that all potentially problematic
g_memdup() uses have been replaced if we replace these too.

Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://gitlab.gnome.org/GNOME/glib/-/issues/2319
Bug-Debian: https://bugs.debian.org/982778
gwinhttpfile Avoid arithmetic overflow when calculating a.patch | (download)

gio/win32/gwinhttpfile.c | 8 4 + 4 - 0 !
1 file changed, 4 insertions(+), 4 deletions(-)

 gwinhttpfile: avoid arithmetic overflow when calculating a size
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

The members of `URL_COMPONENTS` (`winhttp_file->url`) are `DWORD`s, i.e.
32-bit unsigned integers. Adding to and multiplying them may cause them
to overflow the unsigned integer bounds, even if the result is passed to
`g_memdup2()` which accepts a `gsize`.

Cast the `URL_COMPONENTS` members to `gsize` first to ensure that the
arithmetic is done in terms of `gsize`s rather than unsigned integers.

Spotted by Sebastian Dröge.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Bug: https://gitlab.gnome.org/GNOME/glib/-/issues/2319
Bug-Debian: https://bugs.debian.org/982778
gwin32 Use gsize internally in g_wcsdup.patch | (download)

gio/gwin32appinfo.c | 2 1 + 1 - 0 !
gio/gwin32registrykey.c | 2 1 + 1 - 0 !
2 files changed, 2 insertions(+), 2 deletions(-)

 gwin32: use gsize internally in g_wcsdup()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

This allows it to handle strings up to length `G_MAXSIZE` — previously
it would overflow with such strings.

Update the several copies of it identically.

Adapted for GLib 2.58 by Simon McVittie.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
gbytearray Do not accept too large byte arrays.patch | (download)

glib/garray.c | 6 6 + 0 - 0 !
glib/gbytes.c | 4 4 + 0 - 0 !
glib/tests/bytes.c | 37 35 + 2 - 0 !
3 files changed, 45 insertions(+), 2 deletions(-)

 gbytearray: do not accept too large byte arrays

GByteArray uses guint for storing the length of the byte array, but it
also has a constructor (g_byte_array_new_take) that takes length as a
gsize. gsize may be larger than guint (64 bits for gsize vs 32 bits
for guint). It is possible to call the function with a value greater
than G_MAXUINT, which will result in silent length truncation. This
may happen as a result of unreffing GBytes into GByteArray, so rather
be loud about it.

(Test case tweaked by Philip Withnall.)

(Backport 2.66: Add #include gstrfuncsprivate.h in the test case for
`g_memdup2()`.)

Fixes: CVE-2021-27218
Bug-Debian: https://bugs.debian.org/982779
glocalfileoutputstream Fix a typo in a comment.patch | (download)

gio/glocalfileoutputstream.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 glocalfileoutputstream: fix a typo in a comment

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Bug: https://gitlab.gnome.org/GNOME/glib/-/issues/2325
Bug-Debian: https://bugs.debian.org/984969
tests Stop using g_test_bug_base in file tests.patch | (download)

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

 tests: stop using g_test_bug_base() in file tests
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Since a following commit is going to add a new test which references
Gitlab, so it’s best to move the URI bases inside the test cases.

Backported to GLib 2.58 by Simon McVittie.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
[GLib 2.58.x did not allow g_test_bug() without g_test_bug_base(),
so use an empty string as the base]
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://gitlab.gnome.org/GNOME/glib/-/issues/2325
Bug-Debian: https://bugs.debian.org/984969
glocalfileoutputstream Factor out a flag check.patch | (download)

gio/glocalfileoutputstream.c | 7 4 + 3 - 0 !
1 file changed, 4 insertions(+), 3 deletions(-)

 glocalfileoutputstream: factor out a flag check

This clarifies the code a little. It introduces no functional changes.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Bug: https://gitlab.gnome.org/GNOME/glib/-/issues/2325
Bug-Debian: https://bugs.debian.org/984969
glocalfileoutputstream Fix CREATE_REPLACE_DESTINATION wit.patch | (download)

gio/glocalfileoutputstream.c | 49 35 + 14 - 0 !
gio/tests/file.c | 107 107 + 0 - 0 !
2 files changed, 142 insertions(+), 14 deletions(-)

 glocalfileoutputstream: fix create_replace_destination with symlinks
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

The `G_FILE_CREATE_REPLACE_DESTINATION` flag is equivalent to unlinking
the destination file and re-creating it from scratch. That did
previously work, but in the process the code would call `open(O_CREAT)`
on the file. If the file was a dangling symlink, this would create the
destination file (empty). That’s not an intended side-effect, and has
security implications if the symlink is controlled by a lower-privileged
process.

Fix that by not opening the destination file if it’s a symlink, and
adjusting the rest of the code to cope with
 - the fact that `fd == -1` is not an error iff `is_symlink` is true,
 - and that `original_stat` will contain the `lstat()` results for the
   symlink now, rather than the `stat()` results for its target (again,
   iff `is_symlink` is true).

This means that the target of the dangling symlink is no longer created,
which was the bug. The symlink itself continues to be replaced (as
before) with the new file — this is the intended behaviour of
`g_file_replace()`.

The behaviour for non-symlink cases, or cases where the symlink was not
dangling, should be unchanged.

Includes a unit test.

Resolves CVE-2021-28153 (glib#2325). Backported to GLib 2.58 by
Simon McVittie.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
[Backport to 2.58.x: replace g_local_file_fstat with fstat]
[Backport to 2.58.x: replace g_local_file_lstat with lstat]
[Backport to 2.58.x: replace _g_stat_mode with direct access to st_mode]
[Backport to 2.58.x: don't call g_test_summary()]
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://gitlab.gnome.org/GNOME/glib/-/issues/2325
Bug-Debian: https://bugs.debian.org/984969
glocalfileoutputstream Add a missing O_CLOEXEC flag to re.patch | (download)

gio/glocalfileoutputstream.c | 15 12 + 3 - 0 !
1 file changed, 12 insertions(+), 3 deletions(-)

 glocalfileoutputstream: add a missing o_cloexec flag to replace()

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Bug: https://gitlab.gnome.org/GNOME/glib/-/issues/2325
Bug-Debian: https://bugs.debian.org/984969
glocalfileoutputstream Tidy up error handling.patch | (download)

gio/glocalfileoutputstream.c | 33 17 + 16 - 0 !
1 file changed, 17 insertions(+), 16 deletions(-)

 glocalfileoutputstream: tidy up error handling

After the recent reworking of this code it was possible for `g_close()`
to be called on `fd == -1`, which is invalid. It would have reported an
error, were errors not ignored. So it was harmless, but still best to
fix.

Simplify the error handling by combining both error labels and checking
the state of `fd` dynamically.

Coverity CID: #1450834

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Bug: https://gitlab.gnome.org/GNOME/glib/-/issues/2325
Bug-Debian: https://bugs.debian.org/984969
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