public inbox for git-commits@fedoraproject.org
help / color / mirror / Atom feed
From: Kalev Lember <klember@redhat.com>
To: git-commits@fedoraproject.org
Subject: [rpms/glib2] cve-2026-58016-f44: Update to 2.78.0
Date: Tue, 11 Aug 2026 10:38:03 GMT	[thread overview]
Message-ID: <178644468318.1.16865322758263707170.rpms-glib2-bfcaf32a42c7@fedoraproject.org> (raw)

A new commit has been pushed.

Repo   : rpms/glib2
Branch : cve-2026-58016-f44
Commit : bfcaf32a42c71fdf62935f700452c4382973f41f
Author : Kalev Lember <klember@redhat.com>
Date   : 2023-09-16T21:35:32+02:00
Stats  : +3/-89 in 3 file(s)
URL    : https://src.fedoraproject.org/rpms/glib2/c/bfcaf32a42c71fdf62935f700452c4382973f41f?branch=cve-2026-58016-f44

Log:
Update to 2.78.0

---
diff --git a/3565.patch b/3565.patch
deleted file mode 100644
index a93a0dd..0000000
--- a/3565.patch
+++ /dev/null
@@ -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
-

diff --git a/glib2.spec b/glib2.spec
index 375d3c3..7ba2786 100644
--- a/glib2.spec
+++ b/glib2.spec
@@ -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

diff --git a/sources b/sources
index bce19a9..1b07ded 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (glib-2.77.3.tar.xz) = d9727d67e63d7f8ce710bff497c183799b0192ac10900da87887bd76812aad9603e7f132d7eb4e8626787c427048aeafb4a28654ab808c676bcfc2b897e005d9
+SHA512 (glib-2.78.0.tar.xz) = 3d06890002f4b13f831c83fbb70cfce529f9750e30888619e4d6277116be15d106379a03143412cf4b2a289c0cbdbbc299ecf17284fbffc06c791ecf7556c765

                 reply	other threads:[~2026-08-11 10:38 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=178644468318.1.16865322758263707170.rpms-glib2-bfcaf32a42c7@fedoraproject.org \
    --to=klember@redhat.com \
    --cc=git-commits@fedoraproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox