Package: glib2.0 / 2.50.3-2+deb9u2

Metadata

Package Version Patches format
glib2.0 2.50.3-2+deb9u2 3.0 (quilt)

Patch series

view the series file
Patch File delta Description
01_gettext desktopfiles.patch | (download)

glib/gkeyfile.c | 71 71 + 0 - 0 !
glib/gkeyfile.h | 3 3 + 0 - 0 !
2 files changed, 74 insertions(+)

 add some description
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
# UbuntuSpecific: 01_gettext-desktopfiles.patch was changed to use X-GNOME-, so this is necessary until all our .desktop files are converted
03_disble_glib_compile_schemas_warning.patch | (download)

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

 disable confusing (to users) warning about deprecated schema paths
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 to override the passwd entry
 This will allow to fix various kinds of build failures due to restricted
 build environments.
06_thread_test_ignore_prctl_fail.patch | (download)

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

 do not fail the /thread/thread4 test if prctrl() fails. this happens on the debian buildds.
07_disable_tests_on_slow_archs.patch | (download)

gio/tests/gdbus-threading.c | 2 2 + 0 - 0 !
gio/tests/socket.c | 2 2 + 0 - 0 !
glib/tests/mainloop.c | 4 4 + 0 - 0 !
glib/tests/timeout.c | 2 2 + 0 - 0 !
4 files changed, 10 insertions(+)

 disable tests on slow architectures which keep failing the tests.
61_glib compile binaries path.patch | (download)

gio-2.0.pc.in | 4 2 + 2 - 0 !
1 file 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.
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
Date: Sat, 16 Jul 2011 13:12:48 -0700

skip brokwn dbus appinfo test.patch | (download)

gio/tests/Makefile.am | 1 0 + 1 - 0 !
1 file changed, 1 deletion(-)

 the dbus-appinfo test hangs in a build environment (with no x server)
Do not attempt to autolaunch a session dbus daemon w.patch | (download)

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

 [patch] do not attempt to autolaunch a session dbus-daemon with no
 DISPLAY

The two known use-cases for autolaunching are:

* X-forwarding: "ssh -Y myhost myapp" resulting in a
  session bus on myhost but an X server on the original host

* Legacy desktop environments on OSs without D-Bus integration:
  e.g. running a single GNOME or KDE app under fvwm or something,
  without a session dbus-daemon being started by either systemd,
  gnome-session, or OS integration scripts analogous to Debian's
  /etc/X11/Xsession.d/75dbus_dbus-launch

In either case, an X11 DISPLAY is also needed.

"dbus-launch --autolaunch" doesn't do anything useful when unable
to connect to an X11 display; this has been the case since the feature
was added in 2006, and is useful to avoid "split brain" situations in
which two processes that ought to be part of the same session end up
on separate session buses. Since dbus commit 407c111 in 2011,
libdbus hasn't even attempted to run "dbus-launch --autolaunch"
unless getenv("DISPLAY") returns non-null in the parent: this avoids
doing a relatively complicated fork-and-exec that is clearly not
going to lead to success. This commit gives GDBus the same policy.

