public inbox for git-commits@fedoraproject.org
help / color / mirror / Atom feed
From: Michael Catanzaro <mcatanzaro@redhat.com>
To: git-commits@fedoraproject.org
Subject: [rpms/glib2] cve-2026-58016-f44: Remove gspawn-eperm patchset
Date: Tue, 11 Aug 2026 10:38:13 GMT	[thread overview]
Message-ID: <178644469387.1.11572501377695424267.rpms-glib2-11c7fe1165ae@fedoraproject.org> (raw)

            A new commit has been pushed.

            Repo   : rpms/glib2
            Branch : cve-2026-58016-f44
            Commit : 11c7fe1165ae0cb2ddd6c671160a78b4a70e4c5d
            Author : Michael Catanzaro <mcatanzaro@redhat.com>
            Date   : 2024-05-07T14:35:36-05:00
            Stats  : +0/-66 in 2 file(s)
            URL    : https://src.fedoraproject.org/rpms/glib2/c/11c7fe1165ae0cb2ddd6c671160a78b4a70e4c5d?branch=cve-2026-58016-f44

            Log:
            Remove gspawn-eperm patchset

Nobody seems to know whether this is still required or not. Probably
not. And even if it is still required, Fedora cannot carry workarounds
for old Docker versions forever.

---
diff --git a/glib2.spec b/glib2.spec
index 77dda5f..8dd53e4 100644
--- a/glib2.spec
+++ b/glib2.spec
@@ -12,10 +12,6 @@ Source:         https://download.gnome.org/sources/glib/2.80/glib-%{version}.tar
 # https://gitlab.gnome.org/GNOME/glib/-/merge_requests/903
 Patch:          gnutls-hmac.patch
 
-# recent close_range() changes break CircleCI and GitHub actions -- we can remove this when
-# the baremetal Docker is updated there i.e. lets be a little bit pragmatic...
-Patch:          gspawn-eperm.patch
-
 BuildRequires:  gcc
 BuildRequires:  gcc-c++
 BuildRequires:  gettext

diff --git a/gspawn-eperm.patch b/gspawn-eperm.patch
deleted file mode 100644
index 0d240bb..0000000
--- a/gspawn-eperm.patch
+++ /dev/null
@@ -1,62 +0,0 @@
-From 24de599887f641271ea279a0421776990075b714 Mon Sep 17 00:00:00 2001
-From: David King <amigadave@amigadave.com>
-Date: Tue, 12 Mar 2024 10:15:03 +0000
-Subject: [PATCH] gspawn: Additionally handle EPERM
-
-Handle old broken versions of Docker and libseccomp which do not
-recognise close_range().
-
-https://github.com/opencontainers/runc/issues/2151
-https://salsa.debian.org/debian/libseccomp/-/blob/debian/bullseye/debian/patches/syscalls_add_close_range_syscall.patch
-
-Based on a patch by Richard Hughes.
----
- glib/glib-unix.c | 23 +++++++++++++++++++----
- 1 file changed, 19 insertions(+), 4 deletions(-)
-
-diff --git a/glib/glib-unix.c b/glib/glib-unix.c
-index 7cb76dd33..9b2dfe2d9 100644
---- a/glib/glib-unix.c
-+++ b/glib/glib-unix.c
-@@ -835,9 +835,18 @@ g_fdwalk_set_cloexec (int lowfd)
-    *
-    * Handle ENOSYS in case it’s supported in libc but not the kernel; if so,
-    * fall back to safe_fdwalk(). Handle EINVAL in case `CLOSE_RANGE_CLOEXEC`
--   * is not supported. */
-+   * is not supported.
-+   *
-+   * Also handle EPERM for the cases where GLi is running under broken versions
-+   * of Docker+libseccomp which don't recognise `close_range()` so block calls
-+   * to it under a default security policy which returns EPERM rather than (the
-+   * correct) ENOSYS. This workaround should be carried in distributions until
-+   * they have versions of libseccomp and Docker which contain:
-+   *  - https://salsa.debian.org/debian/libseccomp/-/blob/debian/bullseye/debian/patches/syscalls_add_close_range_syscall.patch
-+   *  - https://github.com/opencontainers/runc/issues/2151
-+   */
-   ret = close_range (lowfd, G_MAXUINT, CLOSE_RANGE_CLOEXEC);
--  if (ret == 0 || !(errno == ENOSYS || errno == EINVAL))
-+  if (ret == 0 || !(errno == ENOSYS || errno == EINVAL || errno == EPERM))
-     return ret;
- #endif  /* HAVE_CLOSE_RANGE */
- 
-@@ -882,9 +891,15 @@ g_closefrom (int lowfd)
-    * situations: https://bugs.python.org/issue38061
-    *
-    * Handle ENOSYS in case it’s supported in libc but not the kernel; if so,
--   * fall back to safe_fdwalk(). */
-+   * fall back to safe_fdwalk().
-+   *
-+   * Also handle EPERM for the cases where GLib is running under broken versions
-+   * of Docker+libseccomp which don’t recognise `close_range()` so block calls
-+   * to it under a default security policy which returns EPERM rather than (the
-+   * correct) ENOSYS.
-+   */
-   ret = close_range (lowfd, G_MAXUINT, 0);
--  if (ret == 0 || errno != ENOSYS)
-+  if (ret == 0 || !(errno == ENOSYS || errno == EPERM))
-     return ret;
- #endif  /* HAVE_CLOSE_RANGE */
- 
--- 
-2.44.0
-

                 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=178644469387.1.11572501377695424267.rpms-glib2-11c7fe1165ae@fedoraproject.org \
    --to=mcatanzaro@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