Bug#1055827: ITP: elenv -- Emacs Lisp Environment Detection Library
Xiyue Deng writes: > Package: wnpp > Owner: Xiyue Deng > Severity: wishlist > > * Package name: elenv > Version : 0.1.0+git20231106.e7619ff > Upstream Author : Jen-Chieh Shen > * URL or Web page : g...@github.com:jcs-elpa/elenv.git > * License : GPL-3+ > Description : Emacs Lisp Environment Detection Library > > Elenv is an Emacs Lisp library that provides a consistent interface to > detect operating sytem types, graphic environments, environmental > variables, executables, etc. > > I intent to maintain this within the Debian Emacsen team. Forgot to mention that this package is a dependency of newer lsp-mode package. More packages will potentially use this in the future as well. -- Xiyue Deng
Bug#1055828: libqxmppqt5-dev has an undeclared file conflict on /usr/lib/x86_64-linux-gnu/pkgconfig/qxmpp.pc
Package: libqxmppqt5-dev Version: 1.5.5-0.1~exp1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + libqxmpp-dev libqxmppqt5-dev has an undeclared file conflict. This may result in an unpack error from dpkg. The file /usr/lib/x86_64-linux-gnu/pkgconfig/qxmpp.pc is contained in the packages * libqxmpp-dev * 1.3.2-2 as present in bullseye * 1.4.0-2 as present in bookworm|trixie|unstable * 1.4.0-2~bpo11+1 as present in bullseye-backports * libqxmppqt5-dev/1.5.5-0.1~exp1 as present in experimental These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected file. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1055827: ITP: elenv -- Emacs Lisp Environment Detection Library
Package: wnpp Owner: Xiyue Deng Severity: wishlist * Package name: elenv Version : 0.1.0+git20231106.e7619ff Upstream Author : Jen-Chieh Shen * URL or Web page : g...@github.com:jcs-elpa/elenv.git * License : GPL-3+ Description : Emacs Lisp Environment Detection Library Elenv is an Emacs Lisp library that provides a consistent interface to detect operating sytem types, graphic environments, environmental variables, executables, etc. I intent to maintain this within the Debian Emacsen team.
Bug#1055773: esptool: CVE-2023-46894
On Sat, Nov 11, 2023 at 08:51:30AM +0100, Salvatore Bonaccorso wrote: > The following vulnerability was published for esptool. > > CVE-2023-46894[0]: > | An issue discovered in esptool 4.6.2 allows attackers to view > | sensitive information via weak cryptographic algorithm. > > If I undestand the upstream discussion[1] correctly this is not > something hich is going to be fixed until the oldest earliest chips > are not supported anymore. So this bug is merely for documentation > purpose and can be closed once this support vanishes (or feel free to > aswer the above, we might then simply mark it as unimportant in the > security-tracker. I'd go one step further, and express that IMHO this is not a security vulnerability and that it shouldn't have been assigned a CVE in the first place. As you mentioned, based on upstream's comment above, old revisions of one of the supported chipsets were using AES ECB for secure boot and flash encryption, but newer ones have switched to newer cryptographic algorithms. esptool has kept support for the older algorithms, in order to keep the ability to work with older revisions of the hardware. Obviously software shouldn't default or recommend broken cryptographic ciphers, when it can be avoided. But I don't think it constitutes a vulnerability to merely implement them, when they are used to interface with the world as it exists outside of your software, such as for compatibility with hardware, network protocols etc. This is the equivalent of saying that coreutils is vulnerable because it ships md5sum, an implementation of a broken digest, or that browsers need a CVE for supporting older TLS ciphers, etc. Or perhaps even that python-cryptography itself needs a CVE because it ships an implementation of AES-ECB (or 3DES or whatever) :) Let me know if you disagree! Keeping the bug open until I hear from you. Thanks, Faidon
Bug#961598: O: sqlcipher -- Command line interface for SQLCipher
Control: affects -1 + src:sqlcipher Seem like a good idea to make sure this issue show up in the bug list for sqlcipher. -- Happy hacking Petter Reinholdtsen
Bug#1055765: chromium: Error: Can't open display (armhf) while other platforms (amd64, arm64, i386) are OK
Probably the easiest way is to manually download the chromium and chromium-common deb packages, and then 'sudo apt install /path/to/chromium_117.x.y.z-1~deb12u1_armhf.deb /path/to/chromium-common_117.x.y.z-1~deb12u1_armhf.deb'. If you go to https://snapshot.debian.org/package/chromium/117.0.5938.149-1~deb12u1/ in your browser, scroll down to the "chromium 117.0.5938.149-1~deb12u1" section, and then click on the link for "chromium_117.0.5938.149-1~deb12u1_armhf.deb" (or right click and click 'save link as', or copy the link and supply it to wget/curl in the qemu environment), it should download it. Do the same thing in the "chromium-common 117.0.5938.149-1~deb12u1" section. https://snapshot.debian.org/package/chromium/118.0.5993.70-1~deb12u1/ has more armhf deb packages, if the 117 packages aren't broken in your test. Unfortunately it looks like 118.0.5993.117-1 never successfully built for armhf on debian 12.. On Sun, Nov 12 2023 at 08:20:36 AM +01:00:00, Julien Neuhart wrote: Could you guide me on how ton install those versions? As far as I know, they are not available in bookworm directly. Thanks! Le 11 nov. 2023 à 21:51, Andres Salomon a écrit : Okay, so not distribution-specific. Between 116 and 119 there were a considerable number of changes in the debian packaging, including switching from clang-14 to clang-16 for build (done in 118.0.5993.117-1~deb12u1) and enabling NEON for armhf (done in 117.0.5938.132-1~deb12u1). My immediate suspicion is the NEON change, so it would helpful if you could try those versions as well and report back. Also, if it turns out to be the NEON change, having the output of `uname -a` and `cat /proc/cpuinfo` (inside of qemu's armhf emulation) would be helpful. On Sat, Nov 11 2023 at 12:08:42 PM +01:00:00, Julien Neuhart wrote: Hello Andres, Thanks for the quick follow up. So I’ve tested with Chromium 116.0.5845.180-1~deb12u1 and it works as expected on Debian 12. Note that I also had to explicitly install the chromium-common package: DEBIAN_FRONTEND=noninteractive apt-get install -y -qq --no-install-recommends chromium-common="116.0.5845.180-1~deb12u1" chromium="116.0.5845.180-1~deb12u1" Distributor ID:Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm Kernel: Linux buildkitsandbox 6.2.0-1015-azure #15~22.04.1-Ubuntu SMP Fri Oct 6 13:20:44 UTC 2023 armv7l GNU/Linux Architecture: armhf chromium —version: ind: '/root/.config/chromium/Crash Reports/pending/': No such file or directory Chromium 116.0.5845.180 built on Debian 12.1, running on Debian 12.2 Le 10 nov. 2023 à 22:01, Andres Salomon a écrit : Hi, Can you please try other versions if possible? 119.0.6045.123-1~deb12u1 is currently in bookworm-security. 116.0.5845.180-1~deb12u1 is still in bookworm. It would be helpful to know if this is a bookworm-specific regression, since it worked on bullseye's 116, or something broken in general with chromium 119. It looks like a version of 117 and 118 also successfully built for armhf, as other option to try: https://snapshot.debian.org/package/chromium/118.0.5993.70-1~deb12u1/ https://snapshot.debian.org/package/chromium/117.0.5938.149-1~deb12u1/ On Fri, Nov 10 2023 at 09:49:00 PM +01:00:00, Julien Neuhart wrote: Package: chromium Version: 119.0.6045.105-1~deb12u1 Dear maintainers, While building with QEMU a Docker image based on Debian bookworm using the chromium package, I found out that the « armhf » variant seems broken, which is not the case for others platforms. Indeed, after having installed chromium with: DEBIAN_FRONTEND=noninteractive apt-get install -y -qq --no-install-recommends chromium Running « chromium —version » failed on armhf (Error: Can't open display) while working as expected in others platform (amd64, arm64, i386). Please note it is working fine in Debian 11 & package version 116.0.5845.180. Full installation logs may be found here: https://github.com/gulien/chromium/actions/runs/6829257786 armhf: Distributor ID: Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm Kernel: Linux buildkitsandbox 6.2.0-1015-azure #15~22.04.1-Ubuntu SMP Fri Oct 6 13:20:44 UTC 2023 armv7l GNU/Linux Architecture: armhf chromium —version: Error: Can't open display: i386: Distributor ID: Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm Kernel: Linux buildkitsandbox 6.2.0-1015-azure #15~22.04.1-Ubuntu SMP Fri Oct 6 13:20:44 UTC 2023 x86_64 GNU/Linux Architecture: i386 chromium —version: find: '/root/.config/chromium/Crash Reports/pending/': No such file or directory Chromium 119.0.6045.123 built on Debian 12.2, running on Debian 12.2 arm64: Distributor ID: Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm Kernel: Linux buildkitsandbox 6.2.0-1015-azure #15~22.04.1-Ubuntu SMP Fri
Bug#1055826: bullseye-pu: package crun/0.17+dfsg-1+deb11u2 (bullseye regression)
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: c...@packages.debian.org, car...@debian.org
Control: affects -1 + src:crun
A change merged into Linux v6.6 broke crun. The change was backported in
the stable branch with v6.1.55, the version in bookworm. We fixed crun
last week crun 1.8.1-1+deb12u1 (unblock request: #1055241).
Salvatore Bonaccorso pointed out that the change was backported into all
the stable branches, including v5.10.197, the version now in bullseye.
bullseye's crun, v0.17, is also affected, therefore bullseye crun +
bullseye Linux (or bullseye crun+bullseye-backports Linux etc.) are now
broken as well.
This upload just backports the same two patches that we backported to
bookworm and that are needed to address this issue. The patches apply
with minimal changes. There are no other changes included in this
upload.
See the bookworm-pu unblock request, #1055241, and SUA 243-1, for more
context.
[ Tests ]
Lightly tested on a bullseye VM.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
Thanks,
Faidon
diff -Nru crun-0.17+dfsg/debian/changelog crun-0.17+dfsg/debian/changelog
--- crun-0.17+dfsg/debian/changelog 2023-02-11 23:44:44.0 +0200
+++ crun-0.17+dfsg/debian/changelog 2023-11-02 18:52:46.0 +0200
@@ -1,3 +1,12 @@
+crun (0.17+dfsg-1+deb11u2) bullseye; urgency=medium
+
+ * Backport two commits from upstream ("ignore ENOTSUP when chmod a
+symlink"), that restore containers with systemd as their init system, when
+running under Linux >= v6.6, >= v6.1.55 and >= 5.10.197, i.e. bullseye's
+and bookworm's current stable kernels. (Closes: #1053821)
+
+ -- Faidon Liambotis Thu, 02 Nov 2023 18:52:46 +0200
+
crun (0.17+dfsg-1+deb11u1) bullseye; urgency=medium
* Backport upstream commits b847d14 ("spec: do not set inheritable
diff -Nru crun-0.17+dfsg/debian/patches/series
crun-0.17+dfsg/debian/patches/series
--- crun-0.17+dfsg/debian/patches/series2023-02-11 23:44:44.0
+0200
+++ crun-0.17+dfsg/debian/patches/series2023-11-02 18:52:46.0
+0200
@@ -1,2 +1,4 @@
CVE-2022-27650-b847d14.patch
CVE-2022-27650-1aeeed2.patch
+utils-ignore-ENOTSUP-when-chmod-a-symlink.patch
+utils-fix-ignore-ENOTSUP-when-chmod-a-symlink.patch
diff -Nru
crun-0.17+dfsg/debian/patches/utils-fix-ignore-ENOTSUP-when-chmod-a-symlink.patch
crun-0.17+dfsg/debian/patches/utils-fix-ignore-ENOTSUP-when-chmod-a-symlink.patch
---
crun-0.17+dfsg/debian/patches/utils-fix-ignore-ENOTSUP-when-chmod-a-symlink.patch
1970-01-01 02:00:00.0 +0200
+++
crun-0.17+dfsg/debian/patches/utils-fix-ignore-ENOTSUP-when-chmod-a-symlink.patch
2023-11-02 18:52:46.0 +0200
@@ -0,0 +1,36 @@
+From 60296f112fddc74f4926f8ca6f6e1ef7a61ef5b9 Mon Sep 17 00:00:00 2001
+From: Giuseppe Scrivano
+Date: Tue, 26 Sep 2023 11:51:19 +0200
+Subject: [PATCH] utils: fix ignore ENOTSUP when chmod a symlink
+
+when ENOTSUP is encountered we must continue copying the other files,
+not doing an early return.
+
+commit 57262a2710c83fa08767f0ce3ba7a80993515bb2 introduced the
+regression with the Podman CI.
+
+Signed-off-by: Giuseppe Scrivano
+
+Origin: upstream,
https://github.com/containers/crun/commit/14afa8a46e2e83608a3a219402bce8ea8d071192
+Bug: https://github.com/containers/crun/issues/1308
+Bug-Debian: https://bugs.debian.org/1053821
+---
+ src/libcrun/utils.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/libcrun/utils.c b/src/libcrun/utils.c
+index 5c7f315..5306c5b 100644
+--- a/src/libcrun/utils.c
b/src/libcrun/utils.c
+@@ -1858,7 +1858,7 @@ copy_recursive_fd_to_fd (int srcdirfd, int dfd, const
char *srcname, const char
+ {
+ /* If the operation fails with ENOTSUP we are dealing with a
symlink, so ignore it. */
+ if (errno == ENOTSUP)
+-return 0;
++continue;
+
+ if (UNLIKELY (ret < 0))
+ return crun_make_error (err, errno, "chmod `%s/%s`", destname,
de->d_name);
+--
+2.39.2
+
diff -Nru
crun-0.17+dfsg/debian/patches/utils-ignore-ENOTSUP-when-chmod-a-symlink.patch
crun-0.17+dfsg/debian/patches/utils-ignore-ENOTSUP-when-chmod-a-symlink.patch
---
crun-0.17+dfsg/debian/patches/utils-ignore-ENOTSUP-when-chmod-a-symlink.patch
1970-01-01 02:00:00.0 +0200
+++
crun-0.17+dfsg/debian/patches/utils-ignore-ENOTSUP-when-chmod-a-symlink.patch
2023-11-02 18:52:46.0 +0200
@@ -0,0 +1,48 @@
+From 3bc67556e2f077337e574e4c3aaf18488410b2f5 Mon Sep 17 00:00:00 2001
+From: Giuseppe Scrivano
+Date: Fri, 22 Sep 2023 11:34:19 +0200
+Subject: [PATCH] utils: ignore ENOTSUP when chmod a symlink
+
+commit 5d1f903f75a80daa4dfb3d84e114ec8ecbf29956 in the kernel, present
+in a release since Linux 6.6
