Update to 2.78.0
This commit is contained in:
parent
6995c02c20
commit
bfcaf32a42
83
3565.patch
83
3565.patch
@ -1,83 +0,0 @@
|
||||
From 4a9672764214d5fab569b774fe761ae7d2ec11d9 Mon Sep 17 00:00:00 2001
|
||||
From: Philip Withnall <philip@tecnocode.co.uk>
|
||||
Date: Wed, 6 Sep 2023 12:08:56 +0100
|
||||
Subject: [PATCH] gkeyfile: Temporarily re-allow invalid escapes when parsing
|
||||
strings
|
||||
MIME-Version: 1.0
|
||||
Content-Type: text/plain; charset=UTF-8
|
||||
Content-Transfer-Encoding: 8bit
|
||||
|
||||
Before commit 71b7efd08a1feadc8ddca31e164034b1f5a6bd74, `GKeyFile`
|
||||
incorrectly allowed invalid escape sequences: it would treat the
|
||||
sequence as a literal, set a `GError`, but not return failure from the
|
||||
function. So if a caller was explicitly checking for returned `GError`s,
|
||||
they could detect the invalid escape; but if they were just checking the
|
||||
function’s return value, they’d miss it.
|
||||
|
||||
This is not correct use of `GError`, and the [Desktop Entry
|
||||
Spec](https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s04.html)
|
||||
doesn’t allow for invalid escape sequences to be accepted. So it’s wrong
|
||||
in both ways.
|
||||
|
||||
However, the commit above changed this behaviour without realising it,
|
||||
quite close to the 2.78 stable release deadline. There are numerous key
|
||||
files in the wild which use invalid escape sequences, and it’s too late
|
||||
in the cycle to ‘break’ parsing of all of them.
|
||||
|
||||
So, for now, revert to the old behaviour for invalid escape sequences,
|
||||
and give people another cycle to adapt to the changes. This will likely
|
||||
mean they end up calling `g_key_file_get_value()` rather than
|
||||
`g_key_file_get_string()`. See
|
||||
https://gitlab.gnome.org/GNOME/glib/-/issues/3098 for tracking
|
||||
re-enabling the error handling for invalid escape sequences.
|
||||
|
||||
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
|
||||
|
||||
Fixes: #3095
|
||||
See: #3098
|
||||
---
|
||||
glib/gkeyfile.c | 17 ++++++++++++++++-
|
||||
1 file changed, 16 insertions(+), 1 deletion(-)
|
||||
|
||||
diff --git a/glib/gkeyfile.c b/glib/gkeyfile.c
|
||||
index 68130fead9..d08a485c06 100644
|
||||
--- a/glib/gkeyfile.c
|
||||
+++ b/glib/gkeyfile.c
|
||||
@@ -4351,6 +4351,7 @@ g_key_file_parse_value_as_string (GKeyFile *key_file,
|
||||
break;
|
||||
|
||||
case '\0':
|
||||
+ g_clear_error (error);
|
||||
g_set_error_literal (error, G_KEY_FILE_ERROR,
|
||||
G_KEY_FILE_ERROR_INVALID_VALUE,
|
||||
_("Key file contains escape character "
|
||||
@@ -4373,11 +4374,25 @@ g_key_file_parse_value_as_string (GKeyFile *key_file,
|
||||
sequence[1] = *p;
|
||||
sequence[2] = '\0';
|
||||
|
||||
+ /* FIXME: This should be a fatal error, but there was a
|
||||
+ * bug which prevented that being reported for a long
|
||||
+ * time, so a lot of applications and in-the-field key
|
||||
+ * files use invalid escape sequences without anticipating
|
||||
+ * problems. For now (GLib 2.78), message about it; in
|
||||
+ * future, the behaviour may become fatal again.
|
||||
+ *
|
||||
+ * The previous behaviour was to set the #GError but not
|
||||
+ * return failure from the function, so the caller could
|
||||
+ * explicitly check for invalid escapes, but also ignore
|
||||
+ * the error if they want. This is not how #GError is
|
||||
+ * meant to be used, but the #GKeyFile code is very old.
|
||||
+ *
|
||||
+ * See https://gitlab.gnome.org/GNOME/glib/-/issues/3098 */
|
||||
+ g_clear_error (error);
|
||||
g_set_error (error, G_KEY_FILE_ERROR,
|
||||
G_KEY_FILE_ERROR_INVALID_VALUE,
|
||||
_("Key file contains invalid escape "
|
||||
"sequence “%s”"), sequence);
|
||||
- goto error;
|
||||
}
|
||||
}
|
||||
break;
|
||||
--
|
||||
GitLab
|
||||
|
@ -1,11 +1,11 @@
|
||||
Name: glib2
|
||||
Version: 2.77.3
|
||||
Version: 2.78.0
|
||||
Release: %autorelease
|
||||
Summary: A library of handy utility functions
|
||||
|
||||
License: LGPL-2.1-or-later
|
||||
URL: https://www.gtk.org
|
||||
Source: https://download.gnome.org/sources/glib/2.77/glib-%{version}.tar.xz
|
||||
Source: https://download.gnome.org/sources/glib/2.78/glib-%{version}.tar.xz
|
||||
|
||||
# Required for RHEL core crypto components policy. Good for Fedora too.
|
||||
# https://bugzilla.redhat.com/show_bug.cgi?id=1630260
|
||||
@ -16,9 +16,6 @@ Patch: gnutls-hmac.patch
|
||||
# the baremetal Docker is updated there i.e. lets be a little bit pragmatic...
|
||||
Patch: gspawn-eperm.patch
|
||||
|
||||
# https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3565
|
||||
Patch: 3565.patch
|
||||
|
||||
BuildRequires: gcc
|
||||
BuildRequires: gcc-c++
|
||||
BuildRequires: gettext
|
||||
|
2
sources
2
sources
@ -1 +1 @@
|
||||
SHA512 (glib-2.77.3.tar.xz) = d9727d67e63d7f8ce710bff497c183799b0192ac10900da87887bd76812aad9603e7f132d7eb4e8626787c427048aeafb4a28654ab808c676bcfc2b897e005d9
|
||||
SHA512 (glib-2.78.0.tar.xz) = 3d06890002f4b13f831c83fbb70cfce529f9750e30888619e4d6277116be15d106379a03143412cf4b2a289c0cbdbbc299ecf17284fbffc06c791ecf7556c765
|
||||
|
Loading…
Reference in New Issue
Block a user