Bug#1076554: Regression: error parsing URL //: Invalid host/port
Package: apache2 Version: 2.4.61-1~deb12u1 Severity: important Dear Maintainer, Following DSA 5729-1 (2.4.61-1~deb12u1), access to Sympa broke. User error: Bad Request Log error: AH01059: error parsing URL //: Invalid host/port I believe the issue is related to this line: SetHandler "proxy:unix:/run/sympa/wwsympa.socket|fcgi://" This is the default configuration from the sympa Debian package. I get the same result when compiling the debdiff from: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076531 (2.4.62) I can work-around the issue by appending 'localhost': SetHandler "proxy:unix:/run/sympa/wwsympa.socket|fcgi://localhost" (but this is still a regression in the stable release :)) -- Package-specific info: -- System Information: Debian Release: 12.6 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-23-cloud-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apache2 depends on: ii apache2-bin2.4.62-1~deb12u1~local ii apache2-data 2.4.62-1~deb12u1~local ii apache2-utils 2.4.62-1~deb12u1~local ii init-system-helpers1.65.2 ii lsb-base 11.6 ii media-types10.0.0 ii perl 5.36.0-7+deb12u1 ii procps 2:4.0.2-3 ii sysvinit-utils [lsb-base] 3.06-4 Versions of packages apache2 recommends: ii ssl-cert 1.1.2 Versions of packages apache2 suggests: pn apache2-doc ii apache2-suexec-pristine 2.4.62-1~deb12u1~local pn www-browser Versions of packages apache2-bin depends on: ii libapr1 1.7.2-3 ii libaprutil1 1.6.3-1 ii libaprutil1-dbd-sqlite3 1.6.3-1 ii libaprutil1-ldap 1.6.3-1 ii libbrotli1 1.0.9-2+b6 ii libc62.36-9+deb12u7 ii libcrypt11:4.4.33-2 ii libcurl4 7.88.1-10+deb12u6 ii libjansson4 2.14-2 ii libldap-2.5-02.5.13+dfsg-5 ii liblua5.3-0 5.3.6-2 ii libnghttp2-141.52.0-1+deb12u1 ii libpcre2-8-0 10.42-1 ii libssl3 3.0.13-1~deb12u1 ii libxml2 2.9.14+dfsg-1.3~deb12u1 ii perl 5.36.0-7+deb12u1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages apache2-bin suggests: pn apache2-doc ii apache2-suexec-pristine 2.4.62-1~deb12u1~local pn www-browser Versions of packages apache2 is related to: ii apache2 2.4.62-1~deb12u1~local ii apache2-bin 2.4.62-1~deb12u1~local -- no debconf information
Bug#834059: dose-builddebcheck: outputs wrong yaml
Reported upstream at https://gitlab.com/irill/dose3/-/issues/18 :) -- Sylvain
Bug#1064063: plasma-workspace: CVE-2024-1433
Hi, According to my analysis only recent versions should be affected: https://salsa.debian.org/security-tracker-team/security-tracker/-/commit/7f8624b3c13f84e0233f8f893bce99090a7dd3a2 The tracker was updated to mark Debian non-affected: https://salsa.debian.org/security-tracker-team/security-tracker/-/commit/f0cddbc1a89d6988e0891225dfe9eb40374b1d8d I'm leaving the bug open but feel free to close it if the above sounds sensible :) Cheers! Sylvain Beucler Debian LTS Team On Fri, 16 Feb 2024 16:16:09 +0100 =?UTF-8?Q?Moritz_M=C3=BChlenhoff?= wrote: Source: plasma-workspace X-Debbugs-CC: t...@security.debian.org Severity: important Tags: security Hi, The following vulnerability was published for plasma-workspace. CVE-2024-1433[0]: | A vulnerability, which was classified as problematic, was found in | KDE Plasma Workspace up to 5.93.0. This affects the function | EventPluginsManager::enabledPlugins of the file | components/calendar/eventpluginsmanager.cpp of the component Theme | File Handler. The manipulation of the argument pluginId leads to | path traversal. It is possible to initiate the attack remotely. The | complexity of an attack is rather high. The exploitability is told | to be difficult. The patch is named | 6cdf42916369ebf4ad5bd876c4dfa0170d7b2f01. It is recommended to apply | a patch to fix this issue. The associated identifier of this | vulnerability is VDB-253407. NOTE: This requires write access to | user's home or the installation of third party global themes. https://github.com/KDE/plasma-workspace/commit/6cdf42916369ebf4ad5bd876c4dfa0170d7b2f01 If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2024-1433 https://www.cve.org/CVERecord?id=CVE-2024-1433 Please adjust the affected versions in the BTS as needed.
Bug#1067807: reportbug: Increase vm.max_map_count for game/application compatibility
Package: reportbug Version: 12.0.0 Severity: important Description: I propose to increase the default value of the 'vm.max_map_count' parameter to improve compatibility and performance of memory mapping-intensive applications, including databases and video games, especially those run through memory layers. compatibility like Wine such as Hogwarts legacy. Justification for the request: 1°) Fedora has already increased this default value to 1048576 to meet the needs of modern applications, including Windows games running via Wine or Steam 2°) Ubuntu has very recently recognized this bug, and is preparing to correct it in the next version of Ubuntu. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2057792 3°) Debian users who play video games, in particular those who use emulators or compatibility layers, but also on native Linux games, often encounter crash problems due to an insufficient 'vm.max_map_count' value . Expected result: Increase the default value of 'vm.max_map_count' to 1048576 to avoid the need for manual modifications, ensure a better user experience out of installation, and improve compatibility with a wide range of video games. Environment: All current versions of debian. Potential impact: - Significantly improved compatibility and performance for video games requiring extensive memory mapping. - Reduced manual setup steps for end users, especially in the gaming community. Additional Notes: This modification should be tested to assess its impact on system performance and resource consumption before being integrated by default, through debian sid for example. -- Package-specific info: ** Environment settings: INTERFACE="gtk" ** /home/sylvain/.reportbugrc: reportbug_version "12.0.0" mode novice ui gtk email "courseve...@gmail.com" smtphost "smtp.gmail.com" smtptls -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/24 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages reportbug depends on: ii apt 2.6.1 ii python3 3.11.2-1+b1 ii python3-reportbug 12.0.0 ii sensible-utils 0.0.17+nmu1 reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail ii debconf 1.5.82 pn debsums pn default-mta | postfix | exim4 | mail-transport-agent pn dlocate pn emacs-bin-common ii file 1:5.44-3 ii gnupg 2.2.40-1.1 pn python3-urwid ii reportbug-gtk 12.0.0 ii xdg-utils 1.1.3-4.1 Versions of packages python3-reportbug depends on: ii apt 2.6.1 ii file 1:5.44-3 ii python3 3.11.2-1+b1 ii python3-apt 2.6.0 ii python3-debian 0.1.49 ii python3-debianbts 4.0.1 ii python3-requests 2.28.1+dfsg-1 ii sensible-utils 0.0.17+nmu1 python3-reportbug suggests no packages. -- no debconf information
Bug#1066983: monopd: Fails to start monopd.service
Hi Markus, On Mon, Mar 25, 2024 at 02:36:59AM +0100, Markus Koschany wrote: > Sylvain Rochet wrote: > > Actually, the main problem is /lib/systemd/system/monopd.socket which > > set Accept=yes while monopd needs Accept=no (which is the default value). > > I wonder if monopd needs a systemd socket file at all and if we should > disable the service after the installation. We have been using this > setting since the introduction of systemd. If monopd runs with > Accept=no then we also don't need a service template file. At some > point I also noticed the same warning as Shriram > > "monopd.socket is a disabled or a static unit not running, not > starting it." and then followed [1] and added the required template > file. Yeah, socket activation is not really useful for public servers services, it is mostly used for local services that can be spawned on the fly later. Furthermore, socket activation breaks monopd metaserver registration because the daemon must be running to register, so better only ship the service file. I let you decide whether the service should be disabled or enabled by default (but unless something recently changed, daemon usually runs by default on Debian. I admit having lost track :D). > I have been running monopd for the past decade and I also suspect the > daemon is affected by some bugs which might be remotely exploitable. What makes you think that? My daemon is running attached to gdb so I can easily catch and trace any issue that would kill the process. So far it's been over 10 years without a single issue, some process lived for several years between systems reboot. I am not saying it is bug free because nothing is bug free, but if it is remotely exploitable and actively exploited, I would be aware of it on my running instance. > Since users usually don't need the monopd server anyway, if they want > to play a game, they should make a conscious decision to start it if > they want to use it locally. For a simple internet game, the daemon is > not required. Installing the server package isn't already a conscious decision? Kind regards, Sylvain signature.asc Description: Digital signature
Bug#1066983: monopd: Fails to start monopd.service
Hi, On Sat, Mar 23, 2024 at 09:35:38PM +0100, Sylvain Rochet wrote: > > That might be related to the latest change "Add a service template for > compatibility reasons with monopd.socket.". Actually, the main problem is /lib/systemd/system/monopd.socket which set Accept=yes while monopd needs Accept=no (which is the default value). By the way, I just released monopd 0.10.3 that detect this misconfiguration and exit instead of spinning forever over accept() :) Sylvain signature.asc Description: Digital signature
Bug#1066983: monopd: Fails to start monopd.service
Hi Shriram, On Sat, Mar 16, 2024 at 08:03:02PM +0530, Shriram Ravindranathan wrote: > Package: monopd > Version: 0.10.2-6+b2 > Severity: grave > Justification: renders package unusable > X-Debbugs-Cc: s...@ters.dev > > Dear Maintainer, > > monopd.service fails to start (could not bind port 1234), rendering the > package unusable. > > Mar 16 19:25:02 think182 sudo[4410]: shriram : TTY=pts/0 ; PWD=/home/shriram > ; USER=root ; COMMAND=/usr/bin/apt install monopd > Mar 16 19:25:02 think182 sudo[4410]: pam_unix(sudo:session): session opened > for user root(uid=0) by (uid=1000) > Mar 16 19:25:03 think182 systemd[1]: Reloading. > Mar 16 19:25:04 think182 systemd[1]: Reloading. > Mar 16 19:25:04 think182 systemd[1]: Starting monopd.service - game server > for board games like GtkAtlantic... > Mar 16 19:25:04 think182 systemd[1]: Listening on monopd.socket - monopd > listening socket. > Mar 16 19:25:04 think182 monopd[4512]: monopd 0.10.2 started > Mar 16 19:25:04 think182 monopd[4512]: loaded game configuration: > game=[Atlantic] > Mar 16 19:25:04 think182 monopd[4512]: loaded game configuration: > game=[Monopoly] > Mar 16 19:25:04 think182 systemd[1]: monopd.service: Failed to parse ERRNO= > field value '-2' in notification message: Numerical result out of range > Mar 16 19:25:04 think182 monopd[4512]: could not bind port 1234, exiting > Mar 16 19:25:04 think182 systemd[1]: monopd.service: Main process exited, > code=exited, status=254/n/a > Mar 16 19:25:04 think182 systemd[1]: monopd.service: Failed with result > 'exit-code'. > Mar 16 19:25:04 think182 systemd[1]: Failed to start monopd.service - game > server for board games like GtkAtlantic. > Mar 16 19:25:05 think182 sudo[4410]: pam_unix(sudo:session): session closed > for user root That might be related to the latest change "Add a service template for compatibility reasons with monopd.socket.". Masking socket activation and enabling the service worked for me: # systemctl stop monopd@*.service # systemctl stop system-monopd.slice # systemctl stop monopd.socket # systemctl mask monopd.socket # systemctl enable monopd.service # systemctl start monopd.service Kind regards, Sylvain signature.asc Description: Digital signature
Bug#1067113: libhiredis-dev: cmake config incompatible with upstream
Package: libhiredis-dev
Version: 1.2.0-6
Severity: normal
X-Debbugs-Cc: joubert...@gmail.com
Dear Maintainer,
The CMake config provided by this package seems incompatible with the upstream
one.
Currently, the package provides data under the name "Hiredis" with a capital
leading H, while upstream is named "hiredis" lowercase
".../cmake/Hiredis/HiredisConfig{,Version}.cmake" vs.
".../cmake/hiredis/hiredis-config.cmake" (see
https://github.com/redis/hiredis/blob/master/CMakeLists.txt#L137-L150)
This means that a client CMake project can't switch transparently between an
Debian install and a custom cmake build of hiredis.
Could you rename the cmake configuration provided by Debian to match upstream,
or even build hiredis using the official CMake support?
Thanks.
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (990, 'testing'), (800, 'stable-updates'), (800, 'stable'), (700,
'unstable'), (90, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libhiredis-dev depends on:
ii libhiredis1.1.0 1.2.0-6
libhiredis-dev recommends no packages.
libhiredis-dev suggests no packages.
-- no debconf information
Bug#1056992: freerdp2 version 3
Hi Mike & team, Is there something blocking you to start packaging v3 ? Thanks Sylvain
Bug#1059560: libwebkit2gtk-4.1-0: Can not add google online account via gnome-controle-center without : export WEBKIT_DISABLE_DMABUF_RENDERER=1
On Thu, 2023-12-28 at 14:25 +, Alberto Garcia wrote: > Control: tags -1 moreinfo > > On Thu, Dec 28, 2023 at 12:40:06PM +0100, Sylvain Maurin wrote: > > After a fresh install on a DELL Precision 3620 with i915 and Quadro > > K420 display adapters (used with Nvidia legacy driver v470), I > > wished to add a Google account via the 'Online Accounts' > [...] > > DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied > > Failed to create GBM buffer of size 496x346: Permission denied > > Can you install libnvidia-egl-gbm1 and try again ? > > Berto I did libnvidia-egl-gbm1 installation and probed : maurin@gimli:~$ unset WEBKIT_DISABLE_DMABUF_RENDERER maurin@gimli:~$ gnome-control-center GLib-GIO: _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ?gsettings-backend?GoaBackend: Loading all providers: GoaBackend: - googleGoaBackend: - owncloudGoaBackend: - windows_liveGoaBackend: - exchangeGoaBackend: - lastfmGoaBackend: - imap_smtpGoaBackend: - kerberosGoaBackend: activated kerberos providerGLib-GIO: Using cross-namespace EXTERNAL authentication (this will deadlock if server is GDBus < 2.73.3)GLib-GIO: Using cross- namespace EXTERNAL authentication (this will deadlock if server is GDBus < 2.73.3)GLib-GIO: _g_io_module_get_default: Found default implementation gvfs (GDaemonVfs) for ‘gio-vfs’GLib: unsetenv() is not thread-safe and should not be used after threads are createdGLib-GIO: _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ‘gsettings-backend’GoaBackend: Loading all providers: GoaBackend: - googleGoaBackend: - owncloudGoaBackend: - windows_liveGoaBackend: - exchangeGoaBackend: - lastfmGoaBackend: - imap_smtpGoaBackend: - kerberosGoaBackend: activated kerberos providerKMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied Failed to create GBM buffer of size 496x346: Permission denied KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied Failed to create GBM buffer of size 496x346: Permission denied KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied Failed to create GBM buffer of size 496x346: Permission denied Failed to create EGL images for DMABufs with file descriptors -1, -1 and -1 GLib-GIO: _g_io_module_get_default: Found default implementation gnutls (GTlsBackendGnutls) for ‘gio-tls-backend’ It didn't impacted problem. Sylvain -- ** Sylvain MAURIN - Admin.Sys. Institut Camille Jordan 21, avenue Claude Bernard 69622 VILLEURBANNE Cedex Tel: +33 472448546 -- Cel: +33 612399929 Mail: sylvain.mau...@cnrs.fr **
Bug#1059560: libwebkit2gtk-4.1-0: Can not add google online account via gnome-controle-center without : export WEBKIT_DISABLE_DMABUF_RENDERER=1
Package: libwebkit2gtk-4.1-0 Version: 2.42.4-1~deb12u1 Severity: important Dear Maintainer, After a fresh install on a DELL Precision 3620 with i915 and Quadro K420 display adapters (used with Nvidia legacy driver v470), I wished to add a Google account via the 'Online Accounts' panel from gnome-control-center when I only saw an empty dialog box. To get more clues, I started gnome-control-center from the CLI and got this error: ``` $ gnome-control-center GLib-GIO: _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ?gsettings-backend?GoaBackend: Loading all providers: GoaBackend: - googleGoaBackend: - owncloudGoaBackend: - windows_liveGoaBackend: - exchangeGoaBackend: - lastfmGoaBackend: - imap_smtpGoaBackend: - kerberosGLib-GIO: Using cross-namespace EXTERNAL authentication (this will deadlock if server is GDBus < 2.73.3)GoaBackend: activated kerberos providerGLib-GIO: Using cross-namespace EXTERNAL authentication (this will deadlock if server is GDBus < 2.73.3)GLib-GIO: _g_io_module_get_default: Found default implementation gvfs (GDaemonVfs) for ‘gio-vfs’GLib: unsetenv() is not thread-safe and should not be used after threads are createdGLib-GIO: _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ‘gsettings-backend’GoaBackend: Loading all providers: GoaBackend: - googleGoaBackend: - owncloudGoaBackend: - windows_liveGoaBackend: - exchangeGoaBackend: - lastfmGoaBackend: - imap_smtpGoaBackend: - kerberosGoaBackend: activated kerberos providerKMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied Failed to create GBM buffer of size 496x346: Permission denied KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied Failed to create GBM buffer of size 496x346: Permission denied KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied Failed to create GBM buffer of size 496x346: Permission denied Failed to create EGL images for DMABufs with file descriptors -1, -1 and -1 GLib-GIO: _g_io_module_get_default: Found default implementation gnutls (GTlsBackendGnutls) for ‘gio-tls-backend’ ``` I did a few research and found that the error is related to webkit renderer. As a workaround, an 'export WEBKIT_DISABLE_DMABUF_RENDERER=1' in my /etc/profile.d/FixWebKitRenderer.sh solved this problem. ``` $ gnome-control-center GLib-GIO: _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ?gsettings-backend?GoaBackend: Loading all providers: GoaBackend: - googleGoaBackend: - owncloudGoaBackend: - windows_liveGoaBackend: - exchangeGoaBackend: - lastfmGoaBackend: - imap_smtpGoaBackend: - kerberosGoaBackend: activated kerberos providerGLib- GIO: Using cross-namespace EXTERNAL authentication (this will deadlock if server is GDBus < 2.73.3)GLib-GIO: Using cross-namespace EXTERNAL authentication (this will deadlock if server is GDBus < 2.73.3)GLib-GIO: _g_io_module_get_default: Found default implementation gvfs (GDaemonVfs) for ‘gio-vfs’GLib: unsetenv() is not thread-safe and should not be used after threads are createdGLib-GIO: _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ‘gsettings-backend’GoaBackend: Loading all providers: GoaBackend: - googleGoaBackend: - owncloudGoaBackend: - windows_liveGoaBackend: - exchangeGoaBackend: - lastfmGoaBackend: - imap_smtpGoaBackend: - kerberosGoaBackend: activated kerberos providerGLib- GIO: _g_io_module_get_default: Found default implementation gnutls (GTlsBackendGnutls) for ‘gio-tls-backend’GLib-GIO: _g_io_module_get_default: Found default implementation gnome (GProxyResolverGnome) for ‘gio-proxy- resolver’GLib-GIO: Using cross-namespace EXTERNAL authentication (this will deadlock if server is GDBus < 2.73.3)GLib-GIO: _g_io_module_get_default: Found default implementation gvfs (GDaemonVfs) for ‘gio-vfs’GLib: unsetenv() is not thread-safe and should not be used after threads are createdGLib-GIO: _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ‘gsettings-backend’GoaBackend: Loading all providers: GoaBackend: - googleGoaBackend: - owncloudGoaBackend: - windows_liveGoaBackend: - exchangeGoaBackend: - lastfmGoaBackend: - imap_smtpGoaBackend: - kerberosGoaBackend: activated kerberos provider ``` As I may have a rare display configuration that may be related to this probleme, I join an 'xrandr' list : ``` $ xrandr --listproviders --listactivemonitors Providers: number : 2 Provider 0: id: 0x2d7 cap: 0x1, Source Output crtcs: 4 outputs: 4 associated providers: 1 name:NVIDIA-0 Provider 1: id: 0x315 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 6 associated providers: 1 name:modesetting Monitors: 3 0: +*DP-1 1920/546x1200/352+1050+404 DP-1 1: +DP-1-2 1200/518x1920/324+2970+0 DP-1-2 2: +HDMI-1-2 1050/473x1680/296+0+254 HDMI-1-2 ``` Thank's you for you work and happy holidays, Sylvain -- System Information:
Bug#1057671: cytadela: game include non free graphical assets
Hi, I know this may come as a shock, given how often this isn't the case, but the contrib status is dutifully documented in the copyright file: https://metadata.ftp-master.debian.org/changelogs//contrib/c/cytadela/cytadela_1.1.0-4_copyright ;) Please review and revise severity / close accordingly :) -- All the algorithms and artwork were taken from the original with permission from their authors. Distribution of the artwork (as a part of the conversion) is allowed under terms of the GNU GPL. <http://cytadela.sourceforge.net/doc.php?lang=en> -- This package in in the 'contrib' archive area and is not part of the Debian GNU/Linux distribution. The reason is that while the game data is free, there is no published software to modify the game levels: - .cmf and .3dg are generated from the original game's map files, using the 'mapconv' converter: http://sourceforge.net/projects/cytadela/files/mapconv/ That's the files we have no way to modify, neither in the original or the converted form. If somebody writes an editor (which should not be particularly difficult) the package can go in the 'main' area of the Debian archive. - For reference: .far files are archives (similar to .zip files), they can be created and extracted using the free 'fareditor' application: http://cytadela.sourceforge.net/download.php http://sourceforge.net/projects/cytadela/files/fareditor/ The .far archives contains textures and game fonts. Since the game engine is made specially for these 'contrib' data, it basically depends on them, so it goes to 'contrib' as well. It can go in 'main' as soon as the original data goes in 'main'. Cheers! Sylvain
Bug#1026898: deprecate QUOTAUSER post-bookworm
Hi, On 26/11/2023 11:32, Marc Haber wrote: On Sun, Nov 26, 2023 at 10:00:27AM +0100, Sylvain Beucler wrote: I use QUOTAUSER on a multi-user remote system, for a non-profit, where people tend to forget about disk space, to ensure any new 'adduser' sets a reasonable quota. If there's an alternative please let me know. The alternative would be to use edquota -p (quota) (username) after creating the user. At least that's what adduser does when the quotauser configuration option is set. I use QUOTAUSER so I can be sure that when me or a co-admin creates a user, the quota is set, and there's no way to forget about it (iow I know how to do it manually). By alternative, I mean a way to ensure that the quota is always set for new users :) I might contribute some tests but probably not soon. It would be nice if adduser would give a clear error message if quotauser is given and edquota is not present on the system, suggesting that the quota package be installed, and exit RET_MORE_PACKAGES, analogous to deluser's handling of perl not being present in line 198++ (probably easier than that because the existing code has to handle a failed use). An autopkgtest would mainly need to check the error handling and whether setting quotauser will actually have a result if quota is installed. I am not sure whether this also needs to run on a quota-enabled filesystem which might be hard to do in an autopkgtest. Noted. Cheers! Sylvain
Bug#1026898: deprecate QUOTAUSER post-bookworm
Hi, I use QUOTAUSER on a multi-user remote system, for a non-profit, where people tend to forget about disk space, to ensure any new 'adduser' sets a reasonable quota. If there's an alternative please let me know. I might contribute some tests but probably not soon. Cheers! Sylvain
Bug#1056593: transmission-remote-gtk: upstrean LOCALEDIR envvar bug avoids loading locale file
Package: transmission-remote-gtk Version: 1.5.1-1 Severity: normal Tags: l10n upstream X-Debbugs-Cc: cano...@9online.fr Dear Maintainer, The current version has a bug which prevents loading the appropriate locale file, so transmission-remote-gtk isn't translated for non-english-speaking users. Upstream fixed this bug in the 1.6.0 version with the following commit : https://github.com/transmission-remote-gtk/transmission-remote-gtk/commit/af7d3d78388da19b691d8773adaa0d5cd7c1b456 Please consider adding this commit to the current package. -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-13-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.utf8), LANGUAGE=fr_FR Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages transmission-remote-gtk depends on: ii libc62.36-9+deb12u3 ii libcurl4 7.88.1-10+deb12u4 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libgeoip11.6.12-10 ii libglib2.0-0 2.74.6-2 ii libgtk-3-0 3.24.38-2~deb12u1 ii libjson-glib-1.0-0 1.6.6-1 ii libpango-1.0-0 1.50.12+ds-1 ii libproxy1v5 0.4.18-1.2 transmission-remote-gtk recommends no packages. transmission-remote-gtk suggests no packages.
Bug#1055415: Wrong order for the `resolve' option in nsswitch.conf
Le dimanche 5 novembre 2023, Michael Biebl a écrit : > > See https://salsa.debian.org/systemd-team/systemd/-/merge_requests/162 > > This is indeed related. Yet the changes (as of today) do not seem to fix the order for `resolve'. This merge request seems to be waiting for a consensus before it can make progress.
Bug#1055415: Wrong order for the `resolve' option in nsswitch.conf
Package: libnss-resolve Version: 252.17-1~deb12u1 X-Debbugs-CC: pkg-systemd-maintain...@lists.alioth.debian.org The debian postinstall script for libnss-resolve inserts `resolve' in the `hosts:' line of /etc/nsswitch.conf before `dns', therefore after `files'. This does not seem optimal, as per `man nss-resolve', which reads: Specifically, it is recommended to place "resolve" early in /etc/nsswitch.conf's "hosts:" line. It should be before the "files" entry, since systemd-resolved supports /etc/hosts internally, but with caching.
Bug#1053562: nvidia-driver: Please package version 535 (possibly solves issues with running Dota 2).
Package: nvidia-driver Version: 530.41.03-3 Severity: normal Dear Maintainer, Please consider packaging version 535 of the NVIDIA drivers as that version seems to solve an issue with the game Dota 2 as is discussed here: https://github.com/ValveSoftware/Dota-2/issues/2414 . To briefly summarize the issue, the game freezes when drawing some particle effects, and the following error appears in the system log: [ 6398.284496] NVRM: GPU at PCI::01:00: GPU-5031fcee-5e0f-e0ab-2215-3b3790c16154 [ 6398.284518] NVRM: Xid (PCI::01:00): 32, pid=11430, name=dota2, Channel ID 0036 intr 0004 [ 6398.285005] NVRM: Xid (PCI::01:00): 32, pid=11430, name=dota2, Channel ID 0036 intr 0080 Some users report solving the issue by installing version 535 of the NVIDIA drivers. Cheers, -- Package-specific info: uname -a: Linux naelys 6.5.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.5.3-1 (2023-09-13) x86_64 GNU/Linux /proc/version: Linux version 6.5.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-13 (Debian 13.2.0-4) 13.2.0, GNU ld (GNU Binutils for Debian) 2.41) #1 SMP PREEMPT_DYNAMIC Debian 6.5.3-1 (2023-09-13) /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 530.41.03 Thu Mar 16 19:48:20 UTC 2023 GCC version: gcc version 13.2.0 (Debian 13.2.0-4) lspci 'display controller [030?]': 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP107 [GeForce GTX 1050] [10de:1c81] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Gigabyte Technology Co., Ltd GP107 [GeForce GTX 1050] [1458:3766] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: nvidia Kernel modules: nvidia dmesg: Device node permissions: crw-rw+ 1 root video 226, 0 Oct 6 12:02 /dev/dri/card0 crw-rw+ 1 root render 226, 128 Oct 6 12:02 /dev/dri/renderD128 crw-rw-rw- 1 root root 195, 254 Oct 6 12:02 /dev/nvidia-modeset crw-rw-rw- 1 root root 241, 0 Oct 6 12:02 /dev/nvidia-uvm crw-rw-rw- 1 root root 241, 1 Oct 6 12:02 /dev/nvidia-uvm-tools crw-rw-rw- 1 root root 195, 0 Oct 6 12:02 /dev/nvidia0 crw-rw-rw- 1 root root 195, 255 Oct 6 12:02 /dev/nvidiactl /dev/dri/by-path: total 0 lrwxrwxrwx 1 root root 8 Oct 6 12:02 pci-:01:00.0-card -> ../card0 lrwxrwxrwx 1 root root 13 Oct 6 12:02 pci-:01:00.0-render -> ../renderD128 /dev/nvidia-caps: total 0 cr 1 root root 244, 1 Oct 6 13:55 nvidia-cap1 cr--r--r-- 1 root root 244, 2 Oct 6 13:55 nvidia-cap2 video:x:44:boilard Alternative 'nvidia': nvidia - auto mode link best version is /usr/lib/nvidia/current link currently points to /usr/lib/nvidia/current link nvidia is /usr/lib/nvidia/nvidia slave nvidia--libEGL_nvidia.so.0-i386-linux-gnu is /usr/lib/i386-linux-gnu/libEGL_nvidia.so.0 slave nvidia--libEGL_nvidia.so.0-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libEGL_nvidia.so.0 slave nvidia--libGLESv1_CM_nvidia.so.1-i386-linux-gnu is /usr/lib/i386-linux-gnu/libGLESv1_CM_nvidia.so.1 slave nvidia--libGLESv1_CM_nvidia.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libGLESv1_CM_nvidia.so.1 slave nvidia--libGLESv2_nvidia.so.2-i386-linux-gnu is /usr/lib/i386-linux-gnu/libGLESv2_nvidia.so.2 slave nvidia--libGLESv2_nvidia.so.2-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libGLESv2_nvidia.so.2 slave nvidia--libGLX_nvidia.so.0-i386-linux-gnu is /usr/lib/i386-linux-gnu/libGLX_nvidia.so.0 slave nvidia--libGLX_nvidia.so.0-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0 slave nvidia--libcuda.so-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libcuda.so slave nvidia--libcuda.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libcuda.so.1 slave nvidia--libglxserver_nvidia.so is /usr/lib/nvidia/libglxserver_nvidia.so slave nvidia--libnvcuvid.so-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvcuvid.so slave nvidia--libnvcuvid.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvcuvid.so.1 slave nvidia--libnvidia-allocator.so.1-i386-linux-gnu is /usr/lib/i386-linux-gnu/libnvidia-allocator.so.1 slave nvidia--libnvidia-allocator.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvidia-allocator.so.1 slave nvidia--libnvidia-cfg.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1 slave nvidia--libnvidia-encode.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvidia-encode.so.1 slave nvidia--libnvidia-ml.so-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvidia-ml.so slave nvidia--libnvidia-ml.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvidia-ml.so.1 slave nvidia--libnvidia-nvvm.so.4-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvidia-nvvm.so.4 slave nvidia--libnvidia-nvvm.so.530.41.03-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvidia-nvvm.so.530.41.03 slave
Bug#1043011: clazy: Incompatibility with gcc/libstdc++ version 13
Package: clazy
Version: 1.11-4
Severity: important
X-Debbugs-Cc: joubert...@gmail.com
Dear Maintainer,
Using clazy on Debian testing with the newly updated libstdc++ to version 13 I
now get the following error:
/usr/bin/../lib/gcc/x86_64-linux-
gnu/13/../../../../include/c++/13/chrono:2320:48: error: call to consteval
function 'std::chrono::hh_mm_ss::_S_fractional_width' is not a constant
expression
static constexpr unsigned fractional_width = {_S_fractional_width()};
^
I believe this is due to the use of an older clang/llvm version (14) that does
not properly/completely implements 'consteval'.
Updating the used clang/llvm to a newer version should fix the issue.
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (990, 'testing'), (800, 'stable-updates'), (800, 'stable'), (700,
'unstable'), (90, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.4.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages clazy depends on:
ii clang-141:14.0.6-12
ii libc6 2.37-6
ii libclang-cpp14 1:14.0.6-12
ii libgcc-s1 13.1.0-9
ii libllvm14 1:14.0.6-12
ii libstdc++6 13.1.0-9
clazy recommends no packages.
clazy suggests no packages.
-- no debconf information
Bug#1035875: Arbitrary code execution vulnerability in versions < 2.3
Hi, I requested a CVE at cveform.mitre.org so we can start a discussion with upstream on clear grounds, and possibly involve other distros :) From https://github.com/mtrojnar/osslsigncode/compare/2.2...2.3 there are a lot of commits that fixes memory issues, e.g. fix double free in msi_dirent_new() Fix more fuzzer errors etc. so most probably there isn't a single clean patch to apply :/ We might want to just bump to buster and bullseye to 2.3, there's only one rdep AFAICS. Cheers! Sylvain Beucler Debian LTS Team (this week's Front-Desk person)
Bug#1033604: runc_1.0.0~rc6+dfsg1-3+deb10u2_amd64.deb: Built-Using refers to non-existing source package
Package: ftp.debian.org X-Debbugs-Cc: b...@beuc.net Severity: important Hi, (This was reported on #debian-ftp yesterday, submitting a bug report so it's not missed :)) All the 'any' parts of my 'runc' buster-lts update has been stuck at the "Uploaded" (not "Installed") stage for a day: https://buildd.debian.org/status/package.php?suite=buster-security=runc According to carnil, the error is: runc_1.0.0~rc6+dfsg1-3+deb10u2_amd64.deb: Built-Using refers to non-existing source package golang-github-mrunalp-fileutils (= 0.0~git20160930.0.4ee1cc9-1) AFAICT we're missing these at security.debian.org/pool/: - golang-github-mrunalp-fileutils (= 0.0~git20160930.0.4ee1cc9-1) - golang-github-urfave-cli (= 1.20.0-1) Could an ftp-master inject these dependencies and re-process the .changes? Cheers! Sylvain Beucler Debian LTS Team
Bug#1032482:
I found a related issue on upstream git. https://github.com/lxc/lxd/pull/11333 Following date of 5.0.2 and issue creation. This fix is not present on 5.0.2.
Bug#1032482: LXD - issue with btrfs backend loop file
Package: lxd Severity: important Hello, I had an issue when using a btrfs backend loop file. To confirm the issue, I bootstrapped a fresh Deb12 install. This is the method to reproduce the issue. After installed lxd,btrfs-progs and done the init wizard : lxc storage create pool_btrfs_1 btrfs size=50GiB lxc profile device add default root disk path=/ pool=pool_btrfs_1 lxc profile device add default ethlan nic name=ethlan nictype=bridged parent=brlan lxc init images:debian/12 Deb12test -v All seems to be fine, trying to limit storage for this container lxc config device override Deb12test root size=20GiB Error: Failed to update device "root": Failed to run: btrfs qgroup create 0/257 /var/lib/lxd/storage-pools/pool_btrfs_1/containers/Deb12test: exit status 1 (ERROR: unable to create quota group: File exists) I've the issue Try to create a new container lxc init images:debian/12 Deb12test2 -v Creating Deb12test2 Error: Failed instance creation: Failed creating instance from image: Failed to run: btrfs qgroup create 0/256 /var/lib/lxd/storage-pools/pool_btrfs_1/images/3971d4f65afc45437f1a688151487848e966088de60e995d9a6e638e292bae71: exit status 1 (ERROR: unable to create quota group: File exists) Issue again, no more action possible :( After some previous tests I discovered this issue is related to btrfs 6. Downgrade it : wget http://snapshot.debian.org/archive/debian/20220922T121957Z/pool/main/b/btrfs-progs/btrfs-progs_5.19.1-1_amd64.deb dpkg -i btrfs-progs_5.19.1-1_amd64.deb (no reboot performed) lxc init images:debian/12 Deb12test2 -v Creating Deb12test2 lxc config device override Deb12test root size=20GiB Device root overridden for Deb12test All works fine ! I found this issue on LXD tracker https://github.com/lxc/lxd/issues/11210 Therefore, changelog of 5.0.2 seems have the fix : https://linuxcontainers.org/lxd/news/#lxd-502-lts-has-been-released "lxd/storage/drivers/driver/btrfs/utils: Fix getQGroup to suport BTRFS >= 6.0.1" I will also try to inform upstream devs. I will keep you if I have news from them. Sylvain
Bug#922729: debootstrap: unable to override arch-test
Package: debootstrap Followup-For: Bug #922729 Hello The workaround I found was to install the binfmt-support and qemu-user-static packages, when debootstrap'ing an arm64 chroot on a amd64 host. Thank you -- Sylvain
Bug#1025297: Fixed in 22.3.2-1
After upgrading to 22.3.2-1 - issue seems resolved for me.
Bug#1025798: dolphin-emu: depends on obsolete packages libmbedcrypto3, libmbedtls12, libmbedx509-0
Package: dolphin-emu Version: 5.0+dfsg-6 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Dear Maintainer, Package dolphin-emu depends on obsolete packages libmbedcrypto3, libmbedtls12 and libmbedx509-0, making it impossible to install. Cheers, -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-5-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.utf8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dolphin-emu depends on: ii dolphin-emu-data 5.0+dfsg-6 ii libao41.2.2+20180113-1.1 ii libasound21.2.8-1 ii libavcodec58 7:4.4.2-1+b3 ii libavformat58 7:4.4.2-1+b3 ii libavutil56 7:4.4.2-1+b3 ii libbluetooth3 5.66-1 ii libc6 2.36-6 ii libcurl3-gnutls 7.86.0-2 ii libenet7 1.3.13+ds-1 ii libevdev2 1.13.0+dfsg-1 ii libgcc-s1 [libgcc1] 12.2.0-9 ii libgl11.5.0-1 ii libglib2.0-0 2.74.2-1 ii libgtk-3-03.24.35-2 ii liblzo2-2 2.10-2 ii libmbedcrypto32.16.11-0.3 ii libmbedtls12 2.16.11-0.3 ii libmbedx509-0 2.16.11-0.3 ii libminiupnpc172.2.3-1+b1 ii libopenal11:1.19.1-2 ii libpng16-16 1.6.39-2 ii libportaudio2 19.6.0-1.2 ii libpulse0 16.1+dfsg1-2+b1 ii libsfml-network2.52.5.1+dfsg-2+b2 ii libsfml-system2.5 2.5.1+dfsg-2+b2 ii libsoil1 1.07~20080707.dfsg-4 ii libsoundtouch12.3.2+ds1-1 ii libstdc++612.2.0-9 ii libswscale5 7:4.4.2-1+b3 ii libudev1 252.2-1 ii libusb-1.0-0 2:1.0.26-1 ii libwxbase3.0-0v5 3.0.5.1+dfsg-5 ii libwxgtk3.0-gtk3-0v5 3.0.5.1+dfsg-5 ii libx11-6 2:1.8.1-2 ii libxi62:1.8-1+b1 ii libxrandr22:1.5.2-2+b1 ii zlib1g1:1.2.11.dfsg-4.1 dolphin-emu recommends no packages. dolphin-emu suggests no packages. -- no debconf information -- Sylvain BOILARD
Bug#1025432: LXD - suggestion to moving dnsmasq to recommended dependencie
Package: lxd Severity: wishlist Hello, Following the discussion[1] on the Go mailing list. Please find this bug for my suggestion to move the dnsmasq dependency to recommended. For users who do not need a network solution managed by LXD, we cannot install LXD without installing dnsmasq. I suggest to move dnsmasq to recommended. For me, this corresponds to what is mentioned in the paragraph "DEBIAN POLICY Recommends, Suggests, and Enhances fields"[2] from The Debian Administrator's Handbook Most of debian user (I think) will not change option about recommended packages and they are installed. Related to LXD, most of Debian user will install dnsmasq with LXD and for those who wish to not use it, we will be able to not install it. I tested to break (mv /usr/sbin/dnsmasq /usr/sbin/dnsmasq) dnsmasq to check if LXD will have issue. I didn't found issue. All seems good. I hope that other user will send their opinion Sylvain [1] - https://lists.debian.org/debian-go/2022/12/msg6.html [2] - https://debian-handbook.info/browse/stable/sect.package-meta-information.html
Bug#1025297: thunderbird segfault with 22.3
Hi, I'm also encountering issues with 22.3.0-1 with thunderbird. The application doesn't start - here's GDB backtrace: #0 _dl_close (_map=0x0) at ./elf/dl-close.c:795 #1 0x77b6de9a in __GI__dl_catch_exception (exception=exception@entry=0x7fff9a70, operate=, args=) at ./elf/dl-error-skeleton.c:208 #2 0x77b6df4f in __GI__dl_catch_error (objname=0x7fff9ac8, errstring=0x7fff9ad0, mallocedp=0x7fff9ac7, operate=, args=) at ./elf/dl-error-skeleton.c:227 #3 0x77aa3dc7 in _dlerror_run (operate=, args=) at ./dlfcn/dlerror.c:138 #4 0x77aa3b26 in __dlclose (handle=) at ./dlfcn/dlclose.c:31 #5 0x7fffe3ae7f44 in () at /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #6 0x7fffe3ae7190 in () at /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #7 0x7fffe30aa179 in () at /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #8 0x7fffe36b5156 in () at /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #9 0x7fffe36b50c4 in () at /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #10 0x7fffe30ac0bc in () at /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #11 0x7fffe30b44b5 in () at /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #12 0x7fffedd31eae in () at /lib/x86_64-linux-gnu/libgbm.so.1 #13 0x7fffedd32360 in () at /lib/x86_64-linux-gnu/libgbm.so.1 #14 0x7fffedd3264b in () at /lib/x86_64-linux-gnu/libgbm.so.1 #15 0x7fffedd3074c in () at /lib/x86_64-linux-gnu/libgbm.so.1 #16 0x7fffedd30884 in gbm_create_device () at /lib/x86_64-linux-gnu/libgbm.so.1 #17 0x70d48f9a in mozilla::widget::nsGbmLib::CreateDevice(int) (fd=3) at ./widget/gtk/DMABufLibWrapper.h:66 #18 0x70d48d4f in mozilla::widget::nsDMABufDevice::Configure(nsTSubstring&) (this=0x756e3880 , aFailureId=...) at ./widget/gtk/DMABufLibWrapper.cpp:255 #19 0x7fffef1f3bc0 in gfxPlatformGtk::InitDmabufConfig() (this=) at ./gfx/thebes/gfxPlatformGtk.cpp:221 #20 0x7fffef1f35c4 in gfxPlatformGtk::gfxPlatformGtk() (this=0x7fffea00e580) at ./gfx/thebes/gfxPlatformGtk.cpp:113 #21 0x7fffef1eb9a2 in gfxPlatform::Init() () at ./gfx/thebes/gfxPlatform.cpp:895 #22 0x7fffef1eafd0 in gfxPlatform::GetPlatform() () at ./gfx/thebes/gfxPlatform.cpp:467 Downgrading to 22.2.4 fixes the issue. I'm using the proprietary nvidia driver, on another machine without a nvidia card, 22.3 works fine. Let me know if you need something else. Thanks
Bug#1023884: vtun: patch for libssl3
Hi,
Attached patch is a better approach to fix that by loading providers in
main instead of crypto module. That way it also works for legacy VTun
crypto module (VTun <= 2.6) if there are any users left and is future
proof for auth module.
Sylvain
diff -Nru vtun-3.0.4.orig/main.c vtun-3.0.4/main.c
--- vtun-3.0.4.orig/main.c 2022-11-23 13:56:31.0 +0100
+++ vtun-3.0.4/main.c 2022-11-23 13:57:03.283705646 +0100
@@ -35,6 +35,10 @@
#include
#endif
+#ifdef HAVE_SSL
+#include
+#endif /* HAVE_SSL */
+
#include "vtun.h"
#include "lib.h"
#include "compat.h"
@@ -70,6 +74,10 @@
struct vtun_host *host = NULL;
struct sigaction sa;
char *hst;
+#ifdef HAVE_SSL
+ OSSL_PROVIDER *legacy;
+ OSSL_PROVIDER *deflt;
+#endif /* HAVE_SSL */
/* Configure default settings */
svr = 0; daemon = 1; sock = 0;
@@ -168,6 +176,20 @@
openlog("vtund", LOG_PID|LOG_NDELAY|LOG_PERROR, vtun.syslog);
}
+#ifdef HAVE_SSL
+ legacy = OSSL_PROVIDER_load(NULL, "legacy");
+ if (legacy == NULL) {
+vtun_syslog(LOG_ERR, "Failed to load OpenSSL Legacy provider");
+exit(1);
+ }
+
+ deflt = OSSL_PROVIDER_load(NULL, "default");
+ if (deflt == NULL) {
+ vtun_syslog(LOG_ERR, "Failed to load OpenSSL Default provider");
+ exit(1);
+ }
+#endif /* HAVE_SSL */
+
clear_nat_hack_flags(svr);
if(!svr){
signature.asc
Description: Digital signature
Bug#1023884: vtun: patch for libssl3
Package: vtun
Version: 3.0.4-2+b1
Severity: important
Dear Maintainer,
gdb:
Program received signal SIGSEGV, Segmentation fault.
0x77c063a2 in EVP_CIPHER_CTX_set_key_length () from
/lib/x86_64-linux-gnu/libcrypto.so.3
OpenSSL 3.0 introduced providers, legacy algorithms such as RC4 or Blowfish
must now be explicitely enabled before using them.
See #1014193.
Here is a patch loading the legacy and default provider.
-- System Information:
Debian Release: bookworm/sid
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldoldstable'), (500,
'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.0.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages vtun depends on:
ii libc6 2.36-4
ii liblzo2-2 2.10-2
ii libssl33.0.7-1
ii lsb-base 11.5
ii sysvinit-utils [lsb-base] 3.05-7
ii udev 252.1-1
ii zlib1g 1:1.2.13.dfsg-1
vtun recommends no packages.
vtun suggests no packages.
-- Configuration Files:
/etc/vtund.conf [Errno 13] Permission denied: '/etc/vtund.conf'
-- no debconf information
diff -Nru vtun-3.0.4.orig/lfd_encrypt.c vtun-3.0.4/lfd_encrypt.c
--- vtun-3.0.4.orig/lfd_encrypt.c 2022-11-12 01:29:21.0 +0100
+++ vtun-3.0.4/lfd_encrypt.c2022-11-12 01:28:45.525976893 +0100
@@ -154,9 +154,23 @@
const EVP_CIPHER *cipher_type;
char tmpstr[64];
char cipher_name[32];
+ OSSL_PROVIDER *legacy;
+ OSSL_PROVIDER *deflt;
EVP_CIPHER_CTX *pctx_enc;
EVP_CIPHER_CTX *pctx_dec;
+ legacy = OSSL_PROVIDER_load(NULL, "legacy");
+ if (legacy == NULL) {
+ vtun_syslog(LOG_ERR, "Failed to load OpenSSL Legacy provider");
+ return -1;
+ }
+
+ deflt = OSSL_PROVIDER_load(NULL, "default");
+ if (deflt == NULL) {
+ vtun_syslog(LOG_ERR, "Failed to load OpenSSL Default provider");
+ return -1;
+ }
+
ctx_enc = EVP_CIPHER_CTX_new();
ctx_dec = EVP_CIPHER_CTX_new();
ctx_enc_ecb = EVP_CIPHER_CTX_new();
Bug#1023473: tinyproxy: Bad owner for /var/log/tinyproxy with bullseye bpo
Package: tinyproxy Version: 1.11.1-1~bpo11+1 Severity: important X-Debbugs-Cc: tarjaiz...@gmail.com Dear Maintainer, With 1.11.1-1~bpo11+1 version, owner of /var/log/tinyproxy is not set to tinyproxy user. During starting service, we have this error : ERROR: Could not create log file /var/log/tinyproxy/tinyproxy.log: Permission denied. Regarding to this commit https://salsa.debian.org/debian/tinyproxy/-/commit/05f60e2e7f9fdadf01c75142df34260d2e0afd91 it was done in previous version. I checked with stable version and owner is correcly set. I don't understand the commit message : "Remove deprecated migration code" Do you have information about this issue ? Can you fix it ? Thanks -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 5.10.0-19-arm64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_CRAP Locale: LANG=en_US.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tinyproxy depends on: ii adduser 3.118 ii init-system-helpers 1.60 ii logrotate3.18.0-2+deb11u1 ii lsb-base 11.1.0 ii tinyproxy-bin1.11.1-1~bpo11+1 tinyproxy recommends no packages. tinyproxy suggests no packages. -- Configuration Files: /etc/tinyproxy/tinyproxy.conf changed [not included] -- no debconf information
Bug#961654: buster-pu: package bzip2/1.0.6-9.2~deb10u1
Hi, IIUC this is about fixing 2 non-security bugs, that were introduced prior to buster's initial release. I personally don't think this fits the LTS project scope. Maybe other LTS members will have a different opinion. Cheers! Sylvain Beucler Debian LTS Team On 13/09/2022 15:27, Santiago R.R. wrote: El 10/09/22 a las 19:11, Adam D. Barratt escribió: On Wed, 2020-05-27 at 11:56 +0200, Santiago R.R. wrote: Since 1.0.6-9, bzip2 was built without the -D_FILE_OFFSET_BITS=64 CPPFLAG, and so it's not able to handle > 2GB files in 32-bit archs. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944557 I've uploaded a fixed version to unstable yesterday. It would be great to fix it also in buster. Please, consider the attached debdiff. Would it be OK for you to upload it? Apologies for apparently letting this sit unanswered. (FTR there was a reply from a non-SRM member 18 months ago.) And I am sorry I missed that answer. The final point release for buster has now happened, so any further updates to packages in buster will need to be handled via LTS. I'm therefore going to close this request now. [snip] I am forwarding this to the LTS folks, so they can decide about this change.
Bug#1006682: /usr/lib/cmake/mathgl2/MathGL2Config.cmake: Could NOT find OpenMP_CXX
Ok, I just figured out why you probably can't reproduce the issue: you need to use clang as a compiler. If you use `CXX=clang++-14 cmake [...]` as a configure command line you'll likely trigger the error. And the required package providing OpenMP for clang must match the clang version used: if I install libomp-13-dev while using clang++-14 for example I'll still get the error. With this additional info I get that the issue is triggered with a non-default setup, so I'm not sure how or even if it can be fixed correctly. Especially given that the proper dependency is heavily dependent on the clang version used/installed. Given that understanding I'd be fine with leaving things as is. And maybe it's the upstream MathGL2Config.cmake that needs a rework to deal more easily with various setups. Anyway, thanks for taking a look. Le mer. 31 août 2022 à 10:03, Sylvain Joubert a écrit : > Hi, > Here is the minimal CMakeLists.txt that reproduces the issue: > > cmake_minimum_required(VERSION 3.22.0) > project(mgl_test LANGUAGES CXX) > find_package(MathGL2 REQUIRED) > > If the packages libomp-dev and libomp-XX-dev that it drags (libomp-11-dev > on stable, libomp-14-dev on my testing setup) are not installed I get the > initial reported error. > > > Le mar. 30 août 2022 à 22:03, Rafael Laboissière a > écrit : > >> Control: tags -1 moreinfo >> >> * Sylvain Joubert [2022-03-02 11:17]: >> >> > Package: libmgl-dev >> > Version: 8.0.1-1 >> > Severity: normal >> > >> > Dear Maintainer, >> > >> > Trying to use libmgl-dev through find_package(MathGL2) in CMake I'm >> facing the >> > following error: >> > >> > CMake Error at >> /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230 >> > (message): Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS >> OpenMP_CXX_LIB_NAMES) >> > Call Stack (most recent call first): >> > /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:594 >> > (_FPHSA_FAILURE_MESSAGE) >> > /usr/share/cmake-3.22/Modules/FindOpenMP.cmake:544 >> > (find_package_handle_standard_args) >> > /usr/share/cmake-3.22/Modules/CMakeFindDependencyMacro.cmake:47 >> > (find_package) >> > /usr/lib/cmake/mathgl2/MathGL2Config.cmake:22 (find_dependency) >> > [...] >> > >> > It appears the libmgl-dev package is missing a dependency on an OpenMP >> > related package. Installing libomp-dev fixes the issue though I'm not >> > sure this is the correct package to depend on. >> >> Thank you for the bug report. >> >> Could you please provide an example that trigger the bug? For >> inspiration, look at Bug #1004218 [1] or #1004219 [2]. >> >> Best, >> >> Rafael Laboissière >> >> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004218 >> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004219 >> >
Bug#1006682: /usr/lib/cmake/mathgl2/MathGL2Config.cmake: Could NOT find OpenMP_CXX
Hi, Here is the minimal CMakeLists.txt that reproduces the issue: cmake_minimum_required(VERSION 3.22.0) project(mgl_test LANGUAGES CXX) find_package(MathGL2 REQUIRED) If the packages libomp-dev and libomp-XX-dev that it drags (libomp-11-dev on stable, libomp-14-dev on my testing setup) are not installed I get the initial reported error. Le mar. 30 août 2022 à 22:03, Rafael Laboissière a écrit : > Control: tags -1 moreinfo > > * Sylvain Joubert [2022-03-02 11:17]: > > > Package: libmgl-dev > > Version: 8.0.1-1 > > Severity: normal > > > > Dear Maintainer, > > > > Trying to use libmgl-dev through find_package(MathGL2) in CMake I'm > facing the > > following error: > > > > CMake Error at > /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230 > > (message): Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS > OpenMP_CXX_LIB_NAMES) > > Call Stack (most recent call first): > > /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:594 > > (_FPHSA_FAILURE_MESSAGE) > > /usr/share/cmake-3.22/Modules/FindOpenMP.cmake:544 > > (find_package_handle_standard_args) > > /usr/share/cmake-3.22/Modules/CMakeFindDependencyMacro.cmake:47 > > (find_package) > > /usr/lib/cmake/mathgl2/MathGL2Config.cmake:22 (find_dependency) > > [...] > > > > It appears the libmgl-dev package is missing a dependency on an OpenMP > > related package. Installing libomp-dev fixes the issue though I'm not > > sure this is the correct package to depend on. > > Thank you for the bug report. > > Could you please provide an example that trigger the bug? For > inspiration, look at Bug #1004218 [1] or #1004219 [2]. > > Best, > > Rafael Laboissière > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004218 > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004219 >
Bug#819341: [unison] Please build unison-fsmonitor
On Fri, 24 Jul 2020 07:49:22 +0200 =?UTF-8?Q?St=c3=a9phane_Glondu?= wrote: Le 23/07/2020 à 17:35, Vincent Lefevre a écrit : >> I am planning to change the packaging structure of Unison in Debian. >> >> My current roadmap is: >> - create a new source package unison-2.48 >> - make meta-unison provide unison and unison-gtk with symlinks to the >> binaries provided by unison-2.48 >> - let the "unison" source package disappear >> - create a new source package unison-2.51 (or whatever is the latest >> version at the time) >> - ... >> - build unison-fsmonitor in unison-2.51 >> >> and be done with alternatives. This new packaging scheme makes more >> sense IMHO and will ease co-installability of multiple versions of unison. > > What would be important would be to include the OCaml version number > in the unison package name, since it has an effect on the behavior. Right. I've already uploaded unison-2.48 to NEW, let's settle on that first. I will add the OCaml version number in the next OCaml transition. Any news on the unison-fsmonitor helper to be compiled and bundled with the unison package ? -- Sylvain Leroy Président Eternilab https://www.eternilab.com
Bug#1010349: closed by Sylvain Beucler (Re: librecad: CVE-2021-21897 - heap-based buffer overflow loading a DXF file via embedded dxflib)
Hi, On 03/08/2022 19:31, Moritz Mühlenhoff wrote: > Am Sat, May 28, 2022 at 06:36:29PM +0200 schrieb Sylvain Beucler: >> - the package uses system dxflib, cf. debian/patches/debian_build.patch > > But is that functional/working as expected? librecad does not > have and dependency on libdxflib3? I stand corrected, thanks. Looking further, according to https://github.com/LibreCAD/LibreCAD/commit/71f1203c5dbfd49c0eabbeac1d763b6b6faccbf1 "Removed dxflib, only new libdxfrw are used" (2.0.0alpha4, pre-jessie) dxflib is not responsible for DXF support anymore and the embedded copy was removed. Thus it is not needed to depend on libxdflib3. A few files with common dxflib filenames or even copyright headers are present in 'libraries/jwwlib', for the purpose of handling JWW files; AFAICS this is an entirely different code that probably roughly started out as a copy of the previous DXF handler based on dxflib, retaining some utility code from dxflib but rewriting the core. The possibly vulnerable 'dl_jww-copy.cpp' in that folder, similar to dxflib's 'dl_dxf.cpp', isn't compiled through debuild (at least in buster), and hasn't been modified since its initial checkin. Overall it seems librecad embeds dxflib only partially now. On Wed, Aug 03, 2022 at 07:36:31PM +0200, Salvatore Bonaccorso wrote: > Actually I believe this should be either: > > - kept unfixed, as the source is affected but mark it as (unimportant) > as it has no relevance for the binary packages built > - drop the entry completely (see previous examples commited by jmm on > that matter hen the embedded source had no security impact at all to > the source package mentioned). Thanks for the explanation. Since the issue appears tricky I'm committing option #1, so as to leave a trace. Cheers! Sylvain Beucler Debian LTS Team
Bug#1014064: libqpid-proton-cpp12-dev: Missing CMake config files
Package: libqpid-proton-cpp12-dev Version: 0.37.0-1+b1 Severity: normal X-Debbugs-Cc: joubert...@gmail.com Dear Maintainer, While the pkg-config *.pc files are provided by this package, the relevant CMake config files are not. This make the library impossible to use in a standard CMake way (using find_package) I believe the same issue also applies to the libqpid-proton11-dev package The missing files should be in /usr/lib/cmake/ProtonCpp/ and in /usr/lib/cmake/Proton/ for libqpid-proton11-dev Sylvain. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (800, 'stable-updates'), (800, 'stable'), (700, 'unstable'), (90, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libqpid-proton-cpp12-dev depends on: ii libqpid-proton-cpp12 0.37.0-1+b1 ii libqpid-proton11-dev 0.37.0-1+b1 libqpid-proton-cpp12-dev recommends no packages. libqpid-proton-cpp12-dev suggests no packages. -- no debconf information
Bug#1010349: librecad: CVE-2021-21897 - heap-based buffer overflow loading a DXF file via embedded dxflib
Hello Neil, I'm triaging this vulnerability for Debian LTS / stretch. It appears librecad is not affected (all dists): - the package uses system dxflib, cf. debian/patches/debian_build.patch - while there appears to be similar vulnerable code in libraries/jwwlib/src/dl_jww-copy.cpp (grep for 'groupCode==42'), this particular file is not used in the build process AFAICT Can you confirm and update the security tracker accordingly? Cheers! Sylvain Beucler Debian LTS Team On Fri, 29 Apr 2022 11:09:43 +0100 Neil Williams wrote: Source: librecad Version: 2.1.3-3 Severity: important Tags: security X-Debbugs-Cc: codeh...@debian.org, Debian Security Team Hi, The following vulnerability was published for librecad. CVE-2021-21897[0]: | A code execution vulnerability exists in the | DL_Dxf::handleLWPolylineData functionality of Ribbonsoft dxflib | 3.17.0. A specially-crafted .dxf file can lead to a heap buffer | overflow. An attacker can provide a malicious file to trigger this | vulnerability. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-21897 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21897 Please adjust the affected versions in the BTS as needed.
Bug#1006682: /usr/lib/cmake/mathgl2/MathGL2Config.cmake: Could NOT find OpenMP_CXX
Package: libmgl-dev Version: 8.0.1-1 Severity: normal X-Debbugs-Cc: joubert...@gmail.com Dear Maintainer, Trying to use libmgl-dev through find_package(MathGL2) in CMake I'm facing the following error: CMake Error at /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230 (message): Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS OpenMP_CXX_LIB_NAMES) Call Stack (most recent call first): /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE) /usr/share/cmake-3.22/Modules/FindOpenMP.cmake:544 (find_package_handle_standard_args) /usr/share/cmake-3.22/Modules/CMakeFindDependencyMacro.cmake:47 (find_package) /usr/lib/cmake/mathgl2/MathGL2Config.cmake:22 (find_dependency) [...] It appears the libmgl-dev package is missing a dependency on an OpenMP related package. Installing libomp-dev fixes the issue though I'm not sure this is the correct package to depend on. Thanks, Sylvain -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (800, 'stable-updates'), (800, 'stable'), (700, 'unstable'), (90, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libmgl-dev depends on: ii libgl-dev 1.4.0-1 ii libgsl-dev2.7.1+dfsg-3 ii libmgl-fltk8 8.0.1-1 ii libmgl-glut8 8.0.1-1 ii libmgl-mpi8 8.0.1-1 ii libmgl-qt5-8 8.0.1-1 ii libmgl-wnd8 8.0.1-1 ii libmgl-wx88.0.1-1 ii libmgl8 8.0.1-1 ii libpng-dev1.6.37-3 libmgl-dev recommends no packages. libmgl-dev suggests no packages. -- no debconf information
Bug#995368: libapache2-mod-proxy-uwsgi - CVE-2021-36160 regression, altered PATH_INFO
The regression fix is now officially staged upstream for 2.4.52: https://github.com/apache/httpd/commit/8966e290a6e947fad0289bf4e243b0b552e13726 Cheers! Sylvain Beucler Debian LTS Team
Bug#998679:
Hello, I have the same issue with firefox-esr 91.3.0esr-1. Downgrading to 91.2.0esr-1 remove the issue. Sylvain
Bug#998346: apt assigns priority 500 to package versions from debian-security
Package: apt Version: 2.2.4 Severity: normal Dear maintainer, APT does not consider package versions from debian-security for updates unless I change the priority assigned to these package versions to a more appropriate value with a preference configuration file (see the preferences.d/debian-security.disabled file below). After adding this file I could easily install the security updates I had missed untill then by running `aptitude upgrade` as I usually do. At some point APT was proposing to upgrade firefox-esr to the version found in unstable while ignoring the version in debian-security. I was recently in the process of upgrading from oldstable to stable which might have caused this particular behavior, and found out about the debian-security issue while trouble-shooting this. I remain available should you need any further information. Cheers, -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "1"; APT::Install-Suggests "0"; APT::Sandbox ""; APT::Sandbox::User "_apt"; APT::Authentication ""; APT::Authentication::TrustCDROM "true"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$"; APT::NeverAutoRemove:: "^linux-image-4\.19\.0-17-amd64$"; APT::NeverAutoRemove:: "^linux-image-5\.10\.0-9-amd64$"; APT::NeverAutoRemove:: "^linux-headers-4\.19\.0-17-amd64$"; APT::NeverAutoRemove:: "^linux-headers-5\.10\.0-9-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-4\.19\.0-17-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-5\.10\.0-9-amd64$"; APT::NeverAutoRemove:: "^linux-modules-4\.19\.0-17-amd64$"; APT::NeverAutoRemove:: "^linux-modules-5\.10\.0-9-amd64$"; APT::NeverAutoRemove:: "^linux-modules-extra-4\.19\.0-17-amd64$"; APT::NeverAutoRemove:: "^linux-modules-extra-5\.10\.0-9-amd64$"; APT::NeverAutoRemove:: "^linux-signed-image-4\.19\.0-17-amd64$"; APT::NeverAutoRemove:: "^linux-signed-image-5\.10\.0-9-amd64$"; APT::NeverAutoRemove:: "^linux-image-unsigned-4\.19\.0-17-amd64$"; APT::NeverAutoRemove:: "^linux-image-unsigned-5\.10\.0-9-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-image-4\.19\.0-17-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-image-5\.10\.0-9-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-headers-4\.19\.0-17-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-headers-5\.10\.0-9-amd64$"; APT::NeverAutoRemove:: "^gnumach-image-4\.19\.0-17-amd64$"; APT::NeverAutoRemove:: "^gnumach-image-5\.10\.0-9-amd64$"; APT::NeverAutoRemove:: "^.*-modules-4\.19\.0-17-amd64$"; APT::NeverAutoRemove:: "^.*-modules-5\.10\.0-9-amd64$"; APT::NeverAutoRemove:: "^.*-kernel-4\.19\.0-17-amd64$"; APT::NeverAutoRemove:: "^.*-kernel-5\.10\.0-9-amd64$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.19\.0-17-amd64$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-5\.10\.0-9-amd64$"; APT::NeverAutoRemove:: "^linux-modules-.*-4\.19\.0-17-amd64$"; APT::NeverAutoRemove:: "^linux-modules-.*-5\.10\.0-9-amd64$"; APT::NeverAutoRemove:: "^linux-tools-4\.19\.0-17-amd64$"; APT::NeverAutoRemove:: "^linux-tools-5\.10\.0-9-amd64$"; APT::NeverAutoRemove:: "^linux-cloud-tools-4\.19\.0-17-amd64$"; APT::NeverAutoRemove:: "^linux-cloud-tools-5\.10\.0-9-amd64$"; APT::NeverAutoRemove:: "^linux-buildinfo-4\.19\.0-17-amd64$"; APT::NeverAutoRemove:: "^linux-buildinfo-5\.10\.0-9-amd64$"; APT::NeverAutoRemove:: "^linux-source-4\.19\.0-17-amd64$"; APT::NeverAutoRemove:: "^linux-source-5\.10\.0-9-amd64$"; APT::VersionedKernelPackages ""; APT::VersionedKernelPackages:: "linux-.*"; APT::VersionedKernelPackages:: "kfreebsd-.*"; APT::VersionedKernelPackages:: "gnumach-.*"; APT::VersionedKernelPackages:: ".*-modules"; APT::VersionedKernelPackages:: ".*-kernel"; APT::Never-MarkAuto-Sections ""; APT::Never-MarkAuto-Sections:: "metapackages"; APT::Never-MarkAuto-Sections:: "contrib/metapackages"; APT::Never-MarkAuto-Sections:: "non-free/metapackages"; APT::Never-MarkAuto-Sections:: "restricted/metapackages"; APT::Never-MarkAuto-Sections:: "universe/metapackages"; APT::Never-MarkAuto-Sections:: "multiverse/metapackages"; APT::Move-Autobit-Sections ""; APT::Move-Autobit-Sections:: "oldlibs"; APT::Move-Autobit-Sections:: "contrib/oldlibs"; APT::Move-Autobit-Sections:: "non-free/oldlibs"; APT::Move-Autobit-Sections:: "restricted/oldlibs"; APT::Move-Autobit-Sections:: "universe/oldlibs"; APT::Move-Autobit-Sections:: "multiverse/oldlibs"; APT::Default-Release "bullseye"; APT::Architectures ""; APT::Architectures:: "amd64"; APT::Compressor ""; APT::Compressor::. ""; APT::Compressor::.::Name "."; APT::Compressor::.::Extension ""; APT::Compressor::.::Binary ""; APT::Compressor::.::Cost "0"; APT::Compressor::zstd ""; APT::Compressor::zstd::Name "zstd"; APT::Compressor::zstd::Extension ".zst"; APT::Compressor::zstd::Binary "false"; APT::Compressor::zstd::Cost "60";
Bug#967939: dvb-apps: Update dvb-apps:amd64 1.1.1+rev1500-1.2 => 1.1.1+rev1500-1.4 breaks gnutv
Hi, Bug confirmed on Bullseye (1.1.1+rev1500-1.4). gnutv only writes meta-data, no audio, no video, no subtitles…. So no errors but an empty stream. At least, 1.1.1+rev1500-1.2 from Buster can be installed on Bullseye without too much hassle and still works. Sincerely, -- Sylvain L. Sauvage
Bug#980052: xfce4-terminal: Does not honor Drop-down “Move to monitor with pointer” option
Hello, I discovered this bug today, after upgrading from buster to bullseye. It seems to be fixed upstream : https://gitlab.xfce.org/xfce/libxfce4ui/-/merge_requests/41 -- Regards, Sylvain OpenPGP_signature Description: OpenPGP digital signature
Bug#996551: llvm-13-dev: Missing dependency to libomp-13-dev
Package: llvm-13-dev Version: 1:13.0.0-6 Followup-For: Bug #996551 X-Debbugs-Cc: joubert...@gmail.com Dear Maintainer, I believe this bug still exists in version 1:13.0.0-6 with the same error. With a quick glance at the patch/fix I believe the regex that comments the relevant line is at fault (using 'omp-device-info' while the actual file/target name is 'llvm-omp-device-info') -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (800, 'stable-updates'), (800, 'stable'), (700, 'unstable'), (90, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.14.0-2-amd64 (SMP w/8 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages llvm-13-dev depends on: ii libc6 2.32-4 ii libclang-cpp13 1:13.0.0-6 ii libffi-dev 3.4.2-3 ii libgcc-s1 11.2.0-9 ii libllvm13 1:13.0.0-6 ii libncurses-dev [libtinfo-dev] 6.2+20201114-4 ii libstdc++6 11.2.0-9 ii libtinfo-dev 6.2+20201114-4 ii libxml2-dev2.9.12+dfsg-5 ii libz3-dev 4.8.12-1+b1 ii llvm-131:13.0.0-6 ii llvm-13-tools 1:13.0.0-6 llvm-13-dev recommends no packages. llvm-13-dev suggests no packages.
Bug#996551: llvm-13-dev: Missing dependency to libomp-13-dev
Package: llvm-13-dev Version: 1:13.0.0-5 Severity: important X-Debbugs-Cc: joubert...@gmail.com Dear Maintainer, With the recent move of llvm-omp-device-info from llvm-X to libomp8-dev, done in llvm-toolchain-13 (1:13.0.0-4), this package should now depend on libomp-X-dev The current situation is that llvm-X-dev references llvm-omp-device-info as part of an installed targets in its cmake configuration, but since it no longer provides that file any attempt to use the LLVM cmake package results in an error: CMake Error at /usr/lib/llvm-13/lib/cmake/llvm/LLVMExports.cmake:1501 (message): The imported target "llvm-omp-device-info" references the file "/usr/lib/llvm-13/bin/llvm-omp-device-info" but this file does not exist. Possible reasons include: * The file was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and contained "/usr/lib/llvm-13/lib/cmake/llvm/LLVMExports.cmake" but not all the files it references. Manually installing libomp-X-dev fixes the problem. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (800, 'stable-updates'), (800, 'stable'), (700, 'unstable'), (90, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.14.0-2-amd64 (SMP w/8 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages llvm-13-dev depends on: ii libc6 2.32-4 ii libclang-cpp13 1:13.0.0-5 ii libffi-dev 3.4.2-2 ii libgcc-s1 11.2.0-9 ii libllvm13 1:13.0.0-5 ii libncurses-dev [libtinfo-dev] 6.2+20201114-4 ii libstdc++6 11.2.0-9 ii libtinfo-dev 6.2+20201114-4 ii libxml2-dev2.9.12+dfsg-5 ii libz3-dev 4.8.12-1+b1 ii llvm-131:13.0.0-5 ii llvm-13-tools 1:13.0.0-5 llvm-13-dev recommends no packages. llvm-13-dev suggests no packages.
Bug#995368: libapache2-mod-proxy-uwsgi - CVE-2021-36160 regression, altered PATH_INFO
Hi, On 05/10/2021 18:41, Sylvain Beucler wrote: forwarded 995368 https://bz.apache.org/bugzilla/show_bug.cgi?id=65616 The Apache developers say there's an incorrect configuration in the first place. For example, ProxyPassMatch ^/ui uwsgi://127.0.0.1:8081/ should be ProxyPassMatch ^/ui uwsgi://127.0.0.1:8081 following the warning about slashes in the documentation: http://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass However, they are currently considering an additional patch to restore the previous (less strict) behavior. Philippe, Josef, I prepared a build with the new patch, so you can test early: https://people.debian.org/~beuc/lts/uwsgi/ https://people.debian.org/~beuc/lts/uwsgi/libapache2-mod-proxy-uwsgi_2.0.14+20161117-3+deb9u5_amd64.deb I'm interested in your feedback. Cheers! Sylvain Beucler Debian LTS Team
Bug#995368: libapache2-mod-proxy-uwsgi - CVE-2021-36160 regression, altered PATH_INFO
tags 995368 + upstream forwarded 995368 https://bz.apache.org/bugzilla/show_bug.cgi?id=65616 thanks Note: there doesn't seem to be actual path duplication at the UWSGI level, AFAICS Django just gets confused by the additional '/' at the start of PATH_INFO and incorrectly duplicates the path in the debug error page.
Bug#995368: libapache2-mod-proxy-uwsgi 2.0.14+20161117-3+deb9u4 - duplicated request path
affects 995368 apache2 thanks @Philippe thank you for the detailed info. @Moritz bookworm/apache2-2.4.49's behavior currently matches uwsgi/stretch's (buggy) behavior, it looks like the upstream patch introduced a regression. (This 2.4.49 release appears to have been tested poorly upstream, that'd make the 5th..) KO: ProxyPass /uwsgi-pp uwsgi://localhost:8001/ OK: ProxyPass /uwsgi-pps/ uwsgi://localhost:8001/ KO: ProxyPassMatch ^/admin uwsgi://localhost:8001/ I'll open a ticket on bz.apache.org. Cheers! Sylvain Beucler Debian LTS Team On 05/10/2021 14:39, Philippe Accorsi wrote: Hi, I work on this project https://github.com/tracim/tracim and we saw the problem with the docker images created with files available here https://github.com/tracim/tracim/tree/develop/tools_docker/Debian_Uwsgi/ . We create docker images on Debian Stretch and install package libapache2-mod-proxy-uwsgi. We use socket connection between Apache and uwsgi. In Apache we use (more detail available directly in repository): ProxyPassMatch ^/$ uwsgi://localhost:8081/ And in uwsgi configuration file we use (more detail available directly in repository): plugins = python3 module = wsgi.web:application socket = :8081 Regards, Philippe Accorsi Le 05/10/2021 à 13:04, Sylvain Beucler a écrit : Thank you Moritz for forwarding the bug report. Josef, Philippe, can you provide further information, such anas Apache configuration excerpts, d details about your apache/uwsgi setup? I did not experience issues with my tests using a simple Django application (cf. https://wiki.debian.org/LTS/TestSuites/uwsgi ) so currently I cannot reproduce the problem. Regards, Sylvain Beucler Debian LTS Team On 05/10/2021 10:36, Moritz Mühlenhoff wrote: reassign 995368 uwsgi thanks Am Fri, Oct 01, 2021 at 04:16:05PM +0200 schrieb Josef Kejzlar, wpj s.r.o.: I can confirm this regression. After unattended security upgrades got applied during the night, all our applications stopped working. There is wrong request path sent to uwsgi server. Some times duplicated leading slash. I would classify this as critical problem, all servers using uwsgi and libapache2-mod-proxy-uwsgi stopped working after secuity update. Hi Philippe and Josef, thanks for reporting! This isn't a bug in Apache (source package name apache2), but got introduced by an update in the uwsgi source package (which is admittedly confusing since both build Apache modules with uwsgi in their name). I'm reassigning the bug and adding the debian-lts list to pick this up. -- Bien « collaborativement », Accorsi Philippe Administrateur Système et Support Technique Le logiciel de collaboration Libre MadeinFrance conçu et édité par Algoo SAS e-Mail : philippe.acco...@algoo.fr <mailto:philippe.acco...@algoo.fr> Tel : 09 72 49 72 20 Web : www.algoo.fr <https://www.algoo.fr>
Bug#995368: libapache2-mod-proxy-uwsgi 2.0.14+20161117-3+deb9u4 - duplicated request path
Thank you Moritz for forwarding the bug report. Josef, Philippe, can you provide further information, such as Apache configuration excerpts, and details about your apache/uwsgi setup? I did not experience issues with my tests using a simple Django application (cf. https://wiki.debian.org/LTS/TestSuites/uwsgi ) so currently I cannot reproduce the problem. Regards, Sylvain Beucler Debian LTS Team On 05/10/2021 10:36, Moritz Mühlenhoff wrote: reassign 995368 uwsgi thanks Am Fri, Oct 01, 2021 at 04:16:05PM +0200 schrieb Josef Kejzlar, wpj s.r.o.: I can confirm this regression. After unattended security upgrades got applied during the night, all our applications stopped working. There is wrong request path sent to uwsgi server. Some times duplicated leading slash. I would classify this as critical problem, all servers using uwsgi and libapache2-mod-proxy-uwsgi stopped working after secuity update. Hi Philippe and Josef, thanks for reporting! This isn't a bug in Apache (source package name apache2), but got introduced by an update in the uwsgi source package (which is admittedly confusing since both build Apache modules with uwsgi in their name). I'm reassigning the bug and adding the debian-lts list to pick this up.
Bug#995604: (no subject)
Running latest kernel 5.14.0-2-amd64 #1 SMP Debian 5.14.9-2 seems to fix the issue.
Bug#995604: ntfs-3g: mount.ntfs stuck in D state
Package: ntfs-3g Version: 1:2021.8.22-2 Severity: normal Dear Maintainer, mount.ntfs gets stuck in D state, i'm running latest SID kernel, 5.14.6-3. here's the stack trace: [ 1209.682705] INFO: task kworker/3:0:3972 blocked for more than 604 seconds. [ 1209.682728] Tainted: P OE 5.14.0-1-amd64 #1 Debian 5.14.6-3 [ 1209.682729] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1209.682731] task:kworker/3:0 state:D stack:0 pid: 3972 ppid: 2 flags:0x4000 [ 1209.682735] Workqueue: usb_hub_wq hub_event [usbcore] [ 1209.682759] Call Trace: [ 1209.682762] __schedule+0x2f0/0x910 [ 1209.682768] schedule+0x44/0xa0 [ 1209.682769] rwsem_down_read_slowpath+0x342/0x390 [ 1209.682772] get_super+0x93/0xe0 [ 1209.682779] fsync_bdev+0x11/0x60 [ 1209.682783] delete_partition+0x13/0x80 [ 1209.682788] blk_drop_partitions+0x4a/0x90 [ 1209.682790] del_gendisk+0x44/0x1c0 [ 1209.682793] sd_remove+0x3d/0x80 [sd_mod] [ 1209.682797] __device_release_driver+0x17a/0x230 [ 1209.682802] device_release_driver+0x24/0x30 [ 1209.682804] bus_remove_device+0xd8/0x140 [ 1209.682806] device_del+0x18b/0x3e0 [ 1209.682811] ? ata_tlink_match+0x30/0x30 [libata] [ 1209.682831] ? attribute_container_device_trigger+0x69/0xf0 [ 1209.682834] __scsi_remove_device+0x118/0x150 [scsi_mod] [ 1209.682851] scsi_forget_host+0x54/0x60 [scsi_mod] [ 1209.682859] scsi_remove_host+0x72/0x100 [scsi_mod] [ 1209.682868] usb_stor_disconnect+0x46/0xc0 [usb_storage] [ 1209.682872] usb_unbind_interface+0x8a/0x270 [usbcore] [ 1209.682885] ? kernfs_find_ns+0x35/0xd0 [ 1209.682889] __device_release_driver+0x17a/0x230 [ 1209.682891] device_release_driver+0x24/0x30 [ 1209.682893] bus_remove_device+0xd8/0x140 [ 1209.682895] device_del+0x18b/0x3e0 [ 1209.682897] ? kobject_put+0x91/0x1d0 [ 1209.682900] usb_disable_device+0xc6/0x1e0 [usbcore] [ 1209.682911] usb_disconnect.cold+0x7b/0x207 [usbcore] [ 1209.682922] hub_event+0xbf2/0x1810 [usbcore] [ 1209.682932] ? __switch_to_asm+0x42/0x70 [ 1209.682936] process_one_work+0x1ec/0x390 [ 1209.682939] worker_thread+0x53/0x3e0 [ 1209.682941] ? process_one_work+0x390/0x390 [ 1209.682942] kthread+0x127/0x150 [ 1209.682945] ? set_kthread_struct+0x40/0x40 [ 1209.682948] ret_from_fork+0x22/0x30 I didn't have this issue with the previous 5.10 kernel. Please let me know if you need more information. Thank you Sylvain -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.14.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ntfs-3g depends on: ii fuse3 [fuse] 3.10.5-1 ii libc6 2.32-4 ii libgcrypt20 1.9.4-3+b1 ii libgnutls30 3.7.2-2 ii libntfs-3g89 1:2021.8.22-2 ntfs-3g recommends no packages. ntfs-3g suggests no packages. -- no debconf information
Bug#994057:
Hello, Thank you for your reply. I didn't know graphic rendering specificities of firefox. Thank you for the information. I opened the bug on libegl-mesa0 because it was the first packet of dependencies list. I using 21.2.1-2 version to try to provide more information for this bug. To reproduce the issue with firefox : - right click on tab and use mouse to fly over tab menu. or - open a web site and browse it down/up On my setup, Firefox seems using basic (software rendering) mode by default. With this basic mode, the issue is present with right click tab and web site browsing I tried to use firefox with Webrender (MOZ_WEBRENDER=1 firefox), right click artifacts are still present, but web browsing doesn't display artifact. When using EGL by MOZ_X11_EGL=1 firefox not working, Basic mode is still used Current mode is checked by about:support and Graphics/Features/Compositing value. I tried to provide a capture of the issue by using screen video recorder "simplescreenrecorder" and when I play the video I cannot see artifact on the video. When using remote desktop by VNC, artifact are not present. This bug couldn't be related between libraries and hardware ? I found newer application with artifact : VLC, simplescreenrecorder Sylvain
Bug#994057: libegl-mesa0: 21.2.1-2 with intel graphic card produces artifact on firefox-esr
Package: libegl-mesa0 Version: 21.2.1-2 Severity: serious Justification: unknow X-Debbugs-Cc: tarjaiz...@gmail.com Dear Maintainer, After upgraded libegl-mesa0 libgbm1 libgl1-mesa-dri libglapi-mesa libglx-mesa0 libllvm11 to 21.2.1-2, I have artifacts with firefox-esr. For example, with right click on a tab, I can see artifact. For the moment, I have not seen any problem with other software. If I downgrade to 20.3.5-1, the problem is no longer present. I use Intel graphic card (UHD Graphics 630), lightdm and i3. On another system, nvidia card is used, 21.2.1-2 has no problems. (lightdm and i3 are also used) I think it is related to mesa but I am not sure. Am I the only one in this case? Thanks VGA-compatible devices on PCI bus: -- 00:02.0 VGA compatible controller [0300]: Intel Corporation CoffeeLake-H GT2 [UHD Graphics 630] [8086:3e9b] (rev 02) /etc/X11/xorg.conf does not exist. Contents of /etc/X11/xorg.conf.d: - total 0 /etc/modprobe.d contains no KMS configuration files. Kernel version (/proc/version): --- Linux version 5.10.0-8-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.46-4 (2021-08-03) DRM Information from dmesg: --- -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libegl-mesa0 depends on: ii libc6 2.32-2 ii libdrm2 2.4.107-2 ii libexpat1 2.4.1-2 ii libgbm1 21.2.1-2 ii libgcc-s1 11.2.0-5 ii libglapi-mesa 21.2.1-2 ii libwayland-client0 1.19.0-2 ii libwayland-server0 1.19.0-2 ii libx11-xcb1 2:1.7.2-1 ii libxcb-dri2-0 1.14-3 ii libxcb-dri3-0 1.14-3 ii libxcb-present0 1.14-3 ii libxcb-sync11.14-3 ii libxcb-xfixes0 1.14-3 ii libxcb1 1.14-3 ii libxshmfence1 1.3-1 libegl-mesa0 recommends no packages. libegl-mesa0 suggests no packages. Versions of packages xserver-xorg depends on: ii x11-xkb-utils 7.7+5 ii xkb-data2.33-1 ii xorgxrdp [xorg-driver-video]1:0.2.15-1 ii xserver-xorg-core 2:1.20.11-1 ii xserver-xorg-input-all 1:7.7+23 ii xserver-xorg-input-libinput [xorg-driver-input 1.1.0-1 ii xserver-xorg-input-wacom [xorg-driver-input]0.34.99.1-1+b1 ii xserver-xorg-video-all 1:7.7+23 ii xserver-xorg-video-amdgpu [xorg-driver-video] 19.1.0-2 ii xserver-xorg-video-ati [xorg-driver-video] 1:19.1.0-2 ii xserver-xorg-video-fbdev [xorg-driver-video]1:0.5.0-1 ii xserver-xorg-video-intel [xorg-driver-video]2:2.99.917+git20200714-1+b1 ii xserver-xorg-video-nouveau [xorg-driver-video] 1:1.0.17-1 ii xserver-xorg-video-qxl [xorg-driver-video] 0.1.5+git20200331-1 ii xserver-xorg-video-radeon [xorg-driver-video] 1:19.1.0-2 ii xserver-xorg-video-vesa [xorg-driver-video] 1:2.5.0-1 ii xserver-xorg-video-vmware [xorg-driver-video] 1:13.3.0-3 Versions of packages xserver-xorg recommends: ii libgl1-mesa-dri 21.2.1-2 ii xserver-xorg-legacy 2:1.20.11-1 Versions of packages xserver-xorg-core depends on: ii keyboard-configuration 1.205 ii libaudit1 1:3.0.5-1 ii libbsd0 0.11.3-1 ii libc6 2.32-2 ii libdbus-1-3 1.12.20-2 ii libdrm2 2.4.107-2 ii libegl1 1.3.4-1 ii libepoxy0 1.5.8-1 ii libgbm1 21.2.1-2 ii libgcrypt20 1.9.4-2 ii libgl1 1.3.4-1 ii libpciaccess0 0.16-1 ii libpixman-1-0 0.40.0-1 ii libselinux1 3.1-3 ii libsystemd0 247.9-1 ii libudev1247.9-1 ii libunwind8 1.3.2-2 ii libxau6 1:1.0.9-1 ii libxdmcp6 1:1.1.2-3 ii libxfont2 1:2.0.4-1 ii libxshmfence1 1.3-1 ii udev247.9-1 ii xserver-common 2:1.20.11-1 Versions of packages xserver-xorg-core recommends: ii libgl1-mesa-dri 21.2.1-2 ii libpam-systemd [logind] 247.9-1 Versions of packages xserver-xorg-core suggests: ii xfonts-100dpi1:1.0.4+nmu1.1 ii xfonts-75dpi 1:1.0.4+nmu1.1 ii xfonts-scalable 1:1.0.3-1.2
Bug#992118: squid3-dbg: uninstallable cruft package from src:squid3 in jessie-elts
Hi, Note that jessie-elts is not part of the official Debian project, see https://wiki.debian.org/LTS/Extended So using Debian-specific resources (the BTS) for elts-specific issues may be considered an abuse. Cheers! Sylvain Beucler Debian LTS Team On Thu, 12 Aug 2021 00:17:36 +0200 Andreas Beckmann wrote: Package: squid3-dbg Version: 3.4.8-6+deb8u9 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Control: close -1 jessie-elts has squid3-dbg 3.4.8-6+deb8u9, but src:squid3 (and therefore the squid3 binary package, too) is already at 3.5.23-5+deb8u4 in jessie-elts, rendering the -dbg package uninstallable. The -dbg package is no longer built by the newer source package, leaving around some uninstallable cruft packages. This is probably not an actionable bug. Its primary intention is to mark the corresponding piuparts failures as known bugs.
Bug#991008: php7.4: typo in TEST_PHP_CGI_EXECUTABLE triggers many test suite errors
Source: php7.4 Hi, In debian/rules, the PHP CGI executable is set as: TEST_PHP_CGI_EXECUTABLE=$(CURDIR)/cgi-build/sapi/php-cgi while a correct path would be: TEST_PHP_CGI_EXECUTABLE=$(CURDIR)/cgi-build/sapi/cgi/php-cgi This results in many errors: sh: 1: /<>/cgi-build/sapi/php-cgi: not found see e.g. https://buildd.debian.org/status/fetch.php?pkg=php7.4=amd64=7.4.21-1%2Bdeb11u1=1625215800=0 which makes the test results less comprehensive. Apparently this has been the case since at least the php5 package. Is there a reason to set it that way, or should it be fixed? Cheers! Sylvain Beucler Debian LTS Team
Bug#986804: CVE-2021-28116
Hi, I asked upstream for further information about this vulnerability: https://bugs.squid-cache.org/show_bug.cgi?id=5131 Cheers! Sylvain Beucler Debian LTS Team
Bug#976070: issues fixed
Actually my issue seems different, i think it was this issue in network-manager: https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/issues/64. This has been fixed in 1.8.14-1 currently in experimental.
Bug#986581: debian-security-support: logic behind version-based filters
Hi, On 16/04/2021 10:41, Sylvain Beucler wrote: I dropped the version-based check and adapted the test suite: https://salsa.debian.org/debian/debian-security-support/-/merge_requests/9 pending review with secteam. I think we are all OK with this particular change. Can you review the MR? Cheers! Sylvain
Bug#986333: debian-security-support: Match ecosystems with limited support
On Sat, 3 Apr 2021 21:55:20 + Holger Levsen wrote: I think this is a useful feature indeed and I'd be very happy about patches, MRs or plain commits. debian-security-support is maintained in the Debian group on Salsa, so any DD can commit, though I'll equally happily take review requests :) Status update: I made a MR using a regexp-based approach: https://salsa.debian.org/debian/debian-security-support/-/merge_requests/10 which AFAIU was not deem appropriate for matching node-* in stretch or golang* in buster: https://lists.debian.org/debian-lts/2021/04/msg00030.html https://lists.debian.org/debian-lts/2021/04/msg00031.html I made alternate suggestions and am waiting for maintainers feedback: https://lists.debian.org/debian-lts/2021/04/msg00036.html - Sylvain
Bug#986581: debian-security-support: logic behind version-based filters
Hi Christoph,
Thanks a lot for your precisions,
On 13/04/2021 10:02, Christoph Biedl wrote:
Sylvain Beucler wrote...
We could not find a valid use case for this feature, while it is causing
some missing reports as with 'nodejs', as explained in the above BTS entry.
Did we miss something?
Well, I cannot remember the idea behind the logic, so feel free to do
what you (as a group) consider appropriate.
From guessing, I'd say: The case of "Installed package has a version
number higher than the last supported one" - then the security status of
that package is mostly undefined. Possibly I had backports in mind here:
So if a backport is installed *and* that one has proper security
support, I consider it correct to stay silent about that situation; in
fact, alerting is even wrong because it creates unnecessary noise - that
will educate users to ignore such alerts. But it's indeed hard to tell
whether this situation applies (checking apt-cache policy, checking the
security tracker [please don't], yada yade).
Moreover, I see that:
- backports have no official security support so are never supported
https://backports.debian.org/FAQ/
- the code incorrectly skips packages with no ("0") version
I dropped the version-based check and adapted the test suite:
https://salsa.debian.org/debian/debian-security-support/-/merge_requests/9
pending review with secteam.
The other feature, being able to end support in advance - well I'd call
that a nice hack and I'd certainly keep it. Although I'd agree it will
rarely be used.
Yes, date-based should be enough for this case.
Cheers!
Sylvain
Bug#986581: debian-security-support: logic behind version-based filters
Hello Christoph, I'm investigating an issue in 'debian-security-support' related to how it includes/excludes packages by comparing the installed version and the supported version, see: https://bugs.debian.org/986581 At this point I'm inclined to drop all the version-based logic, because when a package is added in security-support-ended.debX, that means there is immediate concern about this package, and we already can distinguish upcoming and effective end-of-support through dates. We could not find a valid use case for this feature, while it is causing some missing reports as with 'nodejs', as explained in the above BTS entry. Did we miss something? Cheers! Sylvain
Bug#986581: debian-security-support: omits installed packages with higher version
Package: debian-security-support Severity: normal Hi, In security-support-ended.debX, the 2nd field (version) is described as: "last version with support". If the currently installed version is higher, then it is not reported. For instance, nodejs/4.8.2~dfsg-1 (stretch) is not reported against: nodejs 0.10.29~dfsg-2 2020-02-20 ... which is wrong, because nodejs isn't supported and should be reported. The check is done with 'dpkg --compare-versions' and has been there since the initial commit: https://salsa.debian.org/debian/debian-security-support/-/blob/master/check-support-status.in#L262 Reversing the test triggers 29 test failures, explicitly excluding debconf-i18n/1.5.36.1 from the report against: debconf 1.5.36.02014-05-02 Thinking about it, I don't really understand the rationale behind version-based filtering. - If the installed version is higher, it can be a local version, or a backport, or in the nodejs case a lack of support across multiple Debian releases, so that's still unsupported and probably needs to be displayed. - If it's lower, then in what case would we document that a future version will be unsupported? Most probably the user's system is partially upgraded, and the package is likely unsupported already. What is the concrete use case for excluding packages based on version? Do we need to fix the code or security-support-ended.deb9? Cheers! Sylvain
Bug#986333: debian-security-support: Match ecosystems with limited support
Package: debian-security-support Severity: normal Hi, Sometimes, entire ecosystems are affected by Debian support decisions. These source package sets comes to mind: - node-* https://www.debian.org/releases/jessie/amd64/release-notes/ch-information.en.html#libv8 - golang-* https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#golang-static-linking Currently 'check-support-status' fails to detect individual packages affected by these decisions, it only notifies about explicitly referenced packages such as 'nodejs'. Maybe regex matching would help. (debian-security-support is an important tool in the Debian LTS/ELTS offering, so I believe we could offer help/time in this area.) What do you think? Cheers! Sylvain
Bug#976623: godot3-server: Provide both headless and server binaries with current server renamed to headless
Hi, On Sun, 06 Dec 2020 14:11:58 +1300 Ben Caradoc-Davies wrote: the current godot3-server binary is what upstream refer to as a "headless build" (built with "platform=server tools=yes target=release_debug"), and there is no binary for what upstream refer to as a "server build" (built with "platform=server tools=no target=release"). Consider: (1) Renaming "godot3-server" to "godot3-headless" for consistency with upstream, and (2) Adding a new "godot3-server" (built with "platform=server tools=no target=release") for consistency and completeness, in case anyone needs the much smaller "server build" binary. I recently discussed with upstream about packaging games in Debian and they got confused by this naming scheme, so I would +1 this. This is also causing bad practice when packaging games, because the package will depend on godot3-server to perform -headless tasks such as generating .pck files (instead of godot3-headless), see e.g.: https://lists.debian.org/debian-devel-games/2021/02/msg00013.html If it's inconvenient to provider yet another build, maybe we can use Provide:s. FTR their terminology is: https://godotengine.org/download/server * "The _headless_ build includes the editor tool functionality that enables it to run tests and export projects in an automated manner." * "The _server_ build is optimized to run dedicated game servers and does not include editor tools, graphics or audio support." Cheers! Sylvain
Bug#862139: [flash-kernel] Please, stop flashing multiple times
Le dimanche 7 février 2021, 05:03:56 CET Vagrant Cascadian a écrit : >[…] > > update-initramfs: Generating /boot/initrd.img-3.16.0-4-kirkwood > > flash-kernel: installing version 3.16.0-4-kirkwood > > Generating kernel u-boot image... done. > > Flashing kernel (2074936/2097152 bytes)... done. > > Flashing initramfs (5140458/9437184 bytes)... done. > > ... > > > Traitement des actions différées (« triggers ») pour flash-kernel > > (3.35+deb8u3) ... flash-kernel: installing version > > 3.16.0-4-kirkwood > > Generating kernel u-boot image... done. > > Flashing kernel (2074936/2097152 bytes)... done. > > Flashing initramfs (5140458/9437184 bytes)... done. > > This is almost certainly because flash-kernel has hooks in both the > kernel and initramfs: > > /etc/kernel/postinst.d/zz-flash-kernel > /etc/kernel/postrm.d/zz-flash-kernel > /etc/initramfs/post-update.d/flash-kernel > > I don't see a great way around this, as flash-kernel needs to be > updated when either gets updated, and they may often happen at the > same time. The triggers do at least prevent it from getting updated > every time a relevent package gets updated, even it if still happens > multiple times in any given run... > > > That said, someone with a better understanding of dpkg triggers might > be able to come up with something better... The problem is twofold: 1. Both changing the kernel and changing the initramfs trigger the flashing (which is okay) but the deferred trigger should be executed only once, which it’s not. (I’m not sure anymore that was the case, that was 4 years ago. I guess not as I’m talking about “flashing three times.”) 2. As (badly) shown on the excerpt the files are flashed both just when the package is installed (immediate) and when the whole update is finished (deferred). -- Sylvain L. Sauvage
Bug#980353: feed2imap: missing dependency on ruby-rubymail
Package: feed2imap Version: 1.2.6-1 Severity: important ruby-rubymail dependency was removed, but it’s still needed. Here’s the error message when ruby-rubymail is not installed (note that it’s not obvious “rmail” refers to ruby-rubymail and not ruby-mail): $ feed2imap Traceback (most recent call last): 13: from /usr/bin/feed2imap:23:in `' 12: from /usr/bin/feed2imap:23:in `load' 11: from /usr/share/rubygems- integration/all/gems/feed2imap-1.2.6/bin/feed2imap:5:in `' 10: from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require' 9: from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require' 8: from /usr/share/rubygems- integration/all/gems/feed2imap-1.2.6/lib/feed2imap/feed2imap.rb:23:in `' 7: from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require' 6: from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require' 5: from /usr/share/rubygems- integration/all/gems/feed2imap-1.2.6/lib/feed2imap/config.rb:24:in `' 4: from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require' 3: from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require' 2: from /usr/share/rubygems- integration/all/gems/feed2imap-1.2.6/lib/feed2imap/maildir.rb:22:in `' 1: from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require' /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require': cannot load such file -- rmail (LoadError) -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.4-zef (SMP w/16 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 feed2imap depends on: ii ruby 1:2.7+2 ii ruby-feedparser 0.9.6-1 feed2imap recommends no packages. Versions of packages feed2imap suggests: pn imap-server ii kmail [imap-client] 4:20.08.3-1 -- no debconf information -- Sylvain L. Sauvage
Bug#972114: sympa: CVE-2020-26880
Hi, Following user questions, here's my understanding of the current situation: - The issue is partially fixed in Debian by optionally not setting the setuid permissions (debconf question), and setting 'aliases_program' to a method that does not require root (postmap/postalias for Postfix, /bin/true for Exim4, etc.). - Likewise, the issue is partially fixed in upstream dev through ./configure --disable-setuid_newaliases --disable-setuid - The issue will be completely fixed once all MTAs are supported, in particular sendmail which requires calling 'newaliases' as root. This could be done e.g. setuid-wrapping not sympa but just the 'newaliases' command, or dropping support for root 'newaliases' entirely. - Upstream tracks this issue at https://github.com/sympa-community/sympa/issues/1009 Discuss the issue there in priority. Cheers! Sylvain
Bug#978932: sympa: webinterface broken after installing 6.2.40~dfsg-1+deb10u1
Hi, This looks like a duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972189 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972189#45 In the buster version though, CGI mode (which fcgiwrap emulates) was removed from Sympa hence why I didn't add the same NEWS note as in stretch. It looks like this was still working somehow. For the record here is the NEWS note: The fix for the CVE-2020-10936 security issue forced us to drop CGI mode for wwsympa earlier than officially (6.2.24). In particular, users of nginx+fcgiwrap are invited to switch to nginx+spawn-fcgi: https://sympa-community.github.io/manual/install/configure-http-server-spawnfcgi.html See also: https://bugs.debian.org/972189 https://github.com/sympa-community/sympa/issues/1020 Cheers! Sylvain On 31/12/2020 17:41, Tobias Frost wrote: Package: sympa Version: 6.2.40~dfsg-1+deb10u1 Severity: important Dear Maintainer, After installation of the security update the web isterface is defunct. It still loads the "default" site (here: https://$DOMAIN/wws/) but that also the site that will be loaded when selecting an menue entry, for example "Login". (IOW, Login not possible as the login form is not presented) Downgrading to 6.2.40~dfsg-1 makes it work again. Webserver is an nginx instance. The only hint I got (could be a red herring) is this in the nginx error log, the sympa log is silent… Heres a example of the nginx one: (There are many of those…) 2020/12/27 12:13:57 [error] 8193#8193: *2819965 FastCGI sent in stderr: "[Sun Dec 27 12:13:57 2020] wwsympa.fcgi: Use of uninitialized value in string ne at /usr/share/sympa/lib/Sympa/WWW/Session.pm line 408.^M [Sun Dec 27 12:13:57 2020] wwsympa.fcgi: Use of uninitialized value $remote_addr in string ne at /usr/share/sympa/lib/Sympa/WWW/Session.pm line 408" while reading upstream, client: 80.209.204.233, server: lists.regensburg-repariert.de, request: "GET /wws/reviewbouncing/info HTTP/2.0", upstream: "fastcgi://unix:/run/fcgiwrap.socket:", host: "lists.regensburg-repariert.de" 2020/12/27 12:14:21 [error] 8193#8193: *2819965 FastCGI sent in stderr: "[Sun Dec 27 12:14:21 2020] wwsympa.fcgi: Use of uninitialized value in string ne at /usr/share/sympa/lib/Sympa/WWW/Session.pm line 408.^M (Those started exactly on Dec 24, after unattende-upgrades pulled in the security update) Let me know if I can provide more information… Cheers,
Bug#976070: openvpn fails with iproute option
Hello, Has any progress been made on this? i tried to apply the Arch patch manually, but either it doesn't work or I didn't do it right. Downgrading to 2.4 is only workaround for me Thank you
Bug#947431: xerces-c: CVE-2018-1311: use-after-free vulnerability processing external DTD
Excellent! I just re-uploaded 3.2.2+debian-1+deb10u1 with the updated patch. (and tested in a i386 chroot for good measure) I'm now adapting for stretch-lts (which has a monolithic test result). Cheers! Sylvain
Bug#961491: CVE-2020-10936: Security flaws in setuid wrappers
On 07/12/2020 12:06, Stefan Hornburg (Racke) wrote:
On 12/7/20 10:52 AM, Sylvain Beucler wrote:
This high-severity issue was marked with:
[buster] - sympa (Will be fixed via point release)
Consequently I am surprised that it wasn't part of last week's Debian 10.7
point release.
What happened?
Can we consider switching to a DSA?
Yes, sorry I missed that point release. If you want a DSA, that's fine for me.
Status update: the update is ready and a debdiff was sent for approval
to the security team 2 days ago.
Cheers!
Sylvain
diff -Nru sympa-6.2.40~dfsg/debian/changelog sympa-6.2.40~dfsg/debian/changelog
--- sympa-6.2.40~dfsg/debian/changelog 2019-01-20 16:57:14.0 +0100
+++ sympa-6.2.40~dfsg/debian/changelog 2020-12-10 14:39:54.0 +0100
@@ -1,3 +1,21 @@
+sympa (6.2.40~dfsg-1+deb10u1) buster-security; urgency=high
+
+ * Non-maintainer upload.
+ * CVE-2020-10936: Sympa allows privilege escalation through setuid
+wrappers. (Closes: #961491)
+ * CVE-2020-26932: restrict access to sympa_newaliases-wrapper (setuid
+root) to group sympa. (Closes: #971904)
+ * Ask the user whether they want/need sympa_newaliases-wrapper to
+be setuid root (CVE-2020-26880 mitigation).
+ * CVE-2020-9369: prevents creation of temporary files and email
+notifications to listmasters when encountering malformed input
+parameters. (Closes: #952428)
+ * CVE-2020-29668: Sympa allows remote attackers to obtain full SOAP API
+access by sending any arbitrary string (except one from an expired
+cookie) as the cookie value to authenticateAndRun. (Closes: #976020).
+
+ -- Sylvain Beucler Thu, 10 Dec 2020 14:39:54 +0100
+
sympa (6.2.40~dfsg-1) unstable; urgency=medium
* New upstream release.
diff -Nru sympa-6.2.40~dfsg/debian/config sympa-6.2.40~dfsg/debian/config
--- sympa-6.2.40~dfsg/debian/config 2018-12-22 19:47:42.0 +0100
+++ sympa-6.2.40~dfsg/debian/config 2020-12-08 18:37:40.0 +0100
@@ -124,6 +124,10 @@
db_go
fi
+# Ask for sympa_newaliases-wrapper to be setuid root
+db_input high sympa/sympa_newaliases-wrapper-setuid-root || [ $? -eq 30 ]
+db_go
+
# Ask for spool directories removal
db_input medium wwsympa/remove_spool || [ $? -eq 30 ]
db_go
diff -Nru sympa-6.2.40~dfsg/debian/patches/CVE-2020-10936.patch sympa-6.2.40~dfsg/debian/patches/CVE-2020-10936.patch
--- sympa-6.2.40~dfsg/debian/patches/CVE-2020-10936.patch 1970-01-01 01:00:00.0 +0100
+++ sympa-6.2.40~dfsg/debian/patches/CVE-2020-10936.patch 2020-12-08 19:03:59.0 +0100
@@ -0,0 +1,94 @@
+Origin: https://github.com/sympa-community/sympa/commit/3f8449c647e5ab32cf6f8837cb600c1756b6189c
+Last-Update: 2020-12-08
+Reviewed-by: Sylvain Beucler
+
+From 3f8449c647e5ab32cf6f8837cb600c1756b6189c Mon Sep 17 00:00:00 2001
+From: IKEDA Soji
+Date: Fri, 27 Mar 2020 21:28:18 +0900
+Subject: [PATCH] Sympa SA 2020-002 (candidate): Setuid wrappers should clear
+ environment variables to avoid exploits.
+
+---
+ src/cgi/sympa_soap_server-wrapper.fcgi.c | 7 ++-
+ src/cgi/wwsympa-wrapper.fcgi.c | 7 ++-
+ src/libexec/sympa_newaliases-wrapper.c | 7 ++-
+ 3 files changed, 18 insertions(+), 3 deletions(-)
+
+diff --git a/src/cgi/sympa_soap_server-wrapper.fcgi.c b/src/cgi/sympa_soap_server-wrapper.fcgi.c
+index f4c6a6645..435d40c6b 100644
+--- a/src/cgi/sympa_soap_server-wrapper.fcgi.c
b/src/cgi/sympa_soap_server-wrapper.fcgi.c
+@@ -6,6 +6,9 @@
+ Copyright (c) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
+ 2006, 2007, 2008, 2009, 2010, 2011 Comite Reseau des Universites
+ Copyright (c) 2011, 2012, 2013, 2014, 2015, 2016, 2017 GIP RENATER
++ Copyright 2020 The Sympa Community. See the AUTHORS.md
++ file at the top-level directory of this distribution and at
++ <https://github.com/sympa-community/sympa.git>.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+@@ -24,8 +27,10 @@
+ #include
+
+ int main(int argn, char **argv, char **envp) {
++char *myenvp[] = { "IFS= \t\n", "PATH=/bin:/usr/bin", NULL };
++
+ setreuid(geteuid(),geteuid());
+ setregid(getegid(),getegid());
+ argv[0] = SYMPASOAP;
+-return execve(SYMPASOAP,argv,envp);
++return execve(SYMPASOAP, argv, myenvp);
+ }
+diff --git a/src/cgi/wwsympa-wrapper.fcgi.c b/src/cgi/wwsympa-wrapper.fcgi.c
+index c66c7f82b..34198ecf9 100644
+--- a/src/cgi/wwsympa-wrapper.fcgi.c
b/src/cgi/wwsympa-wrapper.fcgi.c
+@@ -6,6 +6,9 @@
+ Copyright (c) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
+ 2006, 2007, 2008, 2009, 2010, 2011 Comite Reseau des Universites
+ Copyright (c) 2011, 2012, 2013, 2014, 2015, 2016, 2017 GIP RENATER
++ Copyright 2020 The Sympa Community. See the AUTHORS.md
++ file at the top-level directory of this distribution and at
++ <https://github.com/sympa-community/sympa.git>.
+
+ This program is free software; you c
Bug#947431: xerces-c: CVE-2018-1311: use-after-free vulnerability processing external DTD
On 11/12/2020 18:40, Bill Blough wrote: This patch has been applied in 3.2.3+debian-2 which has been uploaded to unstable. I'll leave this bug open in hopes of an eventual upstream fix. Great! On 10/12/2020 09:44, Sébastien Delafond wrote: > thanks for the debdiff, it looks good and the trade-off makes sense. You > can upload to security-master and I'll take care of the DSA soon. I did more tests during the past few hours (checking that XERCES_DISABLE_DTD does address the memory leak and using a couple reverse dependencies) and just uploaded the buster update to security master. (and I'm preparing another update for LTS.) Cheers! Sylvain
Bug#947431: xerces-c: CVE-2018-1311: use-after-free vulnerability processing external DTD
Hi, Here's a debdiff against buster. The testsuite passes, provided we modify MemHandlerTest1 to take the leak into account. What do you think? Cheers! Sylvain Beucler Debian LTS Team On 24/11/2020 17:39, Bill Blough wrote: The package has a test suite, so that's probably the minimum. But I'm not sure how much it exercises the DTD code, if at all. I also typically test with some of our internal code at work. But again, no DTDs in use there, either. On Mon, Nov 23, 2020 at 03:56:37PM +0100, Sylvain Beucler wrote: Hi, I can assist with this, notably a LTS upload - not necessarily immediately either. Bill, do you have testing procedures to recommend for this package? Security Team, before issuing a LTS upload, what is your view on a Stable upload for this issue? Cheers! Sylvain Beucler Debian LTS Team On 23/11/2020 03:01, Bill Blough wrote: Yes, this seems reasonable. I'll prepare an upload to unstable prior to the freeze. But it likely won't be for a couple of weeks due to my current workload. Since I assume one of your concerns is for LTS, feel free to do the LTS upload. Or, if you'd rather, I can make an attempt at that in a couple of weeks as well. diff -Nru xerces-c-3.2.2+debian/debian/changelog xerces-c-3.2.2+debian/debian/changelog --- xerces-c-3.2.2+debian/debian/changelog 2018-09-19 21:19:49.0 +0200 +++ xerces-c-3.2.2+debian/debian/changelog 2020-12-09 16:42:11.0 +0100 @@ -1,3 +1,12 @@ +xerces-c (3.2.2+debian-1+deb10u1) buster-security; urgency=medium + + * Non-maintainer upload. + * CVE-2018-1311 mitigation: fix use-after-free vulnerability when +processing external DTD, at the expense of a memory leak. Users may +mitigate both by setting the XERCES_DISABLE_DTD environment variable. + + -- Sylvain Beucler Wed, 09 Dec 2020 16:42:11 +0100 + xerces-c (3.2.2+debian-1) unstable; urgency=medium * New upstream version 3.2.2+debian Closes: 909202 diff -Nru xerces-c-3.2.2+debian/debian/patches/CVE-2018-1311-mitigation.patch xerces-c-3.2.2+debian/debian/patches/CVE-2018-1311-mitigation.patch --- xerces-c-3.2.2+debian/debian/patches/CVE-2018-1311-mitigation.patch 1970-01-01 01:00:00.0 +0100 +++ xerces-c-3.2.2+debian/debian/patches/CVE-2018-1311-mitigation.patch 2020-12-09 16:42:11.0 +0100 @@ -0,0 +1,35 @@ + +https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-1311 + +Index: xerces-c-3.2.2+debian/src/xercesc/internal/IGXMLScanner.cpp +=== +--- xerces-c-3.2.2+debian.orig/src/xercesc/internal/IGXMLScanner.cpp xerces-c-3.2.2+debian/src/xercesc/internal/IGXMLScanner.cpp +@@ -1532,7 +1532,6 @@ void IGXMLScanner::scanDocTypeDecl() + DTDEntityDecl* declDTD = new (fMemoryManager) DTDEntityDecl(gDTDStr, false, fMemoryManager); + declDTD->setSystemId(sysId); + declDTD->setIsExternal(true); +-Janitor janDecl(declDTD); + + // Mark this one as a throw at end + reader->setThrowAtEnd(true); +@@ -3095,7 +3094,6 @@ Grammar* IGXMLScanner::loadDTDGrammar(co + DTDEntityDecl* declDTD = new (fMemoryManager) DTDEntityDecl(gDTDStr, false, fMemoryManager); + declDTD->setSystemId(src.getSystemId()); + declDTD->setIsExternal(true); +-Janitor janDecl(declDTD); + + // Mark this one as a throw at end + newReader->setThrowAtEnd(true); +Index: xerces-c-3.2.2+debian/tests/expected/MemHandlerTest1.log +=== +--- xerces-c-3.2.2+debian.orig/tests/expected/MemHandlerTest1.log xerces-c-3.2.2+debian/tests/expected/MemHandlerTest1.log +@@ -1,4 +1,4 @@ +-At destruction, domBuilderMemMonitor has 0 bytes. +-At destruction, sax2MemMonitor has 0 bytes. +-At destruction, sax1MemMonitor has 0 bytes. ++At destruction, domBuilderMemMonitor has 276 bytes. ++At destruction, sax2MemMonitor has 276 bytes. ++At destruction, sax1MemMonitor has 276 bytes. + At destruction, staticMemMonitor has 0 bytes. diff -Nru xerces-c-3.2.2+debian/debian/patches/series xerces-c-3.2.2+debian/debian/patches/series --- xerces-c-3.2.2+debian/debian/patches/series 2018-09-19 21:19:49.0 +0200 +++ xerces-c-3.2.2+debian/debian/patches/series 2020-12-09 16:42:11.0 +0100 @@ -0,0 +1 @@ +CVE-2018-1311-mitigation.patch
Bug#961491: CVE-2020-10936: Security flaws in setuid wrappers
Hi, On Sat, 10 Oct 2020 09:45:42 +0300 "Stefan Hornburg (Racke)" wrote: On 10/7/20 3:03 PM, Sylvain Beucler wrote: > I noticed this local root escalation yesterday and I'm working on a > Stretch LTS update. > See also https://salsa.debian.org/sympa-team/sympa/-/merge_requests/1 > > Are there plans to update buster? Hello Sylvain, thanks a lot of for your patch! I will talk to the security team concerning buster. This high-severity issue was marked with: [buster] - sympa (Will be fixed via point release) Consequently I am surprised that it wasn't part of last week's Debian 10.7 point release. What happened? Can we consider switching to a DSA? Sylvain Beucler Debian LTS Team
Bug#947431: xerces-c: CVE-2018-1311: use-after-free vulnerability processing external DTD
Hi, I can assist with this, notably a LTS upload - not necessarily immediately either. Bill, do you have testing procedures to recommend for this package? Security Team, before issuing a LTS upload, what is your view on a Stable upload for this issue? Cheers! Sylvain Beucler Debian LTS Team On 23/11/2020 03:01, Bill Blough wrote: Yes, this seems reasonable. I'll prepare an upload to unstable prior to the freeze. But it likely won't be for a couple of weeks due to my current workload. Since I assume one of your concerns is for LTS, feel free to do the LTS upload. Or, if you'd rather, I can make an attempt at that in a couple of weeks as well.
Bug#891469: awstats: Path traversal in config parameter if site config is missing.
Hi, Since awstats is currently unmaintained, can you request a new CVE for this at https://cveform.mitre.org/ ? This way it'll be properly monitored and taken care of in distros. Cheers! Sylvain On Sun, 25 Feb 2018 21:33:34 +0100 =?utf-8?b?VG9tYcW+IMWgb2xj?= wrote: Package: awstats Version: 7.6+dfsg-2 Severity: normal Dear Maintainer, the patch for CVE-2017-1000501 seems to have been incomplete. Please see this report upstream: https://github.com/eldy/awstats/issues/90 awstats will parse arbitrary files passed in the "config" parameter if the default /etc/awstats/awstats.conf is not present. Debian package will install awstats.conf, so a default install does not seem to be vulnerable. However it is possible to use awstats with separate configs for different sites without the default awstats.conf (although README.Debian recommends leaving awstats.conf in place) I can confirm that the reported issue exists in awstats 7.6+dfsg-2 and 7.6+dfsg-1+deb9u1. Steps to reproduce (on Stretch) # apt-get install awstats # rm /etc/awstats/awstats.conf # cp /usr/share/doc/awstats/examples/apache.conf /etc/apache2/conf-available/awstats.conf # a2enconf awstats # systemctl reload apache2 Visit http://localhost/cgi-bin/awstats.pl?config=/etc/passwd -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-6-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) Versions of packages awstats depends on: ii perl 5.24.1-3+deb9u2 Versions of packages awstats recommends: ii libnet-xwhois-perl 0.90-4 Versions of packages awstats suggests: ii apache2 [httpd] 2.4.25-3+deb9u3 pn libgeo-ipfree-perl ii libnet-dns-perl 1.07-1 ii libnet-ip-perl 1.26-1 ii liburi-perl 1.71-1 -- Configuration Files: /etc/awstats/awstats.conf [Errno 2] No such file or directory: '/etc/awstats/awstats.conf'
Bug#890414: awstats: run-parts doesnt work with .sh files
For your consideration: https://salsa.debian.org/debian/awstats/-/merge_requests/2 The awstats package is orphaned. Depending on the answers I may do a NMU. Cheers! Sylvain On Wed, 6 May 2020 13:36:23 + debian_reportbug_202...@michaelaltfield.net wrote: Package: awstats Version: 7.6+dfsg-2 Followup-For: Bug #890414 This is still an issue on Debian 10. Any update on when this will be fixed? Steps to reproduce on a fresh install of Debian 10: sudo su - apt-get -y install nginx awstats run-parts --list /etc/logrotate.d/httpd-prerotate The below execution demonstrates the issue and a potential fix (moving /etc/logrotate.d/httpd-prerotate/awstats/prerotate.sh to /etc/logrotate.d/httpd-prerotate/awstats-prerotate)
Bug#947431: xerces-c: CVE-2018-1311: use-after-free vulnerability processing external DTD
Hi, It seems likely that this issue won't get a proper fix soon, due to upstream inactivity in that area, and the requirement of breaking binary compatibility. Use-after-free is a serious vulnerability as it can lead to various issues including code execution, and the issue was rated 8.1/10 by NVD: http://cwe.mitre.org/data/definitions/416.html https://nvd.nist.gov/vuln/detail/CVE-2018-1311 RedHat introduced a trade-off with the simple attached patch which fixes this issue at the expense of a memory leak. (you can also get it from http://vault.centos.org/7.7.1908/updates/Source/SPackages/xerces-c-3.1.1-10.el7_7.src.rpm) Do we want to follow suit? Cheers! Sylvain Beucler Debian LTS Team On Thu, 26 Dec 2019 21:40:38 +0100 Salvatore Bonaccorso wrote: Source: xerces-c Version: 3.2.2+debian-1 Severity: important Tags: security upstream Forwarded: https://issues.apache.org/jira/browse/XERCESC-2188 Control: found -1 3.1.4+debian-2+deb9u1 Control: found -1 3.1.4+debian-1 Hi, The following vulnerability was published for xerces-c. There is no upstream fix and only suggested mitigations, at time of writing the bugreport. CVE-2018-1311[0]: | The Apache Xerces-C 3.0.0 to 3.2.2 XML parser contains a use-after- | free error triggered during the scanning of external DTDs. This flaw | has not been addressed in the maintained version of the library and | has no current mitigation other than to disable DTD processing. This | can be accomplished via the DOM using a standard parser feature, or | via SAX using the XERCES_DISABLE_DTD environment variable. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2018-1311 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1311 [1] https://issues.apache.org/jira/browse/XERCESC-2188 [2] https://xerces.apache.org/xerces-c/secadv/CVE-2018-1311.txt [3] https://marc.info/?l=xerces-c-users=157653840106914=2 https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-1311 --- xerces-c-3.0.1/src/xercesc/internal/IGXMLScanner.cpp.cve1311 +++ xerces-c-3.0.1/src/xercesc/internal/IGXMLScanner.cpp @@ -1533,7 +1533,6 @@ DTDEntityDecl* declDTD = new (fMemoryManager) DTDEntityDecl(gDTDStr, false, fMemoryManager); declDTD->setSystemId(sysId); declDTD->setIsExternal(true); -Janitor janDecl(declDTD); // Mark this one as a throw at end reader->setThrowAtEnd(true); @@ -3154,7 +3153,6 @@ DTDEntityDecl* declDTD = new (fMemoryManager) DTDEntityDecl(gDTDStr, false, fMemoryManager); declDTD->setSystemId(src.getSystemId()); declDTD->setIsExternal(true); -Janitor janDecl(declDTD); // Mark this one as a throw at end newReader->setThrowAtEnd(true);
Bug#974991: sagemath: segfault on startup
Hello >From trial and error, my workaround is to downgrade python3-cypari2. I have no idea whether it is appropriate or if it is going to trigger something else, but at least I don't have a startup crash anymore. Here are the steps: - add "deb https://snapshot.debian.org/archive/debian/20200628T024451Z unstable main" to /etc/apt/sources.list - sudo apt -o Acquire::Check-Valid-Until=false update - sudo apt install python3-cypari2=2.1.1-2+b2 It seems it is a recurring situation, 906796 happened two years ago. -- Sylvain
Bug#974034: Update obsolete/non-free FPM configuration procedure
Package: php7.4-fpm Tags: patch Cross-referencing https://salsa.debian.org/php-team/php/-/merge_requests/5 Cheers! Sylvain
Bug#972114: sympa: CVE-2020-26880
Hi Stefan, On 05/11/2020 15:29, Stefan Hornburg (Racke) wrote: On 11/5/20 3:19 PM, Sylvain Beucler wrote: @racke, following your work at https://github.com/sympa-community/sympa/pull/1015 it seems we'd need a new debconf question to ask the user whether they want the setuid wrapper to be activated or not. Yes, good idea. But it would make sense to add some more documentation and maybe we can also ask about the mail server in use. E.g. with Exim you don't need to run the alias command at all. I implemented conditional setuid for sympa_newaliases-wrapper at https://salsa.debian.org/sympa-team/sympa/-/merge_requests/2 explaining the situation in the debconf question as well as pointing to 'aliases_program'. Let me know if that's OK with you and I'll backport it for stretch. Cheers! Sylvain Beucler Debian LTS Team
Bug#972189: sympa: CVE-2020-10936 regression - removal of needed environment variables
Hi, From what I understand the FCGI wrapper was used as CGI through e.g. fcgiwrap, and upstream recommended to switch to fcgi-spawn following https://sympa-community.github.io/manual/install/configure-http-server-spawnfcgi.html Carsten agreed and suggested we add a note about this in the Debian documentation, so I plan to add a note in README.Debian or NEWS.Debian. https://github.com/sympa-community/sympa/issues/1020#issuecomment-710763168 Given there were no other reports I believe this addresses the issue. Cheers! Sylvain Beucler Debian LTS Team
Bug#972114: sympa: CVE-2020-26880
Hi, @racke, following your work at https://github.com/sympa-community/sympa/pull/1015 it seems we'd need a new debconf question to ask the user whether they want the setuid wrapper to be activated or not. This could be added even before the pull request merged I think, as toggling the setuid bit on the wrapper is equivalent to introducing 'alias_wrapper' + setting it of 'off' + removing the wrapper (IIUC). What do you think? If you're OK with this direction I can provide a patch, which I'll probably backport to stretch to mitigate this vulnerability (aka fix it for every MTA but sendmail AFAICS) Cheers! Sylvain Beucler Debian LTS Team
Bug#973544: www.debian.org: LTS Security Advisories RSS links to wrong locations
Hi Laura, Here's a pull request for your consideration: https://salsa.debian.org/webmaster-team/webwml/-/merge_requests/566 I didn't switch to get_recent_security_list_rdf() because 'dsa.rdf.in' (non-LTS/DSA) doesn't use it either. Instead I handled the LTS case in get_recent_list()/grab_titles(). Cheers! Sylvain On 01/11/2020 21:13, Laura Arjona Reina wrote: Hi Nobuhiro Ban, Thanks for reporting this issue. The build of those RSS feeds is done via the get_recent_list() function in the recent_list template: https://salsa.debian.org/webmaster-team/webwml/-/blob/master/english/template/debian/recent_list.wml However, that function is not prepared for security advisories in other path different than www.debian.org/security. In any case, I see that other security lists now call to a different (improved) template: https://salsa.debian.org/webmaster-team/webwml/-/blob/master/english/template/debian/recent_list_security.wml But I couldn't find the correct way to call the function get_recent_security_list_rdf so it creates the RSS feed. CC'ing the debian-lts mailing list for the case they can have a look. Kind regards, El 1/11/20 a las 16:40, Nobuhiro Ban escribió: Package: www.debian.org Severity: normal Dear Maintainer, Debian LTS Security Advisories RSS (https://www.debian.org/lts/security/dla) links to wrong locations. For example: https://www.debian.org/security/2020/dla-2425; /> It should be https://www.debian.org/lts/security/2020/dla-2425 . Regards, Nobuhiro Ban
Bug#972189: sympa: CVE-2020-10936 regression - removal of needed environment variables
Hi, Thank you both for notifying me. For reasons stated in dla-needed.txt, and more importantly for reasons mentioned internally (see elts-git or Holger), I can't dedicate more time this month. >From a quick look: - the patch for older versions is the same besides the copyright notices. - I'm not sure why the FCGI wrapper (which is daemonized and multi-requests) would need to query its environment for REMOTE_ADDR (which changes with each request and is normally sent to the FCGI daemon through its socket), Carsten may need to provide additional details and/or check https://github.com/sympa-community/sympa/issues/1020 for work-arounds. Cheers! Sylvain
Bug#971904: sympa: restrict access to sympa_newaliases-wrapper (setuid root) to group sympa
Source: sympa Tags: patch Cross-referencing https://salsa.debian.org/sympa-team/sympa/-/merge_requests/1 Cheers! Sylvain Beucler Debian LTS Team
Bug#961491: fixed in sympa 6.2.40~dfsg-5
Hi, I noticed this local root escalation yesterday and I'm working on a Stretch LTS update. See also https://salsa.debian.org/sympa-team/sympa/-/merge_requests/1 Are there plans to update buster? Cheers! Sylvain
Bug#971560: libsane-common 1.0.25-4.1+deb9u1 Stretch security update missing lots of files
Hi, The package is in this state since Aug 17, I think we can afford to wait a few more days for testing. So yes, please do test on Tuesday. Cheers! Sylvain On 03/10/2020 00:41, Ivan Baldo wrote: > Hello. > The soonest I could try to check, is this Tuesday 6th 19:00 -0300, sorry. > Let me know if that's useful or too late. > Thanks! > > El vie., 2 de oct. de 2020 a la(s) 10:22, Sylvain Beucler > (b...@beuc.net) escribió: >> >> Hi, >> >> On 02/10/2020 13:51, Ivan Baldo wrote: >>> El vie., 2 de oct. de 2020 a la(s) 06:48, Sylvain Beucler >>> (b...@beuc.net) escribió: >>>> >>>> Hi, >>>> >>>>> El jue., 1 de oct. de 2020 a la(s) 19:32, Sylvain Beucler >>>>> (b...@beuc.net) escribió: >>>>>> This could be due to a bug when building the 'all' and 'amd64' packages >>>>>> separately. >>>> >>>> I can reproduce the 2 debdiff-s with 'debuild -A' and 'debuild -B' >>>> respectively. >>>> >>>> I'm currently backporting fixes from 1.0.27-1~experimental3 to fix the >>>> issue, and updating our procedures to test this case in the future. >>> >>> Great, thanks a lot!!! >> >> I prepared a new package at: >> https://www.beuc.net/tmp/debian-lts/sane-backends/ >> that I plan to upload as a regression fix. >> >> (Note: sane-dll is now consistently removed, as it previously evaded >> deletion only in amd64, see #971592.) >> >> Can you test it? >> >> Cheers! >> Sylvain > > >
Bug#908678: Update on the security-tracker git discussion
Hi, On Tue, 6 Aug 2019 08:28:43 +0200 Salvatore Bonaccorso wrote: > Thanks for keeping track and following up. > > On Tue, Aug 06, 2019 at 08:05:11AM +0200, Bastian Blank wrote: > > Moin > > > > On Tue, Jul 02, 2019 at 01:38:10PM +0200, Moritz Muehlenhoff wrote: > > > On Tue, Jul 02, 2019 at 01:25:43PM +0200, Salvatore Bonaccorso wrote: > > > > p.s.: Question is if we should do a split as well for the other types of > > > > files which are supported (DSA, TDSA, ...) while at it. > > > We can axe out DTSA/* while we're at it. > > > For DSA/list (and DLA/list) we can initially keep it as a single file, it > > > can > > > still be split later on if necessary. > > > > Following up to > > > > | Please provide a plan how and when to fix this before 2019-06-30. > > > > We have now one month later. Please provide the plan. > > The items in > https://salsa.debian.org/security-tracker-team/security-tracker-service/issues/1 > needs further detailed and then sorted/prioritized. Later actual > implementation work on making the split possible on tracker and other > tooling side needs to happen. We cannot depend on a non-functional > instance for the day to day work, so all of the above basically will > need to be ported in some sensible way. > > Progress is slow due to other time limitations in day to day tasks. > > Still if it is going to be too much burden for salsa admin and needs > to be fast, then I only see that we temporarily switch away from salsa > to gitlab or another hosting (github will not work) and then move back > once the split has finally happened. It seems a bit difficult to make a big switch, probably because it's not easy to know and test all the various involved scripts. Considering a more progressive approach, is there something preventing us from switching to the rewritten repository and split/merging the file, something like: diff --git a/conf/post-merge b/conf/post-merge new file mode 100755 index 00..a9991c1cc9 --- /dev/null +++ b/conf/post-merge @@ -0,0 +1,3 @@ +#!/bin/sh +echo "post-merge" +[ -f data/CVE/1999.list ] && cat data/CVE/*.list > data/CVE/list diff --git a/conf/pre-commit b/conf/pre-commit index 767e478e36..12e781e97d 100755 --- a/conf/pre-commit +++ b/conf/pre-commit @@ -5,3 +5,4 @@ set -e exec 1>&2 make check-syntax +bin/split-by-year.py ? Cheers! Sylvain
Bug#971560: libsane-common 1.0.25-4.1+deb9u1 Stretch security update missing lots of files
Hi, On 02/10/2020 13:51, Ivan Baldo wrote: > El vie., 2 de oct. de 2020 a la(s) 06:48, Sylvain Beucler > (b...@beuc.net) escribió: >> >> Hi, >> >>> El jue., 1 de oct. de 2020 a la(s) 19:32, Sylvain Beucler >>> (b...@beuc.net) escribió: >>>> This could be due to a bug when building the 'all' and 'amd64' packages >>>> separately. >> >> I can reproduce the 2 debdiff-s with 'debuild -A' and 'debuild -B' >> respectively. >> >> I'm currently backporting fixes from 1.0.27-1~experimental3 to fix the >> issue, and updating our procedures to test this case in the future. > > Great, thanks a lot!!! I prepared a new package at: https://www.beuc.net/tmp/debian-lts/sane-backends/ that I plan to upload as a regression fix. (Note: sane-dll is now consistently removed, as it previously evaded deletion only in amd64, see #971592.) Can you test it? Cheers! Sylvain
Bug#971592: sane-backends: filtering out libsane-dll doesn't work on combined builds
Source: sane-backends Hi, I'm preparing a stretch LTS update for sane-backends and I noticed that there is code to filter out /usr/lib/$(DEB_HOST_MULTIARCH)/sane/libsane-dll.*, but that the file was still present: # dpkg --contents libsane_1.0.25-4.1_amd64.deb | grep dll # stretch -rw-r--r-- root/root 978 2017-05-21 10:04 ./usr/lib/x86_64-linux-gnu/sane/libsane-dll.la -rw-r--r-- root/root 30632 2017-05-21 10:04 ./usr/lib/x86_64-linux-gnu/sane/libsane-dll.so.1.0.25 lrwxrwxrwx root/root 0 2017-05-21 10:04 ./usr/lib/x86_64-linux-gnu/sane/libsane-dll.so.1 -> libsane-dll.so.1.0.25 Looking further, the filtering only works in separate arch/indep (-B/-A) builds, because the dll* files are cleaned by install-arch but re-installed right after by install-indep. The issue is still present in sid. This is not a problem right now in the unstable archive, but this could be depending on how the package is rebuilt in the future and/or in derivatives: $ dpkg --contents libsane1_1.0.31-2_amd64.deb | grep dll # downloaded from sid [nothing] $ dpkg --contents libsane1_1.0.31-2_amd64.deb | grep dll # `debuild` from source on sid -rw-r--r-- root/root 92232 2020-09-27 13:38 ./usr/lib/x86_64-linux-gnu/sane/libsane-dll.so.1.0.31 lrwxrwxrwx root/root 0 2020-09-27 13:38 ./usr/lib/x86_64-linux-gnu/sane/libsane-dll.so.1 -> libsane-dll.so.1.0.31 Cheers! Sylvain Beucler Debian LTS Team
Bug#971560: libsane-common 1.0.25-4.1+deb9u1 Stretch security update missing lots of files
Hi, > El jue., 1 de oct. de 2020 a la(s) 19:32, Sylvain Beucler > (b...@beuc.net) escribió: >> This could be due to a bug when building the 'all' and 'amd64' packages >> separately. I can reproduce the 2 debdiff-s with 'debuild -A' and 'debuild -B' respectively. I'm currently backporting fixes from 1.0.27-1~experimental3 to fix the issue, and updating our procedures to test this case in the future. Cheers! Sylvain
Bug#971560: libsane-common 1.0.25-4.1+deb9u1 Stretch security update missing lots of files
Hi, Thanks for report this issue. Something must have gone wrong when rebuilding the packages at Debian, because the packages I had built didn't have these differences. I just ran a local rebuild and I still have valid packages, with all the files. It's night-time here so I won't look in depth right now, but https://buildd.debian.org/status/package.php?p=sane-backends=stretch-security should contain possible errors. This could be due to a bug when building the 'all' and 'amd64' packages separately. Cheers! Sylvain
Bug#964432: ruby-rails update destroy redmine issue number linking
Hi all, On 03/08/2020 16:43, Utkarsh Gupta wrote: > On Mon, Aug 3, 2020 at 6:02 PM Sylvain Beucler wrote: >> This version is now impacted by new security issues, such as >> CVE-2020-8163, so I would recommend upgrading anyway. There is no place >> to upload a new version (in particular, not in ELTS where neither rails >> nor redmine are supported), This is not part of Debian per-se, but rails was recently added back to the list of supported packages in ELTS. Mike (in Cc:) claimed the next upload, so this is an opportunity to address a possible regression in CVE-2020-8164/CVE-2020-8165. Cheers! Sylvain
Bug#968369: sane-backends: broken dep-8 test?
Source: sane-backends Hi, I'm preparing a stretch LTS update for sane-backends and it seems debian/tests/start-net does not work as intended. I think the expected output is like: + scanimage -d net -L device `pnm:0' is a Noname PNM file reader virtual device device `pnm:1' is a Noname PNM file reader virtual device but due to grepping ':net' those line are not counted, and the test fails. CNT=`scanimage -d net -L | grep net: | wc -l` Grepping ':pnm' fixes the test: CNT=`scanimage -d net -L | grep pnm: | wc -l` Was that the intended use? Cheers! Sylvain Beucler Debian LTS Team
Bug#964432: ruby-rails update destroy redmine issue number linking
Hi, On 03/08/2020 13:52, Utkarsh Gupta wrote: > Whilst I am totally fine by this suggestion, but still asking.. > Would it make sense to fix this, since this upload was made just > around the time Jessie was EOL'ed. > Of course, I'd want people to upgrade, for sure, but in case they > can't, I don't want to leave them high and dry. > > D'you think there's anything that could be done here? > (or if that's too much to work on, maybe consider reverting the fixes?) This version is now impacted by new security issues, such as CVE-2020-8163, so I would recommend upgrading anyway. There is no place to upload a new version (in particular, not in ELTS where neither rails nor redmine are supported), and as far as I understand s.jaekel could revert the security fixes manually, nearly a month ago. What are you suggesting, more precisely? If after upgrading to Stretch, and despite my working test today, the regression persists, I'll have a look at it. Cheers! Sylvain
Bug#964432: ruby-rails update destroy redmine issue number linking
Hi, On 03/08/2020 10:38, Utkarsh Gupta wrote: > On 8/3/20 1:56 PM, Utkarsh Gupta wrote: >> On Tue, 07 Jul 2020 09:36:20 +0200 "s.jaekel" wrote: >>> Package: ruby-rails >>> Version: 2:4.1.8-1+deb8u7 >>> Severity: important >>> Tags: upstream >>> >>> I updated the ruby-rails packages last week. >>> Since then i can use the also installed redmine (3.0~20140825-8~deb8u4) >>> no longer link tickets together. >> >> This was not a regular upload but an upload by the LTS team. >> I've CC'ed Sylvain (& LTS team), so hopefully someone can take a look at it. > > I had snipped the bug report while CC'ing respective teams. > Please see #964432 for the entire bug report. It is more verbose. I tested with the latest redmine & ruby-rails in Stretch, and things appear to work fine (cf. attachment). Then I realized that this is about Debian Jessie which reached end-of-life a month ago, so the solution is to upgrade to Debian 9. Cheers! Sylvain
Bug#964950: nginx: CVE-2020-11724
In case this helps, here's some documentation to test the issue with the
new upstream test cases:
https://wiki.debian.org/LTS/TestSuites/nginx
and my planned stretch package:
https://www.beuc.net/tmp/debian-lts/nginx/
Cheers!
Sylvain Beucler
Debian LTS Team
diff -Nru nginx-1.10.3/debian/changelog nginx-1.10.3/debian/changelog
--- nginx-1.10.3/debian/changelog 2020-01-11 08:28:05.0 +0100
+++ nginx-1.10.3/debian/changelog 2020-07-13 11:40:49.0 +0200
@@ -1,3 +1,11 @@
+nginx (1.10.3-1+deb9u5) stretch-security; urgency=high
+
+ * Non-maintainer upload by the LTS Security Team.
+ * CVE-2020-11724: ngx_http_lua_subrequest.c allows HTTP request
+smuggling, as demonstrated by the ngx.location.capture API.
+
+ -- Sylvain Beucler Mon, 13 Jul 2020 11:40:49 +0200
+
nginx (1.10.3-1+deb9u4) stretch; urgency=medium
* Handle CVE-2019-20372, error page request smuggling
diff -Nru nginx-1.10.3/debian/modules/patches/nginx-lua/CVE-2020-11724.patch
nginx-1.10.3/debian/modules/patches/nginx-lua/CVE-2020-11724.patch
--- nginx-1.10.3/debian/modules/patches/nginx-lua/CVE-2020-11724.patch
1970-01-01 01:00:00.0 +0100
+++ nginx-1.10.3/debian/modules/patches/nginx-lua/CVE-2020-11724.patch
2020-07-13 11:40:49.0 +0200
@@ -0,0 +1,863 @@
+Origin:
https://github.com/openresty/openresty/commit/4e8b4c395f842a078e429c80dd063b232357
+Origin:
https://github.com/openresty/lua-nginx-module/commit/9ab38e8ee35fc08a57636b1b6190dca70b0076fa
+Last-Update: 2020-07-13
+Reviewed-by: Sylvain Beucler
+
+commit 96c330c3cb2a5abc95d293854801c7ba2896d1da
+Author: Thibault Charbonnier
+Date: Mon Mar 23 19:40:47 2020 -0700
+
+bugfix: prevented request smuggling in the ngx.location.capture API.
+
+From 9ab38e8ee35fc08a57636b1b6190dca70b0076fa Mon Sep 17 00:00:00 2001
+From: Thibault Charbonnier
+Date: Mon, 23 Mar 2020 19:40:47 -0700
+Subject: [PATCH] bugfix: prevented request smuggling in the
+ ngx.location.capture API.
+
+Signed-off-by: Yichun Zhang (agentzh)
+(tests)
+
+Index: nginx-lua/src/ngx_http_lua_subrequest.c
+===
+--- nginx-lua.orig/src/ngx_http_lua_subrequest.c
nginx-lua/src/ngx_http_lua_subrequest.c
+@@ -56,8 +56,6 @@ static ngx_str_t ngx_http_lua_content_l
+ ngx_string("Content-Length");
+
+
+-static ngx_int_t ngx_http_lua_set_content_length_header(ngx_http_request_t *r,
+-off_t len);
+ static ngx_int_t ngx_http_lua_adjust_subrequest(ngx_http_request_t *sr,
+ ngx_uint_t method, int forward_body,
+ ngx_http_request_body_t *body, unsigned vars_action,
+@@ -78,7 +76,7 @@ static void ngx_http_lua_cancel_subreq(n
+ static ngx_int_t ngx_http_post_request_to_head(ngx_http_request_t *r);
+ static ngx_int_t ngx_http_lua_copy_in_file_request_body(ngx_http_request_t
*r);
+ static ngx_int_t ngx_http_lua_copy_request_headers(ngx_http_request_t *sr,
+-ngx_http_request_t *r);
++ngx_http_request_t *pr, ngx_uint_t prcl);
+
+
+ /* ngx.location.capture is just a thin wrapper around
+@@ -622,8 +620,8 @@ ngx_http_lua_adjust_subrequest(ngx_http_
+ unsigned vars_action, ngx_array_t *extra_vars)
+ {
+ ngx_http_request_t *r;
+-ngx_int_trc;
+ ngx_http_core_main_conf_t *cmcf;
++ngx_uint_t prcl = 0;
+ size_t size;
+
+ r = sr->parent;
+@@ -633,46 +631,32 @@ ngx_http_lua_adjust_subrequest(ngx_http_
+ if (body) {
+ sr->request_body = body;
+
+-rc = ngx_http_lua_set_content_length_header(sr,
+-body->buf
+-? ngx_buf_size(body->buf)
+-: 0);
+-
+-if (rc != NGX_OK) {
+-return NGX_ERROR;
+-}
+-
+ } else if (!always_forward_body
+&& method != NGX_HTTP_PUT
+&& method != NGX_HTTP_POST
+&& r->headers_in.content_length_n > 0)
+ {
+-rc = ngx_http_lua_set_content_length_header(sr, 0);
+-if (rc != NGX_OK) {
+-return NGX_ERROR;
+-}
+-
+-#if 1
+ sr->request_body = NULL;
+-#endif
+
+ } else {
+-if (ngx_http_lua_copy_request_headers(sr, r) != NGX_OK) {
+-return NGX_ERROR;
++if (!r->headers_in.chunked) {
++prcl = 1;
+ }
+
+-if (sr->request_body) {
++if (sr->request_body && sr->request_body->temp_file) {
+
+ /* deep-copy the request body */
+
+-if (sr->request_body->temp_file) {
+-if (ngx_http_lua_copy_in_file_request_body(sr) != NGX_OK) {
+-return NGX_ERROR;
+-}
++if (ngx_http_lua_copy_in_file_request_body(sr) != NGX_OK) {
++return NGX_ERROR;
+ }
+
Bug#964950: nginx: CVE-2020-11724
Package: nginx X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security upstream Hi, The following vulnerability was published for ngx_lua. CVE-2020-11724[0]: | ngx_http_lua_subrequest.c allows HTTP request smuggling, as | demonstrated by the ngx.location.capture API. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2020-11724 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11724 Cheers! Sylvain Beucler Debian LTS Team
