gkeyfile: Temporarily re-allow invalid escapes when parsing strings

Backport an upstream patch to temporarily revert changed \\ behaviour in
keyfiles.

https://bugzilla.redhat.com/show_bug.cgi?id=2237562

3565.patch

@@ -0,0 +1,83 @@
+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
+

glib2.spec

@@ -16,6 +16,9 @@ Patch0: gnutls-hmac.patch
 # the baremetal Docker is updated there i.e. lets be a little bit pragmatic...
 Patch2: gspawn-eperm.patch
 
+# https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3565
+Patch3: 3565.patch
+
 BuildRequires: gcc
 BuildRequires: gcc-c++
 BuildRequires: gettext