In Debian, I've encountered GLib test failures in
gio/tests/gapplication.c which appear to be related to the
fork-and-exec for dbus-launch (Debian bug #737380). Specifically,
one test-case ends by calling g_test_dbus_unset(), and the next
test-case tries to access the session bus with DBUS_SESSION_BUS_ADDRESS
unset, resulting in an attempt to autolaunch. Checking for DISPLAY
avoids this attempt to autolaunch, since g_test_dbus_unset() also
unsets DISPLAY. It seems likely that there is some orthogonal bug here,
perhaps involving g_spawn_sync() in the GDBus thread racing with
g_spawn_async_with_pipes() in the main thread, but GApplication is
probably not the ideal place to debug that.

In my opinion as D-Bus maintainer, "dbus-launch --autolaunch" should
be considered to be an X11 feature, and any future D-Bus enhancements
(e.g. kdbus) or successors for X11 (e.g. Wayland, Mir) should obtain
a session bus address by other means - either a session manager
such as "systemd --user", gnome-session or Upstart, or a wrapper
for the user session like dbus-run-session(1).

Related to dbus bug <https://bugs.freedesktop.org/show_bug.cgi?id=19997>.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=723506
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737380

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(-)

 [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.

https://bugzilla.gnome.org/show_bug.cgi?id=722604

skip broken timer test.patch | (download)

glib/tests/timer.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 skip test which performs some unreliable floating point comparisons
0001 Fix trashing on overlayfs.patch | (download)

gio/glocalfile.c | 20 19 + 1 - 0 !
1 file changed, 19 insertions(+), 1 deletion(-)

 [patch] fix trashing on overlayfs

In order to determine whether to trash a file to the home directory, we
compare its st_dev to our home directory's st_dev field.

This is the wrong thing to do on overlayfs when deleting files, because
st_dev contains the ID of the filesystem providing the file (which can
be the lower or upper filesystem), but directories always return the ID
of the overlayfs. Thus the comparison fails and we are unable to trash
the file.

Fix this by checking st_dev of the parent directory when we are deleting
a file.

tests gdatetime Use a real rather than invented time.patch | (download)

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

 [patch] tests/gdatetime: use a real rather than invented timezone

The tzdata maintainers had previously invented abbreviations for
timezones. As of their 2017a release, the one we were testing ("BRT")
has been dropped.

Switch to testing PST, which is a real timezone abbreviation.

https://bugzilla.gnome.org/show_bug.cgi?id=779799
(cherry picked from commit ec02a1875f29ecb8e46c0d8c1403cd00a0b3a9e4)

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 | 8 6 + 2 - 0 !
1 file changed, 6 insertions(+), 2 deletions(-)

 keyfile settings: use tighter permissions

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

Bug: https://gitlab.gnome.org/GNOME/glib/issues/1658
gmarkup Fix unvalidated UTF 8 read in markup parsing erro.patch | (download)

glib/gmarkup.c | 14 13 + 1 - 0 !
glib/tests/Makefile.am | 2 1 + 1 - 0 !
glib/tests/markups/fail-50.expected | 1 1 + 0 - 0 !
glib/tests/markups/fail-50.gmarkup | 1 1 + 0 - 0 !
4 files changed, 16 insertions(+), 2 deletions(-)

 gmarkup: fix unvalidated utf-8 read in markup parsing error paths
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

When formatting the error messages for markup parsing errors, the parser
was unconditionally reading a UTF-8 character from the input buffer —
but the buffer might end with a partial code sequence, resulting in
reading off the end of the buffer by up to three bytes.

Fix this and add a test case, courtesy of pdknsk.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Bug: https://gitlab.gnome.org/GNOME/glib/issues/1361
Bug: https://gitlab.gnome.org/GNOME/glib/issues/1462
gmarkup Avoid reading off the end of a buffer when non nu.patch | (download)

glib/gmarkup.c | 30 20 + 10 - 0 !
1 file changed, 20 insertions(+), 10 deletions(-)

 gmarkup: avoid reading off the end of a buffer when
 non-nul-terminated

When extracting a UTF-8 character to put in an error message on parse
failure, pass the remaining buffer length to utf8_str() to avoid it
running off the end of the input buffer. It previously assumed that the
buffer was nul-terminated, which was the case in all the tests until
now.

A following commit will add test coverage for this.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
(cherry picked from commit 8cfe53f081f8147cd3c36aebf64c635e04d3ab09)

gmarkup Fix crash in error handling path for closing elem.patch | (download)

glib/gmarkup.c | 11 8 + 3 - 0 !
glib/tests/Makefile.am | 1 1 + 0 - 0 !
glib/tests/markups/fail-51.expected | 1 1 + 0 - 0 !
glib/tests/markups/fail-51.gmarkup | 1 1 + 0 - 0 !
4 files changed, 11 insertions(+), 3 deletions(-)

 gmarkup: fix crash in error handling path for closing elements
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

If something which looks like a closing tag is left unfinished, but
isn’t paired to an opening tag in the document, the error handling code
would do a null pointer dereference. Avoid that, at the cost of
introducing a new translatable error message.

Includes a test case, courtesy of pdknsk.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Bug: https://gitlab.gnome.org/GNOME/glib/issues/1364
Bug: https://gitlab.gnome.org/GNOME/glib/issues/1461
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