Bug#1051373: libglib2.0-0: 2.77.3-1 breaks Midnight Commander extension file
See upstream report https://gitlab.gnome.org/GNOME/glib/-/issues/3095#note_1839091, which will be fixed upstream for 2.78.0, which is due to be released in the next couple of days. Philip On Wed, 2023-09-06 at 22:49 +, Michael Gold wrote: > Package: libglib2.0-0 > Version: 2.77.3-1 > Severity: important > > Dear Maintainer, > > After upgrading libglib2.0-0 from 2.77.2-1 to 2.77.3-1, I'm no longer > able to open files by selecting them in Midnight Commander and > pressing > Enter. A change in the behaviour of g_key_file_get_string() appears > to > be the cause. For example, one section of the mc.ext.ini file > contains: > [pdf] > Regex=\.(pdf|PDF|ps|djvu)$ > Open=pdf %f & > > With the new package, a call to g_key_file_get_string() for the > "Regex" > value returns NULL. If I pre-load the old library version, it > returns > the string, and mc executes the specified command if I press Enter > with > a PDF file selected. > > The package version of "mc" is "3:4.8.29-2". > > - Michael > > > -- System Information: > Debian Release: trixie/sid > APT prefers unstable-debug > APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, > 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.4.0-4-amd64 (SMP w/32 CPU threads; PREEMPT) > Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), > LANGUAGE=en_CA:en > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages libglib2.0-0 depends on: > ii libc6 2.37-7 > ii libffi8 3.4.4-1 > ii libmount1 2.39.2-1 > ii libpcre2-8-0 10.42-4 > ii libselinux1 3.5-1 > ii zlib1g 1:1.2.13.dfsg-3 > > Versions of packages libglib2.0-0 recommends: > ii libglib2.0-data 2.77.3-1 > ii shared-mime-info 2.2-1 > ii xdg-user-dirs 0.18-1 > > Versions of packages libglib2.0-0 suggests: > pn low-memory-monitor > > -- no debconf information
Bug#1028475: Backport recent GVariant security fixes to Stable
On Sat, 2023-01-14 at 21:15 +0100, Salvatore Bonaccorso wrote: > Hi Simon, > > Thank you for adding looping in. > > On Thu, Jan 12, 2023 at 10:10:35AM +, Simon McVittie wrote: > > Control: tags -1 + security > > > > On Wed, 11 Jan 2023 at 16:37:01 +, Philip Withnall wrote: > > > Are there plans to backport the recent GVariant security fixes to > > > Debian Stable? > > > > > > These are: > > > - https://gitlab.gnome.org/GNOME/glib/-/issues/2782 > > > - https://gitlab.gnome.org/GNOME/glib/-/issues/2121 > > > - https://gitlab.gnome.org/GNOME/glib/-/issues/2540 > > > - https://gitlab.gnome.org/GNOME/glib/-/issues/2794 > > > - https://gitlab.gnome.org/GNOME/glib/-/issues/2797 > > > - https://gitlab.gnome.org/GNOME/glib/-/issues/2840 > > > - https://gitlab.gnome.org/GNOME/glib/-/issues/2841 > > > > > > In addition, these two issues have highly related fixes (which > > > it’s > > > probably easiest to backport in the same tranche), but they are > > > not > > > security issues: > > > - https://gitlab.gnome.org/GNOME/glib/-/issues/2612 > > > - https://gitlab.gnome.org/GNOME/glib/-/issues/2839 > > > > > > Apologies if a decision has been deliberately taken to not > > > backport > > > them, I don’t fully understand the criteria for what gets > > > backported. > > > > There are actually two sets of criteria for what gets backported to > > stable. If the Debian security team (Cc'd) thinks an issue is > > sufficiently > > serious to need a security advisory and an immediate release, then > > they > > prepare a security update, either doing the work themselves or > > coordinating > > with the package's maintainer for the actual code changes. > > > > If the security team are not interested in an issue, but the > > package's > > maintainer thinks the issue needs a stable update, then the > > package's > > maintainer coordinates with the release team to get the change into > > the > > next stable point release, which happens once per 1-2 months. > > > > I think these issues are all denial-of-service, which the security > > team > > usually treats as not sufficiently important for an advisory and an > > off-schedule fix. Security team: do you agree, based on the > > information > > quoted below? If yes, we can treat this as a low-priority security > > fix > > (I would personally rate its severity at somewhere between > > important > > and minor) and fix it in a point release later. > > I do agree, a point release update seems enough (if feasible, in > backport size and confidence). Makes sense to me. Thanks both for considering this. Philip
Bug#1028475: Backport recent GVariant security fixes to Stable
Package: glib2.0
Version: 2.66.8-1
Tags: security
Are there plans to backport the recent GVariant security fixes to
Debian Stable?
These are:
- https://gitlab.gnome.org/GNOME/glib/-/issues/2782
- https://gitlab.gnome.org/GNOME/glib/-/issues/2121
- https://gitlab.gnome.org/GNOME/glib/-/issues/2540
- https://gitlab.gnome.org/GNOME/glib/-/issues/2794
- https://gitlab.gnome.org/GNOME/glib/-/issues/2797
- https://gitlab.gnome.org/GNOME/glib/-/issues/2840
- https://gitlab.gnome.org/GNOME/glib/-/issues/2841
In addition, these two issues have highly related fixes (which it’s
probably easiest to backport in the same tranche), but they are not
security issues:
- https://gitlab.gnome.org/GNOME/glib/-/issues/2612
- https://gitlab.gnome.org/GNOME/glib/-/issues/2839
Apologies if a decision has been deliberately taken to not backport
them, I don’t fully understand the criteria for what gets backported.
---
There are two sets of risks in these issues:
1. Denial of service caused by handling a malicious serialised variant
which is structured to cause allocations or looping superlinear to its
serialised size. Applications are at risk if they accept untrusted
serialised variants by checking them with g_variant_get_normal_form()
(or don’t check them). Applications which reject variants with
g_variant_is_normal_form() first are not vulnerable. In order to be
exploitable, the variant must have a dynamically typed component in it
(i.e. a `v` type somewhere). This is typically as part of an `a{sv}`.
2. Denial of service caused by handling a malicious text-form variant
which is structured to cause looping superlinear to its text size.
Applications are at risk if they parse untrusted text-form variants.
Scenario 2 is much less likely than scenario 1, as the GVariant text-
form parser is not documented as suitable for use on untrusted input.
Scenario 1 is likely because g_variant_get_normal_form() *is*
documented as being safe to use on untrusted input.
Issue #2840 documents a heap buffer overflow, but this vulnerability
was introduced as part of the fixes for the above two scenarious, so
GLib is only vulnerable to the overflow if an incomplete set of patches
are backported.
---
I have a set of backport commits for this for GLib 2.70.4, which we are
using in Endless OS. At a quick glance, these commits should also be
most of the work needed for backporting to 2.66.8 in Debian Stable. I
am happy to help out with this if that’s useful.
Philip
Bug#997824: evolution-data-server: Backport patches to switch from Google Contacts API to CalDAV to stable
Package: evolution-data-server Version: 3.38.3-1 Severity: important Dear Maintainer, Please consider backporting patches from Debian testing/unstable to stable to switch Evolution and EDS to use CalDAV for accessing Google Contacts. The current method of accessing it, the Google Contacts API, is deprecated and will effectively be turned off in December 2021. This will make all requests (from existing and new users) for calendar data fail. The necessary patches are here: * https://salsa.debian.org/gnome-team/evolution/-/merge_requests/3 * https://salsa.debian.org/gnome-team/evolution-data-server/-/merge_requests/5 I am reporting this via reportbug as there appear to be several existing MRs (for unrelated issues) in salsa.debian.org for Evolution and EDS which have gone unanswered, so I’m guessing the Evo/EDS package maintainers don’t check salsa. -- System Information: Distributor ID: Endless Description:Endless 5.0.0 Release:5.0.0 Codename: n/a Architecture: x86_64 Kernel: Linux 5.11.0-35-generic (SMP w/1 CPU thread) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages evolution-data-server depends on: ii evolution-data-server-common 3.38.3-1 ii gnome-keyring 3.36.0-1 ii libc6 2.31-13+deb11u2 ii libcamel-1.2-62 3.38.3-1 ii libcanberra-gtk3-00.30-7 ii libcanberra0 0.30-7 ii libdb5.3 5.3.28+dfsg1-0.8 ii libebackend-1.2-103.38.3-1 ii libebook-1.2-20 3.38.3-1 ii libebook-contacts-1.2-3 3.38.3-1 ii libecal-2.0-1 3.38.3-1 ii libedata-book-1.2-26 3.38.3-1 ii libedata-cal-2.0-13.38.3-1 ii libedataserver-1.2-25 3.38.3-1 ii libedataserverui-1.2-23.38.3-1 ii libgcr-base-3-1 3.38.1-2 ii libgcr-ui-3-1 3.38.1-2 ii libgdata220.17.13-3 ii libglib2.0-0 2.66.8-1 ii libgoa-1.0-0b 3.38.1-2endless1bem1 ii libgtk-3-03.24.24-4 ii libgweather-3-16 3.36.1-3 ii libical3 3.0.9-2 ii libldap-2.4-2 2.4.57+dfsg-3 ii libpango-1.0-01.46.2-3 ii libsecret-1-0 0.20.4-2 ii libsoup2.4-1 2.72.0-2 ii libxml2 2.9.10+dfsg-6.7 evolution-data-server recommends no packages. Versions of packages evolution-data-server suggests: ii evolution 3.38.3-1 -- no debconf information
Bug#983026: libglib2.0-0: After update GDM3 does not longer start
This is https://gitlab.gnome.org/GNOME/glib/-/issues/2332 On Thu, 2021-02-18 at 10:57 +0100, Michael Ott wrote: > Package: libglib2.0-0 > Version: 2.67.4-1 > Severity: important > > Dear Maintainer, > > After update to 2.67.4 I cannot start GDM > > Output in syslog: > Feb 18 05:14:25 k-c13 gnome-shell[2055]: invalid (NULL) pointer > instance > Feb 18 05:14:25 k-c13 gnome-shell[2055]: g_signal_connect_data: > assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed > > with 2.67.3+git20210214-1 it works > > -- System Information: > Debian Release: bullseye/sid > APT prefers unstable > APT policy: (710, 'unstable'), (670, 'testing'), (660, > 'experimental'), (600, 'stable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386, armhf, arm64 > > Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads) > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), > LANGUAGE=en_GB:en > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages libglib2.0-0 depends on: > ii libc6 2.31-9 > ii libffi7 3.3-5 > ii libmount1 2.36.1-7 > ii libpcre3 2:8.39-13 > ii libselinux1 3.1-3 > ii zlib1g 1:1.2.11.dfsg-2 > > Versions of packages libglib2.0-0 recommends: > ii libglib2.0-data 2.67.3+git20210214-1 > ii shared-mime-info 2.0-1 > ii xdg-user-dirs 0.17-2 > > libglib2.0-0 suggests no packages. > > -- no debconf information >
Bug#944188: /etc/msmtprc password disclosure
On Wed, 3 Feb 2021 12:26:23 + Simon McVittie wrote: > For now, GLib upstream has partially reverted that change, weakening the > security hardening in order to fix the regression, and I'm going to do > the same in Debian. This should stop msmtp from regressing in terms of > which features work, but I cannot guarantee that it does not make msmtp > exploitable. If I find a concrete attack, I will report it privately to > the security team. From an upstream GLib point of view, we’re setting a timeline on when we’re going to revert the reversion and re-harden GLib against this. It’s being tracked in https://gitlab.gnome.org/GNOME/glib/-/issues/2316, and the reversion will be done in the 2.69/2.70 cycle. 2.70 is due to be released around September 2021. Debian can keep its partial reversion in the distro-specific patches for GLib indefinitely, but after 2.70 you will be diverging from upstream in that respect. Philip signature.asc Description: This is a digitally signed message part
Bug#962912: glib2.0: g_file_copy_attributes() chokes on binary xattr values
On Tue, 2020-06-16 at 02:44 +0200, Sergio Gelato wrote: > control: tags -1 + patch > > * Philip Withnall [2020-06-15 23:25:18 +0200]: > > https://gitlab.gnome.org/GNOME/glib/-/issues/422 > > > > Nobody has yet found time to work on it; merge requests are > > welcome! > > Here is a patch that works for me. Upstreamed as https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1568
Bug#962912: glib2.0: g_file_copy_attributes() chokes on binary xattr values
On Tue, 2020-06-16 at 02:44 +0200, Sergio Gelato wrote: > control: tags -1 + patch > > * Philip Withnall [2020-06-15 23:25:18 +0200]: > > https://gitlab.gnome.org/GNOME/glib/-/issues/422 > > > > Nobody has yet found time to work on it; merge requests are > > welcome! > > Here is a patch that works for me. Thanks. In order for it to go through the GLib CI, review process, and be properly attributed to you, could you please create a merge request for it upstream? https://gitlab.gnome.org/GNOME/glib/-/merge_requests/new Thanks, Philip
Bug#962912: glib2.0: g_file_copy_attributes() chokes on binary xattr values
On Mon, 2020-06-15 at 23:17 +0200, Sergio Gelato wrote: > Package: libglib2.0-0 > Version: 2.58.3-2+deb10u2 > Severity: important > > g_file_copy_attributes(), when invoked with G_FILE_COPY_ALL_METADATA > on > files in NFS, is prone to truncating the value of extended attribute > system.nfs4_acl. Here is an excerpt from strace output, showing the > getxattr() and setxattr() calls: It’s this issue upstream: https://gitlab.gnome.org/GNOME/glib/-/issues/422 Nobody has yet found time to work on it; merge requests are welcome! Philip
Bug#934655: libglib2.0-0: provide environment variable to suppress or redirect logging
On Tue, 2019-08-13 at 23:16 +, brian m. carlson wrote: > On 2019-08-13 at 06:12:30, Philip Withnall wrote: > > Hi, > > > > I can’t speak for the Debian project, but as an upstream GLib > > developer > > I can say such an environment variable would not be welcome > > upstream. > > > > Hiding such warnings makes them less likely to be fixed. It’s a way > > of > > sweeping bugs under the carpet which I don’t want to encourage. > > Each > > warning emitted by GTK or GLib indicates a non-trivial bug in the > > code > > which is calling it, which should be fixed. > > Unfortunately, it's often impossible to write code which works on > multiple versions of GTK+ without warnings. I took a version of GVim > which worked fine on Debian unstable with GTK+3 but produced copious > warnings on CentOS 7. This makes it difficult for folks who would > like > to upgrade one single component on a system without rebuilding the > entire GTK+ stack. In addition, an upgrade of GTK+ can cause > previously > working programs to produce errors where they did not before, causing > problems for users. I can believe that might be true in some cases, but I doubt it is *often* the case. Regardless, I encourage you to ask specific questions about the warnings you are encountering on https://discourse.gnome.org/ , and the GTK developers should be able to advise appropriately for each case. > In addition, Unix programs typically produce output to standard error > to > reflect a user-relevant error: something that the user has done wrong > or > that prevents the program from functioning in the way the user > requested. These warnings are not user relevant: they reflect a > developer error, not a problem that reflects a user-visible failure. > From the user perspective, everything is functioning as intended, so > output to standard error is not appropriate. > > And finally, overwhelmingly, developers take a long time to fix > warnings > like this, if they get fixed at all. Perhaps they don't see the use > case > of running graphical programs like PDF viewers from the command line. > More likely, they are overwhelmed with other issues and consider this > low priority. > > I appreciate that these reflect a defect in the program that should > be > fixed, but it isn't fair to force users to either fix these defects > for > themselves or deal with terminal junk. As a Git developer, I can tell > you people would be extremely unhappy if libpcre or libcurl produced > errors on their terminals when they ran Git, even if those were bugs > in > Git itself. I'm not sure why GLib should be different in this regard. Sorry, I think you’re conflating two different types of programs here. Command line applications like git have very different output requirements on stderr/stdout from graphical programs. Command line programs don’t normally use GTK, so shouldn’t see any of the warnings you mention above. I would be very surprised if command line programs using GLib (not GTK) emitted different warnings with different versions of GLib. If they do, can you please provide me with concrete examples and I can advise you about how to eliminate them. GTK and GLib are separate libraries. > Ultimately, I think it's most appropriate to let users decide for > themselves if they would like to see non-user-visible issues on their > terminal. I'm not even asking for this to be the default, just an > option > users can turn on. If it’s not on by default, almost all users will never find out about it. If your argument is that seeing the warnings is only useful for developers, then such an option should be on by default and developers would have to explicitly turn it off. In every situation where I’ve seen warnings (compile time, or run time) hidden from developers, those warnings have very rarely been fixed. Making them visible has increased the number of warnings which have been fixed. Filing bugs against applications, which point out specific warnings which need fixing is, I feel, a much better use of people’s time than inventing new and innovative ways to hide those warnings. Philip
Bug#934655: libglib2.0-0: provide environment variable to suppress or redirect logging
Hi, I can’t speak for the Debian project, but as an upstream GLib developer I can say such an environment variable would not be welcome upstream. Hiding such warnings makes them less likely to be fixed. It’s a way of sweeping bugs under the carpet which I don’t want to encourage. Each warning emitted by GTK or GLib indicates a non-trivial bug in the code which is calling it, which should be fixed. Philip On Mon, 2019-08-12 at 23:31 +, brian m. carlson wrote: > Package: libglib2.0-0 > Version: 2.60.6-1 > Severity: normal > > Currently, GLib and various other GTK+-related software provide > logging, > which goes to stdout or stderr. Much of this logging is developer > focused and basically warns developers that they are doing > questionable > things that one or another toolkit is unhappy with. > > While this is great for debugging and developer visibility, it's not > great for end users who invoke GTK+-based programs from the terminal, > where the messages obscure previous output, sometimes scrolling the > screen significantly. In the past, GVim has been bitten by this > prominently, but various other software, including atril (a PDF > viewer) > and other tools commonly run from the command line, have fallen > victim > to it as well. The most inconvenient part for users is that upgrading > one of the shared libraries a piece of software uses can cause it to > emit many more warnings than before, with little recourse. > > Asking individual packages to fix these issues is not effective, > because, as is the nature with open source, developers lack the time > to > effectively fix all issues, and these issues are seen as purely > cosmetic. I've asked several packages to do so, and the turnaround > time > for fixing these issues is usually measured in years, if they are > fixed > at all. > > GLib should learn an environment variable to either suppress non- > fatal > messages (i.e., those that do not cause the program to abort) or > redirect them to a file (e.g., /dev/null). Even if upstream does not > want this feature, Debian should provide it. > > This is a common issue with multiple questions online, and would > provide > a large amount of value to users. > > -- System Information: > Debian Release: bullseye/sid > APT prefers unstable-debug > APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, > 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, > 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages libglib2.0-0 depends on: > ii libc62.28-10 > ii libffi6 3.2.1-9 > ii libmount12.34-0.1 > ii libpcre3 2:8.39-12+b1 > ii libselinux1 2.9-2+b2 > ii zlib1g 1:1.2.11.dfsg-1+b1 > > Versions of packages libglib2.0-0 recommends: > ii libglib2.0-data 2.60.6-1 > ii shared-mime-info 1.10-1 > ii xdg-user-dirs 0.17-2 > > libglib2.0-0 suggests no packages. > > -- no debconf information >
Bug#924344: glib2.0: CVE-2019-9633
On Wed, 2019-04-03 at 13:00 +0100, Simon McVittie wrote: > On Fri, 29 Mar 2019 at 20:13:17 +0100, Moritz Mühlenhoff wrote: > > On Mon, Mar 11, 2019 at 09:32:02PM +0100, Salvatore Bonaccorso > > wrote: > > > Version: 2.58.3-1 > > Do we know for sure that 2.58.x is vulnerable? I've tried the > reproducer > from the upstream bug and didn't see criticals or a crash. > > > > Forwarded: https://gitlab.gnome.org/GNOME/glib/issues/1649 > > This bug says "Another likely regression from Happy Eyeballs". GLib's > implementation of RFC 8305 "Happy Eyeballs" is a new feature (or new > optimization, depending how you look at it) in 2.59.x/2.60.x. Yeah, this bug should be present in 2.59.x where (x < 2). It was fixed by commit d553d92d6e9f53cbe5a34166fcb919ba652c6a8e, which is present in 2.59.2 onwards. The bug was not present in 2.58.x. I’ve left a comment about it here: https://gitlab.gnome.org/GNOME/glib/issues/1649#note_481826 Philip signature.asc Description: This is a digitally signed message part
Bug#908705: g_icon_to_string output includes some garbage prefix
On Wed, 2018-09-12 at 22:32 +0200, Eduard Bloch wrote: > Package: libglib2.0-0 > Version: 2.58.0-3 > Severity: important > > Hi, > > one of the last releases in the last couple of weeks has broken the > g_icon_to_string function. Previously, it did exactly what > https://developer.gnome.org/gio/stable/GIcon.html#g-icon-to-string > said > and returned a proper short name or absolute path. > > Now, it returns some nonsense, after this pattern: > . GThemedIcon mpv mpv-symbolic > > That's crap. For the example above, > /usr/share/applications/mpv.desktop > contains: > Icon=mpv > > And mpv is what I expect (following documentation) > > Repro: > > Run icewm-menu-fdo (from icewm-common package) and see a lot of those > strings there except of the plain icon name. See https://gitlab.gnome.org/GNOME/glib/issues/1513. Philip signature.asc Description: This is a digitally signed message part
Bug#901887: build-depend should not list xtem
On Tue, 2018-06-19 at 16:20 -0400, Phillip Susi wrote: > Package: glib2.0 > Version: 2.56.1-2 > > I noticed while trying to build glib that it claims to build-depend > on > xterm, which is insane; no package should require xterm to build. I > forced it to build anyway without xterm installed, and it built fine, > so > this dependency should be removed. I suspect it was needed from before the following two upstream bugs were fixed, and is now safe to remove: https://bugzilla.gnome.org/show_bug.cgi?id=786580 https://bugzilla.gnome.org/show_bug.cgi?id=790914 Philip signature.asc Description: This is a digitally signed message part
