Bug#1081552: cryptroot not run as the last in local-top
Control: tag -1 unreproducible moreinfo On Thu, 12 Sep 2024 at 20:12:17 +0200, Paweł Bogusławski wrote: > if one creates /etc/initramfs-tools/scripts/local-top/crypti, crypti > won't be called before cryptroot on boot. Works here, on bookworm as well as sid systems. Which files do you have in scripts/local-top/, and what is the content of scripts/local-top/ORDER? -- Guilhem. signature.asc Description: PGP signature
Bug#1076420: Processed: ITPs block move away from cdbs
On Tue, 10 Sep 2024 at 13:40:06 +0200, Alexandre Rossi wrote: >>> Bug #1076420 [src:uwsgi] uwsgi: move away from cdbs >>> […] >>> Added blocking bug(s) of 1076420: 1078557 >> >> Wrong bug number? #1078557 is for a leaf package and has nothing to do >> with uwsgi or CDBS. > > Sorry for that, fixing my mess. All good :-) -- Guilhem.
Bug#1076420: Processed: ITPs block move away from cdbs
Control: unblock 1076420 by 1078557 On Tue, 10 Sep 2024 at 11:33:07 +, Debian Bug Tracking System wrote: > Processing commands for cont...@bugs.debian.org: >> block 1076420 by 1078557 > Bug #1076420 [src:uwsgi] uwsgi: move away from cdbs > […] > Added blocking bug(s) of 1076420: 1078557 Wrong bug number? #1078557 is for a leaf package and has nothing to do with uwsgi or CDBS. -- Guilhem.
Bug#1080204: cryptsetup-initramfs: try to use passphrase for multiple device
Hi, On Sat, 31 Aug 2024 at 15:14:42 +, Johannes Berg wrote: > Since I have four devices with the same passphrase (they end > up building a btrfs array, so they're all needed), it'd be > nice to (try) using the passphrase for the first, so I don't > have to enter it four times. See /usr/share/doc/cryptsetup/README.keyctl which has been designed for such setup. -- Guilhem. signature.asc Description: PGP signature
Bug#1073052: fixed in cryptsetup 2:2.7.4-1
Hi Paul, On Sun, 25 Aug 2024 at 09:56:59 +0200, Paul Gevers wrote: > Well, if those are currently only run on amd64 and i386, it might be worth > indeed to stop marking them flaky and only run on amd64 (or mark them > skippable and only "exit 77" on i386 on failure, such that failure on amd64 > is still fatal). Ack, thanks for the hint! > However, at this moment they even fail on our KVM capable machine, in > qemu backend [1], as well as before the switch in the lxc backend [2]. Ah right sorry, should have warned about it before you triggered the jobs. For some reason login(1) stopped being transitively pulled inside the guests; this broke cryptroot-* tests and was fixed in https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/a4f182ac1ce8520c1efede6b6c3bda79a7d42b07 , but the fix hasn't been released yet. Cheers, -- Guilhem. signature.asc Description: PGP signature
Bug#1073052: fixed in cryptsetup 2:2.7.4-1
On Sat, 24 Aug 2024 at 21:25:03 +0200, Paul Gevers wrote: > On 24-08-2024 20:53, Guilhem Moulin wrote: >> Awesome, thanks! Right now these tests have “Architecture: amd64 i386”, >> is the runner able to run i386 too or should I remove it from the list? > > Tests with isolation-machine will only run on amd64, no need to special case > them further. If there are tests that you expect to only work on qemu that > are NOT yet tagged with isolation-machine should be marked as such. I think we misunderstood each other. We indeed have isolation-machine tests and it's great if they now can be run on debci infrastructure, but this bug is about the cryptroot-* series which can run on lxc or schroot. These tests themselves start qemu and bootstrap a guest to test unlocking at early boot stage. We chatted about it during DebConf21 and I believe it's not possible to rely on debci's own QEMU setup for such tests. AFAICT the issue with #-1 is that we can't control which runner we'll end up running on, and tests appear to be flaky on non-KVM capable runners. https://salsa.debian.org/ci-team/debci/-/issues/166 is not closed yet, so I guess cryptroot-* will have to remain flaky for now. But it's great if the isolation-machine tests can run on debci infrastructure :-) -- Guilhem. signature.asc Description: PGP signature
Bug#1073052: fixed in cryptsetup 2:2.7.4-1
On Sat, 24 Aug 2024 at 19:16:01 +0200, Paul Gevers wrote: > On 24-08-2024 19:10, Guilhem Moulin wrote: >> Great news that would be much appreciated, thanks! > > Done. > > I triggered a migration-reference/0 run in testing. Awesome, thanks! Right now these tests have “Architecture: amd64 i386”, is the runner able to run i386 too or should I remove it from the list? -- Guilhem. signature.asc Description: PGP signature
Bug#1073052: fixed in cryptsetup 2:2.7.4-1
Hi Paul, On Sat, 24 Aug 2024 at 17:50:22 +0200, Paul Gevers wrote: > On Sun, 04 Aug 2024 22:19:30 + Debian FTP Masters > wrote: >> * DEP-8: Mark cryptroot-* as flaky. To be re-evaluated if/when the >> tests only run on environment where KVM is available. (Closes: #1073052) > > On amd64 we have KVM available, but currently that needs actions from the > ci.d.n operators. I bet you want us to run cryptsetup on qemu on amd64. Great news that would be much appreciated, thanks! -- Guilhem. signature.asc Description: PGP signature
Bug#1079392: dropbear-initramfs: This is the same bug ar achived 1033802
Control: tag -1 moreinfo Hi, On Fri, 23 Aug 2024 at 13:22:01 +1200, jfp wrote: > I get the decrypt prompt on the console, I enter the passphrase then the boot > continues. You enter the passphrase a local console not from an SSH client right? Note that if you don't need remote unlocking you can simply uninstall dropbear-initramfs. > the boot then stops for a long time on /scripts/init-bottom. > then boot continues while displaying Was the network stack configured and did dropbear start before you entered the passphrase prompt? If not, then such behavior is expected as I explained in https://bugs.debian.org/1015810#10: | However if you don't have BOOT=nfs then initramfs-tools-core's | configure_networking() runs asynchronously starting from init-premount | stage and might not give up before the execution is handed over to the | normal system. dropbear-initramfs' init-bottom scripts only wait for | 60s by default but configure_networking() might take much longer (180s | timeout for the device, up to 10s waiting time for udev to settle, then | exponential backoff of 2+3+4+6+9+16+25+36+64+100=265s for the network | configuration). | | Since 2020.81-2 the init-bottom timeout is configurable with | DROPBEAR_SHUTDOWN_TIMEOUT and you can set it to a value that exceeds the | typical configure_networking() duration on your system to be sure that | there is leftover process passed init-bottom stage. See #964187. Does setting DROPBEAR_SHUTDOWN_TIMEOUT=300 (and rebuilding the initramfs image) help? -- Guilhem. signature.asc Description: PGP signature
Bug#1079068: cryptsetup: Waiting for encrypted source device
On Mon, 19 Aug 2024 at 22:40:32 -0400, briag...@disroot.org wrote: > I tried again on a new machine. I was able to reproduce the issue by > following the steps I outlined before. I then did a full reinstall - but > this time after switching to the sid repos and running full-upgrade I > installed systemd-cryptsetup before rebooting. This did not resolve the > issue. Can you share the relevant /etc/crypttab and /etc/fstab entries? Also what is the exact “waiting for encrypted source device” message? Does it show up at initramfs stage or later during the boot process? -- Guilhem. signature.asc Description: PGP signature
Bug#1079068: cryptsetup: Waiting for encrypted source device
On Mon, 19 Aug 2024 at 15:01:38 -0400, Brian Smith wrote: > I decided to do a fresh install to diagnose the issue. I grabbed the latest > mini.iso and did a fresh install with encryped LVM. I was able to boot with no > issues. I then updated my apt sources to point to sid instead of trixie and > ran > an update and full-upgrade. I then saw the "waiting for encryped source > device" > messages and was unable to boot again. Look like https://bugs.debian.org/1076208#10 , does installing systemd-cryptsetup fix the issue? -- Guilhem. signature.asc Description: PGP signature
Bug#1078775: Bug#1078777: roundcube-core: Empty groups in adressbook silently not exported
Hi,
On Thu, 15 Aug 2024 at 22:03:26 +, Einhard Leichtfuß wrote:
> when exporting an addressbook via the Roundcube web UI ("Export all"),
> any group without members is silently ignored.
Looks like this issue and the others 3 you just reported are upstream
issues, please report them at the upstream bug tracker
https://github.com/roundcube/roundcubemail/issues
--
Guilhem.
signature.asc
Description: PGP signature
Bug#1078760: autopkgtest-build-qemu produces unbootable images for old suites
Package: autopkgtest
Version: 5.39
Severity: normal
Tags: patch
Hi,
It appears that running autopkgtest-build-qemu on a sid system produces
unbootable images for bullseye LTS and older suites.
AFAICT that's because autopkgtest-build-qemu creates the guest's root
filestem using the host's mkfs.ext4(8), which by default enables the
‘orphan_file’ feature since e2fsprogs 1.47.0. That feature was added to
linux v5.15, so trying to use such an ext4 FS from an older kernel fails
with
/dev/vda1 has unsupported feature(s): FEATURE_C12
The attached trivial patch simply turns off ‘orphan_file’ when creating
the root file system for older target suites. Tested for jessie to
bullseye, but I suppose this could be useful for Ubuntu as well.
This is a no-op for bookworm or later targets.
Thanks for maintaining autopkgtest!
--
Guilhem.
--- a/autopkgtest-build-qemu
+++ b/autopkgtest-build-qemu
@@ -539,6 +539,8 @@
mkfs["options"] = "-O ^large_dir,^metadata_csum_seed"
if release in ('trusty', 'jessie'):
mkfs["options"] += ",^metadata_csum"
+if release in ('jessie', 'stretch', 'buster', 'bullseye'):
+mkfs["options"] += ",^orphan_file"
steps.append(mkfs)
steps.append(dict(mount='root'))
signature.asc
Description: PGP signature
Bug#1078557: pullimap: create directories that you require
> $ pullimap --debug SECTION > No such directory: /home/user/.local/share at > /usr/share/perl5/Net/IMAP/InterIMAP.pm line 102. > > If you need a certain directory and it does not exist... create it? Per the XDG Base Directory Specification $XDG_DATA_HOME/pullimap (or ~/.local/share/pullimap if XDG_DATA_HOME is unset) is created if it doesn't exist, but it's not obvious to me from the spec that it's pullimap's job to create $XDG_DATA_HOME. -- Guilhem. signature.asc Description: PGP signature
Bug#1078456: roundcube-core: Can't print, rescale or rotate image attachments
Package: roundcube-core Version: 1.6.8+dfsg-1 Severity: normal Tags: upstream pending Control: found -1 1.6.5+dfsg-1+deb12u3 Control: forwarded -1 https://github.com/roundcube/roundcubemail/issues/9571 The upstream fix for CVE-2024-42008 (from 1.6.8 and backported to 1.6.5+dfsg-1+deb12u3) sets a too restrictive Content-Security-Policy on the attachment preview page, which breaks printing and other handling of image attachments. -- Guilhem. signature.asc Description: PGP signature
Bug#1077969: roundcube: CVE-2024-42008, CVE-2024-42009, CVE-2024-42010: XSS and information leak vulnerabilities
Source: roundcube Version: 1.6.7+dfsg-1 Severity: important Found: -1 1.4.15+dfsg.1-1+deb11u3 Found: -1 1.6.5+dfsg-1+deb12u2 Tags: upstream security Roundcube webmail upstream has recently released 1.6.8 [0] which fixes the following vulnerabilities: * CVE-2024-42008: XSS vulnerability in serving of attachments other than HTML or SVG https://github.com/roundcube/roundcubemail/commit/89c8fe9ae9318c015807fbcbf7e39555fb30885d * CVE-2024-42009: XSS vulnerability in post-processing of sanitized HTML content https://github.com/roundcube/roundcubemail/commit/68af7c864a36e1941764238dac440ab0d99a8d26 * CVE-2024-42010: information leak (access to remote content) via insufficient CSS filtering https://github.com/roundcube/roundcubemail/commit/602d0f566eb39b6dcb739ad78323ec434a3b92ce -- Guilhem. [0] https://roundcube.net/news/2024/08/04/security-updates-1.6.8-and-1.5.8 signature.asc Description: PGP signature
Bug#1077652: bullseye-pu: package libvirt/7.0.0-3+deb11u3
Package: release.debian.org Severity: normal Tags: bullseye X-Debbugs-Cc: libv...@packages.debian.org Control: affects -1 + src:libvirt User: release.debian@packages.debian.org Usertags: pu [ Reason ] libvirt/7.0.0-3+deb11u2, currently in Bullseye, is vulnerable to several no-DSA security issues. These issues have been fixed for Buster LTS (DLA 3778-1), so this is a regression for users upgrading to Bullseye from Buster. [ Impact ] Users are vulnerable to (no-dsa) security issues. [ Tests ] AFAICT the code is architectured in several orthogonal components and drivers, and the DEP-8 smoke tests only cover some of them such as LXC or QEMU/KVM. The bulk of the proposed change touches the libxl driver (Xen) which is not covered by DEP-8 tests, so I tested that one more carefully, but also ran manual tests for KVM on a test hypervisor. [ Risks ] All patches are backported from upstream and applied cleanly (except for the libxl-related ones). [ 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 oldstable [x] the issue is verified as fixed in unstable [ Changes ] * Fix CVE-2021-3631: SELinux MCS may be accessed by another machine. * Fix CVE-2021-3667: Improper locking in the virStoragePoolLookupByTargetPath API. * Fix CVE-2021-3975: Use-after-free vulnerability. The qemuMonitorUnregister() function in qemuProcessHandleMonitorEOF is called using multiple threads without being adequately protected by a monitor lock. * Fix CVE-2021-4147: Deadlock and crash in libxl driver. * libxl: Fix regression in domain shutdown. * Fix CVE-2022-0897: Missing locking in nwfilterConnectNumOfNWFilters. * Fix CVE-2024-1441: Off-by-one error in the udevListInterfacesByStatus() function. * Fix CVE-2024-2494: Missing check for negative array lengths in RPC server de-serialization routines. * Fix CVE-2024-2496: NULL pointer dereference in the udevConnectListAllInterfaces() function. -- Guilhem. diffstat for libvirt-7.0.0 libvirt-7.0.0 changelog | 24 +++ patches/CVE-2021-3631.patch | 49 ++ patches/CVE-2021-3667.patch | 36 + patches/CVE-2021-3975.patch | 37 + patches/CVE-2021-4147_1.patch | 111 +++ patches/CVE-2021-4147_2.patch | 68 + patches/CVE-2021-4147_3.patch | 32 patches/CVE-2021-4147_4.patch | 145 patches/CVE-2021-4147_5.patch | 172 patches/CVE-2021-4147_6.patch | 90 patches/CVE-2022-0897.patch | 48 ++ patches/CVE-2024-1441.patch | 35 patches/CVE-2024-2494.patch | 212 ++ patches/CVE-2024-2496.patch | 86 patches/libxl-Fix-domain-shutdown.patch | 226 patches/series | 14 + 16 files changed, 1385 insertions(+) diff -Nru libvirt-7.0.0/debian/changelog libvirt-7.0.0/debian/changelog --- libvirt-7.0.0/debian/changelog 2023-02-06 17:50:14.0 +0100 +++ libvirt-7.0.0/debian/changelog 2024-07-30 21:35:28.0 +0200 @@ -1,3 +1,27 @@ +libvirt (7.0.0-3+deb11u3) bullseye; urgency=medium + + * Non-maintainer upload. + * Fix CVE-2021-3631: SELinux MCS may be accessed by another machine. +(Closes: #990709) + * Fix CVE-2021-3667: Improper locking in the +virStoragePoolLookupByTargetPath API. (Closes: #991594) + * Fix CVE-2021-3975: Use-after-free vulnerability. The +qemuMonitorUnregister() function in qemuProcessHandleMonitorEOF is called +using multiple threads without being adequately protected by a monitor +lock. + * Fix CVE-2021-4147: Deadlock and crash in libxl driver. (Closes: #1002535) + * libxl: Fix regression in domain shutdown. + * Fix CVE-2022-0897: Missing locking in nwfilterConnectNumOfNWFilters. +(Closes: #1009075) + * Fix CVE-2024-1441: Off-by-one error in the udevListInterfacesByStatus() +function. (Closes: #1066058) + * Fix CVE-2024-2494: Missing check for negative array lengths in RPC server +de-serialization routines. (Closes: #1067461) + * Fix CVE-2024-2496: NULL pointer dereference in the +udevConnectListAllInterfaces() function. + + -- Guilhem Moulin Tue, 30 Jul 2024 21:35:28 +0200 + libvirt (7.0.0-3+deb11u2) bullseye; urgency=medium * [461d540] Fix libxl config test failures. diff -Nru libvirt-7.0.0/debian/patches/CVE-2021-3631.patch libvirt-7.0.0/debian/patches/CVE-2021-3631.patch --- libvirt-7.0.0/debian/patches/CVE-2021-3631.patch1970-01-01 01:00:00.0 +0100 +++ libvirt-7.0.0/debian/patches/CVE-2021-3631.patch2024-07-30 21:35:28.0 +0200 @@ -0,0 +1,49 @@ +From: Daniel P. Berrangé +Date: Mon, 28 Jun 2021 13:09:04 +0100 +Subject: security
Bug#1076208: cryptsetup: Additional encrypted partition times out during startup
Hi, On Fri, 12 Jul 2024 at 15:05:03 +, Mark Brandis wrote: > the computer boots from an encrypted partition which works fine. During > startup an additional NVMe is mounted decrypted via crypttab and then > mounted to /data. > > This no longer works. I have to login as root and execute the following: Looks like your device was unlocked by systemd not src:cryptsetup. Do you have systemd-cryptsetup instead? The systemd maintainers have split cryptsetup integration into a separate binary package. -- Guilhem. signature.asc Description: PGP signature
Bug#1069768: The 'no-agent-forwarding' key restriction disables server alive message support
On Tue, 09 Jul 2024 at 14:20:59 +0200, Guilhem Moulin wrote: > On Sat, 29 Jun 2024 at 15:52:49 +0200, Lee Garrett wrote: >> Hi Guilhem, could you give quick feedback on this? I'm also happy to prepare >> a NMU for bookworm if you can't find the time for it. > > In my view this issue doesn't warrant an (o)s-pu upload on its own, but > the fix is trivial so I can do it anyway. Filed #1076015 for s-pu and #1076016 for os-pu. -- Guilhem. signature.asc Description: PGP signature
Bug#1076016: bullseye-pu: package dropbear/2020.81-3+deb11u2
Package: release.debian.org
Severity: normal
Tags: bullseye
X-Debbugs-Cc: dropb...@packages.debian.org
Control: affects -1 + src:dropbear
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
Keepalive packets are being ignored when the ‛-k’ flag (or
‛no-port-forwarding’ authorized_keys(5) restriction) is used.
AFAICT buster is affected as well, so this is not a regression in
bullseye.
[ Impact ]
dropbear-initramfs users unlocking the root file system remotely with
message keepalive enabled (ssh -oServerAliveInterval≠0) might lock
themselves out, see #1069768.
[ Tests ]
I did manually tests that dropbear-bin=2020.81-3+deb11u2 replies to
message keepalives even when remote TCP forwarding is disabled.
[ Risks ]
The patch is trivial and was cleanly cherry-picked from upstream.
With 2020.81-3+deb11u1, the workarounds to prevent being locked out
is to either disable message keepalives on the SSH client, or not to
disable remote TCP forwarding on the SSH server (dropbear).
[ 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 oldstable
[x] the issue is verified as fixed in unstable
[ Changes ]
Cherry-pick upstream patch to fix noremotetcp behavior. Keepalive
packets were being ignored when the ‛-k’ flag (or ‛no-port-forwarding’
authorized_keys(5) restriction) was used. (Closes: #1069768)
--
Guilhem.
diffstat for dropbear-2020.81 dropbear-2020.81
changelog |8 ++
patches/fix-noremotetcp-behavior.patch | 39 +
patches/series |1
3 files changed, 48 insertions(+)
diff -Nru dropbear-2020.81/debian/changelog dropbear-2020.81/debian/changelog
--- dropbear-2020.81/debian/changelog 2024-01-26 12:00:26.0 +0100
+++ dropbear-2020.81/debian/changelog 2024-07-09 15:51:42.0 +0200
@@ -1,3 +1,11 @@
+dropbear (2020.81-3+deb11u2) bullseye; urgency=medium
+
+ * Fix noremotetcp behavior. Keepalive packets were being ignored when the
+‛-k’ flag (or ‛no-port-forwarding’ authorized_keys(5) restriction) was
+used. (Closes: #1069768)
+
+ -- Guilhem Moulin Tue, 09 Jul 2024 15:51:42 +0200
+
dropbear (2020.81-3+deb11u1) bullseye; urgency=medium
* Fix CVE-2021-36369: Due to a non-RFC-compliant check of the available
diff -Nru dropbear-2020.81/debian/patches/fix-noremotetcp-behavior.patch
dropbear-2020.81/debian/patches/fix-noremotetcp-behavior.patch
--- dropbear-2020.81/debian/patches/fix-noremotetcp-behavior.patch
1970-01-01 01:00:00.0 +0100
+++ dropbear-2020.81/debian/patches/fix-noremotetcp-behavior.patch
2024-07-09 15:51:42.0 +0200
@@ -0,0 +1,39 @@
+From: Justin Chen
+Date: Fri, 8 Sep 2023 11:35:18 -0700
+Subject: src: svr-tcpfwd: Fix noremotetcp behavior
+
+If noremotetcp is set, we should still reply with
+send_msg_request_failed. This matches the behavior
+of !DROPBEAR_SVR_REMOTETCPFWD.
+
+We were seeing keepalive packets being ignored when
+the "-k" option was used.
+
+Origin:
https://github.com/mkj/dropbear/commit/3cf8344769eda55e26eee53c1898b2c66544f188
+Bug-Debian: https://bugs.debian.org/1069768
+---
+ svr-tcpfwd.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/svr-tcpfwd.c b/svr-tcpfwd.c
+index 9a2310d..b5e7855 100644
+--- a/svr-tcpfwd.c
b/svr-tcpfwd.c
+@@ -73,14 +73,14 @@ void recv_msg_global_request_remotetcp() {
+
+ TRACE(("enter recv_msg_global_request_remotetcp"))
+
++ reqname = buf_getstring(ses.payload, &namelen);
++ wantreply = buf_getbool(ses.payload);
++
+ if (svr_opts.noremotetcp || !svr_pubkey_allows_tcpfwd()) {
+ TRACE(("leave recv_msg_global_request_remotetcp: remote tcp
forwarding disabled"))
+ goto out;
+ }
+
+- reqname = buf_getstring(ses.payload, &namelen);
+- wantreply = buf_getbool(ses.payload);
+-
+ if (namelen > MAX_NAME_LEN) {
+ TRACE(("name len is wrong: %d", namelen))
+ goto out;
diff -Nru dropbear-2020.81/debian/patches/series
dropbear-2020.81/debian/patches/series
--- dropbear-2020.81/debian/patches/series 2024-01-26 12:00:26.0
+0100
+++ dropbear-2020.81/debian/patches/series 2024-07-09 15:51:42.0
+0200
@@ -1,3 +1,4 @@
local-options.patch
CVE-2021-36369.patch
CVE-2023-48795.patch
+fix-noremotetcp-behavior.patch
signature.asc
Description: PGP signature
Bug#1076015: bookworm-pu: package dropbear/2022.83-1+deb12u2
Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: dropb...@packages.debian.org
Control: affects -1 + src:dropbear
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
Keepalive packets are being ignored when the ‛-k’ flag (or
‛no-port-forwarding’ authorized_keys(5) restriction) is used.
Bullseye is affected as well, so this is not a regression in bookworm.
[ Impact ]
dropbear-initramfs users unlocking the root file system remotely with
message keepalive enabled (ssh -oServerAliveInterval≠0) might lock
themselves out, see #1069768.
[ Tests ]
I did manually tests that dropbear-bin=2022.83-1+deb12u2 replies to
message keepalives even when remote TCP forwarding is disabled.
[ Risks ]
The patch is trivial and was cleanly cherry-picked from upstream.
Without 2022.83-1+deb12u1, the workarounds to prevent being locked out
is to either disable message keepalives on the SSH client, or not to
disable remote TCP forwarding on the SSH server (dropbear).
[ 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 stable
[x] the issue is verified as fixed in unstable
[ Changes ]
Cherry-pick upstream patch to fix noremotetcp behavior. Keepalive
packets were being ignored when the ‛-k’ flag (or ‛no-port-forwarding’
authorized_keys(5) restriction) was used. (Closes: #1069768)
--
Guilhem.
diffstat for dropbear-2022.83 dropbear-2022.83
changelog |8 ++
patches/fix-noremotetcp-behavior.patch | 39 +
patches/series |1
3 files changed, 48 insertions(+)
diff -Nru dropbear-2022.83/debian/changelog dropbear-2022.83/debian/changelog
--- dropbear-2022.83/debian/changelog 2024-01-26 10:01:00.0 +0100
+++ dropbear-2022.83/debian/changelog 2024-07-09 14:22:02.0 +0200
@@ -1,3 +1,11 @@
+dropbear (2022.83-1+deb12u2) bookworm; urgency=medium
+
+ * Fix noremotetcp behavior. Keepalive packets were being ignored when the
+‛-k’ flag (or ‛no-port-forwarding’ authorized_keys(5) restriction) was
+used. (Closes: #1069768)
+
+ -- Guilhem Moulin Tue, 09 Jul 2024 14:22:02 +0200
+
dropbear (2022.83-1+deb12u1) bookworm; urgency=medium
* Fix CVE-2023-48795: (terrapin attack): The SSH transport protocol with
diff -Nru dropbear-2022.83/debian/patches/fix-noremotetcp-behavior.patch
dropbear-2022.83/debian/patches/fix-noremotetcp-behavior.patch
--- dropbear-2022.83/debian/patches/fix-noremotetcp-behavior.patch
1970-01-01 01:00:00.0 +0100
+++ dropbear-2022.83/debian/patches/fix-noremotetcp-behavior.patch
2024-07-09 14:22:02.0 +0200
@@ -0,0 +1,39 @@
+From: Justin Chen
+Date: Fri, 8 Sep 2023 11:35:18 -0700
+Subject: src: svr-tcpfwd: Fix noremotetcp behavior
+
+If noremotetcp is set, we should still reply with
+send_msg_request_failed. This matches the behavior
+of !DROPBEAR_SVR_REMOTETCPFWD.
+
+We were seeing keepalive packets being ignored when
+the "-k" option was used.
+
+Origin:
https://github.com/mkj/dropbear/commit/3cf8344769eda55e26eee53c1898b2c66544f188
+Bug-Debian: https://bugs.debian.org/1069768
+---
+ svr-tcpfwd.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/svr-tcpfwd.c b/svr-tcpfwd.c
+index 7967cfa..01a76a2 100644
+--- a/svr-tcpfwd.c
b/svr-tcpfwd.c
+@@ -79,14 +79,14 @@ void recv_msg_global_request_remotetcp() {
+
+ TRACE(("enter recv_msg_global_request_remotetcp"))
+
++ reqname = buf_getstring(ses.payload, &namelen);
++ wantreply = buf_getbool(ses.payload);
++
+ if (svr_opts.noremotetcp || !svr_pubkey_allows_tcpfwd()) {
+ TRACE(("leave recv_msg_global_request_remotetcp: remote tcp
forwarding disabled"))
+ goto out;
+ }
+
+- reqname = buf_getstring(ses.payload, &namelen);
+- wantreply = buf_getbool(ses.payload);
+-
+ if (namelen > MAX_NAME_LEN) {
+ TRACE(("name len is wrong: %d", namelen))
+ goto out;
diff -Nru dropbear-2022.83/debian/patches/series
dropbear-2022.83/debian/patches/series
--- dropbear-2022.83/debian/patches/series 2024-01-26 10:01:00.0
+0100
+++ dropbear-2022.83/debian/patches/series 2024-07-09 14:22:02.0
+0200
@@ -2,3 +2,4 @@
support-running-test_aslr-without-venv.patch
raise-connection-delay-in-tests.patch
CVE-2023-48795.patch
+fix-noremotetcp-behavior.patch
signature.asc
Description: PGP signature
Bug#1069768: The 'no-agent-forwarding' key restriction disables server alive message support
On Sat, 29 Jun 2024 at 15:52:49 +0200, Lee Garrett wrote: > Hi Guilhem, could you give quick feedback on this? I'm also happy to prepare > a NMU for bookworm if you can't find the time for it. In my view this issue doesn't warrant an (o)s-pu upload on its own, but the fix is trivial so I can do it anyway. -- Guilhem. signature.asc Description: PGP signature
Bug#1072847: fixed in lacme 0.8.3-1
Hi Sakari, On Fri, 05 Jul 2024 at 08:23:56 +, Sakari Ailus wrote: > The removal of the intermediate certificates (or not including the current > ones) however is an issue as the server using the issued certificate still > needs to provide them to the clients. The path pointed to by ‛certificate-chain’ contains the entire chain (excluding the root) as provided by Let's Encrypt. > While it's certainly possible for the lacme user to obtain these > certificates directly from Let's encrypt, it'd be quite convenient to > continue to provide them in the lacme package itself, even if the package > does need to be updated from time to time for that reason. Do you have a concrete usecase? It appears Let's Encrypt has settled on intermediates with <2y lifetime (i.e., shorter than Debian Stable's lifetime), and earlier rotation is at their own discretion, so I don't see how we can reliably provide them as part of the source package. (Updating via (o)s-pu might be an option, but that would only work if the rotation is announced early enough ahead of the point release freeze.) Cheers, -- Guilhem. signature.asc Description: PGP signature
Bug#1073175: bookworm-pu: package lacme/0.8.2-1+deb12u1
Package: release.debian.org Severity: normal Tags: bookworm X-Debbugs-Cc: la...@packages.debian.org Control: affects -1 + src:lacme User: release.debian@packages.debian.org Usertags: pu [ Reason ] Let's Encrypt has recently rotated its intermediate certificates [0]. The previously used intermediate certificates were used as trust anchors for validation of the issued X.509 certificate before its deployment. The intermediate rotation means the validation step currently fails with the default configuration. [ Impact ] Post-issuance validation failure (and therefore unusable package) in the default configuration, see #1072847. [ Tests ] lacme has a comprehensive test suite. It does not run at build time nor via debci as it requires an open 80/tcp and test hostnames pointing to it (to reply to ACME challenges), but I succesfully ran in manually. Moreover the package is already used in production where it indeed solves the post-issuance validation failure. [ Risks ] A quick fix would be to simply replace the old intermediates in the certificate bundle, but that would cease to work again next time Let's Encrypt rotate their intermediates. In fact the new intermediates expire sooner than the old ones (2 years from now, but of course the rotation is likely not to happen at the last minute). This appears to be deliberate in order to discourage pining them [0]. The validation logic has therefore changed to use arbitrary intermediate(s) provided during the issuance step as -untrusted (for chain building). Only the root certificates are used as trust anchor. The patch is rather trival: diff -Nru -w lacme-0.8.2/lacme lacme-0.8.2/lacme --- lacme-0.8.2/lacme 2023-04-25 20:06:22.0 +0200 +++ lacme-0.8.2/lacme 2024-06-14 01:24:36.0 +0200 @@ -822,21 +822,31 @@ The (patch-applied) debdiff is longer as it includes changes to the test suite made to accomodate Let's Encrypt current staging environment. These changes could be omitted from debian/patches since the test suite doesn't run, but I think there is some value in having working manual tests out of the box. [ 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 stable [x] the issue is verified as fixed in unstable [ Changes ] * Backport upstream patch to fix post-issuance validation logic. Avoid pining the intermediate certificates in the bundle and instead validate the leaf certificate with intermediate(s) supplied during issuance as untrusted (used for chain building only). Only the root certificates are used as trust anchor. Not pining intermediate certificates is in line with Let's Encrypt's latest recommendations. Closes: #1072847 * Adjust test suite against current Let's Encrypt staging environment. * d/gbp.conf: Set 'debian-branch = debian/bookworm'. -- Guilhem. [0] https://letsencrypt.org/2024/03/19/new-intermediate-certificates diffstat for lacme-0.8.2 lacme-0.8.2 Makefile|8 --- debian/changelog| 14 ++ debian/gbp.conf |2 debian/patches/series |2 lacme | 26 ++-- tests/account-encrypted-gpg |2 tests/account-encrypted-openssl |1 tests/cert-install | 84 +--- tests/cert-verify | 22 ++ tests/old-lacme |9 ++-- 10 files changed, 106 insertions(+), 64 deletions(-) diff -Nru lacme-0.8.2/debian/changelog lacme-0.8.2/debian/changelog --- lacme-0.8.2/debian/changelog2023-04-25 20:08:21.0 +0200 +++ lacme-0.8.2/debian/changelog2024-06-14 01:20:13.0 +0200 @@ -1,3 +1,17 @@ +lacme (0.8.2-1+deb12u1) bookworm; urgency=medium + + * Backport upstream patches to fix post-issuance validation logic. +We avoid pining the intermediate certificates in the bundle and instead +validate the leaf certificate with intermediates supplied during issuance +as untrusted (used for chain building only). Only the root certificates +are used as trust anchor. Not pining intermediate certificates is in line +with Let's Encrypt's latest recommendations. +Closes: #1072847 + * Adjust test suite against current Let's Encrypt staging environment. + * d/gbp.conf: Set 'debian-branch = debian/bookworm'. + + -- Guilhem Moulin Fri, 14 Jun 2024 01:20:13 +0200 + lacme (0.8.2-1) unstable; urgency=medium * New upstream bugfix release. diff -Nru lacme-0.8.2/debian/gbp.conf lacme-0.8.2/debian/gbp.conf --- lacme-0.8.2/debian/gbp.conf 2023-04-25 20:08:21.0 +0200 +++ lacme-0.8.2/debian/gbp.conf 2024-06-14 01:20:13.0 +0200 @@ -1,6 +1,6 @@ [DEFAULT] upstream-branch = upstream -debian-branch = debian/latest +debian-bran
Bug#1073174: bullseye-pu: package lacme/0.8.0-2+deb11u2
Package: release.debian.org Severity: normal Tags: bullseye X-Debbugs-Cc: la...@packages.debian.org Control: affects -1 + src:lacme User: release.debian@packages.debian.org Usertags: pu [ Reason ] Let's Encrypt has recently rotated its intermediate certificates [0]. The previously used intermediate certificates were used as trust anchors for validation of the issued X.509 certificate before its deployment. The intermediate rotation means the validation step currently fails with the default configuration. [ Impact ] Post-issuance validation failure (and therefore unusable package) in the default configuration, see #1072847. [ Tests ] lacme has a comprehensive test suite. It does not run at build time nor via debci as it requires an open 80/tcp and test hostnames pointing to it (to reply to ACME challenges), but I succesfully ran in manually. Moreover the package is already used in production where it indeed solves the post-issuance validation failure. [ Risks ] A quick fix would be to simply replace the old intermediates in the certificate bundle, but that would cease to work again next time Let's Encrypt rotate their intermediates. In fact the new intermediates expire sooner than the old ones (2 years from now, but of course the rotation is likely not to happen at the last minute). This appears to be deliberate in order to discourage pining them [0]. The validation logic has therefore changed to use arbitrary intermediate(s) provided during the issuance step as -untrusted (for chain building). Only the root certificates are used as trust anchor. The patch is rather trival: diff -Nru lacme-0.8.0/lacme lacme-0.8.0/lacme --- lacme-0.8.0/lacme 2021-02-22 03:19:57.0 +0100 +++ lacme-0.8.0/lacme 2024-06-13 19:23:31.0 +0200 @@ -826,9 +826,14 @@ The (patch-applied) debdiff is longer as it includes changes to the test suite made to accomodate Let's Encrypt current staging environment. These changes could be omitted from debian/patches since the test suite doesn't run, but I think there is some value in having working manual tests out of the box. [ 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 oldstable [x] the issue is verified as fixed in unstable [ Changes ] * Backport upstream patch to fix post-issuance validation logic. Avoid pining the intermediate certificates in the bundle and instead validate the leaf certificate with intermediate(s) supplied during issuance as untrusted (used for chain building only). Only the root certificates are used as trust anchor. Not pining intermediate certificates is in line with Let's Encrypt's latest recommendations. Closes: #1072847 * Adjust test suite against current Let's Encrypt staging environment. -- Guilhem. [0] https://letsencrypt.org/2024/03/19/new-intermediate-certificates diffstat for lacme-0.8.0 lacme-0.8.0 Makefile|8 +--- debian/changelog| 13 +++ debian/patches/series |2 + lacme |7 +++- tests/account-encrypted-gpg |2 - tests/account-encrypted-openssl |1 tests/accountd |1 tests/accountd-kid |4 +- tests/cert-install | 69 +++- tests/cert-revoke |4 +- tests/cert-verify | 20 ++- tests/old-accountd |1 tests/old-lacme |1 13 files changed, 91 insertions(+), 42 deletions(-) diff -Nru lacme-0.8.0/debian/changelog lacme-0.8.0/debian/changelog --- lacme-0.8.0/debian/changelog2023-04-28 10:25:54.0 +0200 +++ lacme-0.8.0/debian/changelog2024-06-13 19:19:07.0 +0200 @@ -1,3 +1,16 @@ +lacme (0.8.0-2+deb11u2) bullseye; urgency=medium + + * Backport upstream patches to fix fix post-issuance validation logic. +We avoid pining the intermediate certificates in the bundle and instead +validate the leaf certificate with intermediates supplied during issuance +as untrusted (used for chain building only). Only the root certificates +are used as trust anchor. Not pining intermediate certificates is in line +with Let's Encrypt's latest recommendations. +Closes: #1072847 + * Adjust test suite against current Let's Encrypt staging environment. + + -- Guilhem Moulin Thu, 13 Jun 2024 19:19:07 +0200 + lacme (0.8.0-2+deb11u1) bullseye; urgency=medium * client: Handle "ready" → "processing" → "valid" status change during diff -Nru lacme-0.8.0/debian/patches/series lacme-0.8.0/debian/patches/series --- lacme-0.8.0/debian/patches/series 2023-04-28 10:25:54.0 +0200 +++ lacme-0.8.0/debian/patches/series 2024-06-13 19:19:07.0 +0200 @@
Bug#1073116: bookworm-pu: package python-idna/3.3-1+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: python-i...@packages.debian.org
Control: affects -1 + src:python-idna
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
Fix CVE-2024-3651: Specially crafted inputs to idna.encode() can consume
significant resources, which may lead to denial of service.
The Security Team argued the vulnerability doesn't warrant a DSA.
[ Impact ]
The vulnerability was fixed in Buster LTS, and users upgrading to
≥Bullseye will regress if it isn't fixed to all recent suites.
[ Tests ]
A PoC can be found at https://bugzilla.redhat.com/show_bug.cgi?id=2274779 .
I successfully ran it locally, but didn't turn it into a DEP-8 or build
time test as it's unclear what the right time threshold would be on o
the buildds. The upstream test suite still runs fine before and after
the change.
[ Risks ]
The debdiff is long because it includes the diff for generated idna/idnadata.py
(`tools/idna-data --dir idna --no-cache --version 14.0.0 make-libdata`),
but beyond that the change is trival and matches the upstream fix.
[ 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 oldstable
[x] the issue is verified as fixed in unstable
[ Changes ]
Fix CVE-2024-3651: Specially crafted inputs to idna.encode() can consume
significant resources, which may lead to denial of service.
(Closes: #1069127)
--
Guilhem.
diffstat for python-idna-3.3 python-idna-3.3
changelog |9
patches/CVE-2024-3651.patch | 2479
patches/series |1
salsa-ci.yml|8
4 files changed, 2497 insertions(+)
diff -Nru python-idna-3.3/debian/changelog python-idna-3.3/debian/changelog
--- python-idna-3.3/debian/changelog2022-02-16 12:45:05.0 +0100
+++ python-idna-3.3/debian/changelog2024-05-30 14:31:22.0 +0200
@@ -1,3 +1,12 @@
+python-idna (3.3-1+deb12u1) bookworm; urgency=high
+
+ * Non-maintainer upload.
+ * Fix CVE-2024-3651: Specially crafted inputs to idna.encode() can consume
+significant resources, which may lead to denial of service.
+(Closes: #1069127)
+
+ -- Guilhem Moulin Thu, 30 May 2024 14:31:22 +0200
+
python-idna (3.3-1) unstable; urgency=medium
* New upstream release.
diff -Nru python-idna-3.3/debian/patches/CVE-2024-3651.patch
python-idna-3.3/debian/patches/CVE-2024-3651.patch
--- python-idna-3.3/debian/patches/CVE-2024-3651.patch 1970-01-01
01:00:00.0 +0100
+++ python-idna-3.3/debian/patches/CVE-2024-3651.patch 2024-05-30
14:31:22.0 +0200
@@ -0,0 +1,2479 @@
+From: Kim Davies
+Date: Mon, 1 Apr 2024 20:24:57 -0700
+Subject: More efficient resolution of joiner contexts
+
+In some pathological cases, this would out eligibility under
+CONTEXTJ rules much faster.
+
+Generated idna/idnadata.py (and idna/uts46data.py) files were updated
+with `tools/idna-data --dir idna --no-cache --version 14.0.0 make-libdata`.
+
+Origin:
https://github.com/kjd/idna/commit/5beb28b9dd77912c0dd656d8b0fdba3eb80222e7
+Bug: https://github.com/kjd/idna/security/advisories/GHSA-jjg7-2v4v-x38h
+Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2274779
+Bug-Debian: https://security-tracker.debian.org/tracker/CVE-2024-3651
+Bug-Debian: https://bugs.debian.org/1069127
+---
+ idna/core.py | 16 +-
+ idna/idnadata.py | 2162 --
+ tools/idna-data | 13 +-
+ 3 files changed, 2124 insertions(+), 67 deletions(-)
+
+diff --git a/idna/core.py b/idna/core.py
+index 55ab967..c6aa30a 100644
+--- a/idna/core.py
b/idna/core.py
+@@ -150,9 +150,11 @@ def valid_contextj(label: str, pos: int) -> bool:
+ joining_type = idnadata.joining_types.get(ord(label[i]))
+ if joining_type == ord('T'):
+ continue
+-if joining_type in [ord('L'), ord('D')]:
++elif joining_type in [ord('L'), ord('D')]:
+ ok = True
+ break
++else:
++break
+
+ if not ok:
+ return False
+@@ -162,9 +164,11 @@ def valid_contextj(label: str, pos: int) -> bool:
+ joining_type = idnadata.joining_types.get(ord(label[i]))
+ if joining_type == ord('T'):
+ continue
+-if joining_type in [ord('R'), ord('D')]:
++elif joining_type in [ord('R'), ord('D')]:
+ ok = True
+ break
++else:
++break
+ return ok
+
+ if cp_value == 0x200d:
+@@ -236,12 +240,8 @@ def check_label(label: Union[str, bytes, bytearray]) ->
None:
+ if intranges_contain(cp_value, idnadata.codepoint_classes['PVALID']):
+
Bug#1073115: bullseye-pu: package python-idna/2.10-1+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
X-Debbugs-Cc: python-i...@packages.debian.org
Control: affects -1 + src:python-idna
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
Fix CVE-2024-3651: Specially crafted inputs to idna.encode() can consume
significant resources, which may lead to denial of service.
The Security Team argued the vulnerability doesn't warrant a DSA.
[ Impact ]
The vulnerability was fixed in Buster LTS, and users upgrading to
≥Bullseye will regress if it isn't fixed to all recent suites.
[ Tests ]
A PoC can be found at https://bugzilla.redhat.com/show_bug.cgi?id=2274779 .
I successfully ran it locally, but didn't turn it into a DEP-8 or build
time test as it's unclear what the right time threshold would be on o
the buildds. The upstream test suite still runs fine before and after
the change.
[ Risks ]
The debdiff is long because it includes the diff for generated idna/idnadata.py
(`tools/idna-data --dir idna --no-cache --version 13.0.0 make-libdata`),
but beyond that the change is trival and matches the upstream fix.
[ 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 oldstable
[x] the issue is verified as fixed in unstable
[ Changes ]
Fix CVE-2024-3651: Specially crafted inputs to idna.encode() can consume
significant resources, which may lead to denial of service.
(Closes: #1069127)
--
Guilhem.
diffstat for python-idna-2.10 python-idna-2.10
changelog |9
patches/CVE-2024-3651.patch | 2314
patches/series |1
salsa-ci.yml|8
4 files changed, 2332 insertions(+)
diff -Nru python-idna-2.10/debian/changelog python-idna-2.10/debian/changelog
--- python-idna-2.10/debian/changelog 2020-07-10 20:19:14.0 +0200
+++ python-idna-2.10/debian/changelog 2024-05-30 13:49:43.0 +0200
@@ -1,3 +1,12 @@
+python-idna (2.10-1+deb11u1) bullseye; urgency=high
+
+ * Non-maintainer upload.
+ * Fix CVE-2024-3651: Specially crafted inputs to idna.encode() can consume
+significant resources, which may lead to denial of service.
+(Closes: #1069127)
+
+ -- Guilhem Moulin Thu, 30 May 2024 13:49:43 +0200
+
python-idna (2.10-1) unstable; urgency=medium
* Team upload.
diff -Nru python-idna-2.10/debian/patches/CVE-2024-3651.patch
python-idna-2.10/debian/patches/CVE-2024-3651.patch
--- python-idna-2.10/debian/patches/CVE-2024-3651.patch 1970-01-01
01:00:00.0 +0100
+++ python-idna-2.10/debian/patches/CVE-2024-3651.patch 2024-05-30
13:49:43.0 +0200
@@ -0,0 +1,2314 @@
+From: Kim Davies
+Date: Mon, 1 Apr 2024 20:24:57 -0700
+Subject: More efficient resolution of joiner contexts
+
+In some pathological cases, this would out eligibility under
+CONTEXTJ rules much faster.
+
+Generated idna/idnadata.py (and idna/uts46data.py) files were updated
+with `tools/idna-data --dir idna --no-cache --version 13.0.0 make-libdata`.
+
+Origin:
https://github.com/kjd/idna/commit/5beb28b9dd77912c0dd656d8b0fdba3eb80222e7
+Bug: https://github.com/kjd/idna/security/advisories/GHSA-jjg7-2v4v-x38h
+Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2274779
+Bug-Debian: https://security-tracker.debian.org/tracker/CVE-2024-3651
+Bug-Debian: https://bugs.debian.org/1069127
+---
+ idna/core.py |8 +-
+ idna/idnadata.py | 2042 --
+ tools/idna-data | 13 +-
+ 3 files changed, 2010 insertions(+), 53 deletions(-)
+
+diff --git a/idna/core.py b/idna/core.py
+index 41ec5c7..cd4a446 100644
+--- a/idna/core.py
b/idna/core.py
+@@ -161,9 +161,11 @@ def valid_contextj(label, pos):
+ joining_type = idnadata.joining_types.get(ord(label[i]))
+ if joining_type == ord('T'):
+ continue
+-if joining_type in [ord('L'), ord('D')]:
++elif joining_type in [ord('L'), ord('D')]:
+ ok = True
+ break
++else:
++break
+
+ if not ok:
+ return False
+@@ -173,9 +175,11 @@ def valid_contextj(label, pos):
+ joining_type = idnadata.joining_types.get(ord(label[i]))
+ if joining_type == ord('T'):
+ continue
+-if joining_type in [ord('R'), ord('D')]:
++elif joining_type in [ord('R'), ord('D')]:
+ ok = True
+ break
++else:
++break
+ return ok
+
+ if cp_value == 0x200d:
+diff --git a/idna/idnadata.py b/idna/idnadata.py
+index a284e4c..ae48ba6 100644
+--- a/idna/idnadata.py
b/idna/idnadata.py
+@@ -92,16 +92,190 @@ scripts = {
+ ),
+ }
+ joining_types = {
+-0x600: 85,
+-0x601: 85,
+-0x6
Bug#1072847: lacme: Post-issuance validation fails in the default configuration
Package: lacme Version: 0.8.2-1 Severity: grave Justification: renders package unusable Let's Encrypt has recently rotated its intermediate certificates [0]. The previous intermediate certificates (lets-encrypt-r[34].pem and lets-encrypt-e[12].pem) are concatenated along side the roots (isrgrootx1.pem and isrg-root-x2.pem) and used as trust anchors for validation of the issued X.509 certificate before its deployment. The new intermediates means the validation step now fails. A quick fix is to add R1[0-4].pem and E[5-9].pem to the certificate bundle, however that will cease to work once Let's Encrypt rotates its intermediates again. A proper fix would be to use the intermediate(s) provided during the issuance step as -untrusted (for chain building). -- Guilhem. [0] https://letsencrypt.org/2024/03/19/new-intermediate-certificates signature.asc Description: PGP signature
Bug#1072058: [pkg-cryptsetup-devel] Bug#1072058: Bug#1017542: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE
On Mon, 03 Jun 2024 at 00:14:39 +0100, Luca Boccassi wrote: > On Mon, 3 Jun 2024 at 00:09, Guilhem Moulin wrote: >> On Sun, 02 Jun 2024 at 23:35:57 +0100, Luca Boccassi wrote: >>> I gather the initramfs scripts are not calling a deferred close after >>> mounting the rootfs in the initrd. If you add that, the device should >>> be automatically cleaned up when the root filesystem is umounted. >> >> initramfs-tools doesn't take the system back on shutdown, so there is >> nothing src:cryptsetup can do here. > > The deferred close is given on the initrd though, immediately after > mounting, which I think is done by the cryptsetup initramfs hook? > Deferred close means that it will be closed by the kernel once the > last mount is gone. So if you call that from the initramfs hook, > things should work out automatically on shutdown. I see, thanks for the explanation. The cryptsetup initramfs scripts are currently only involved at pre-mount stage and do not try to mount anything, but we could add another one at post-mount stage for this. -- Guilhem. signature.asc Description: PGP signature
Bug#1072058: [pkg-cryptsetup-devel] Bug#1072058: Bug#1017542: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE
On Sun, 02 Jun 2024 at 23:35:57 +0100, Luca Boccassi wrote: > Yes, the purpose of the option is to leave that device alone, as it > cannot be closed from the host os, as programs will be running from > it. It doesn't leave the device alone though as it still tries to detach it. > I gather the initramfs scripts are not calling a deferred close after > mounting the rootfs in the initrd. If you add that, the device should > be automatically cleaned up when the root filesystem is umounted. initramfs-tools doesn't take the system back on shutdown, so there is nothing src:cryptsetup can do here. -- Guilhem. signature.asc Description: PGP signature
Bug#1072058: [pkg-cryptsetup-devel] Bug#1072058: Bug#1017542: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE
Control: tag -1 = pending Hi, On Mon, 27 May 2024 at 23:32:13 +0100, Luca Boccassi wrote: > Please consider applying the same change in the initramfs-tools > cryptsetup scripts, so that x-initrd.attach is recognized (and no > warning is printed), and so that it is added if missing. Thanks. While testing this it seems adding x-initrd.attach to vda5_crypt causes systemd not to try to stop systemd-cryptsetup@vda5_crypt.service on shutdown, on this system it still tries and fail to remove the DM device holding the root file system (vda5_crypt): 73s [6.834893] systemd-shutdown[1]: Syncing filesystems and block devices. 73s [6.837554] systemd-shutdown[1]: Sending SIGTERM to remaining processes... 73s [6.845806] systemd-journald[354]: Received SIGTERM from PID 1 (systemd-shutdow). 73s [6.884585] systemd-shutdown[1]: Sending SIGKILL to remaining processes... 73s [6.889688] systemd-shutdown[1]: Unmounting file systems. 73s [6.890874] (sd-umount)[737]: Unmounting '/run/credentials/systemd-cryptsetup@vda5_crypt.service'. 73s [6.893159] (sd-umount)[738]: Unmounting '/run/credentials/systemd-journald.service'. 73s [6.894974] (sd-remount)[739]: Remounting '/' read-only with options 'errors=remount-ro'. 73s [6.925739] EXT4-fs (dm-0): re-mounted 8effcc46-252e-4197-8f24-79f91fc7d8ad ro. Quota mode: none. 73s [6.927993] systemd-shutdown[1]: All filesystems unmounted. 73s [6.928747] systemd-shutdown[1]: Deactivating swaps. 73s [6.929334] systemd-shutdown[1]: All swaps deactivated. 73s [6.929880] systemd-shutdown[1]: Detaching loop devices. 73s [6.933262] systemd-shutdown[1]: All loop devices detached. 73s [6.934343] systemd-shutdown[1]: Stopping MD devices. 73s [6.935470] systemd-shutdown[1]: All MD devices stopped. 73s [6.936602] systemd-shutdown[1]: Detaching DM devices. 73s [6.938329] systemd-shutdown[1]: Not all DM devices detached, 1 left. 73s [6.939932] systemd-shutdown[1]: Detaching DM devices. 73s [6.941675] systemd-shutdown[1]: Not all DM devices detached, 1 left. 73s [6.943213] systemd-shutdown[1]: Detaching DM devices. 73s [6.944951] systemd-shutdown[1]: Not all DM devices detached, 1 left. 73s [6.946351] systemd-shutdown[1]: Cannot finalize remaining DM devices, continuing. 73s [6.948555] systemd-shutdown[1]: Unable to finalize remaining DM devices, ignoring. 73s [6.950748] systemd-shutdown[1]: Syncing filesystems and block devices. 73s [6.952441] systemd-shutdown[1]: Powering off. Is that expected? -- Guilhem. signature.asc Description: PGP signature
Bug#1071474: roundcube: xx
Source: roundcube Version: 1.6.6+dfsg-2 Severity: important Control: found -1 1.6.5+dfsg-1~deb12u1 Control: found -1 1.4.15+dfsg.1-1~deb11u2 Control: found -1 1.3.17+dfsg.1-1~deb10u5 Tags: security upstream Roundcube webmail upstream has recently released 1.6.7 [0] which fixes the following vulnerabilities: * Fix command injection via crafted im_convert_path/im_identify_path on Windows. https://github.com/roundcube/roundcubemail/commit/7da322371fd00a54670a5d6679faae0fcbd3f229 * Fix cross-site scripting (XSS) vulnerability in handling list columns from user preferences. https://github.com/roundcube/roundcubemail/commit/9ca8aa6680c579132e0d1fa59447df8d524ec91c * Fix cross-site scripting (XSS) vulnerability in handling SVG animate attributes. https://github.com/roundcube/roundcubemail/commit/ba252dc5e2946506cb8d0b50b2b7bf95ab51876f AFAICT no CVE-ID has been published for these issues, I'll request them. -- Guilhem. [0] https://roundcube.net/news/2024/05/19/security-updates-1.6.7-and-1.5.7 signature.asc Description: PGP signature
Bug#1069127: python-idna: CVE-2024-3651
Hi, On Tue, 16 Apr 2024 at 21:35:22 +0200, Salvatore Bonaccorso wrote: > The following vulnerability was published for python-idna. > > CVE-2024-3651[0]: > | potential DoS via resource consumption via specially crafted inputs to > | idna.encode() I'm preparing an update for this issue for Buster LTS, would you like me to propose debdiffs for (o)s-pu and sid too? Cheers, -- Guilhem. signature.asc Description: PGP signature
Bug#1067763: interimap fails on 32-bit arches with 64-bit time_t
Control: tag -1 pending Hi, On Tue, 26 Mar 2024 at 13:44:28 +0100, Simon Chopin wrote: > interimap is packing structs that are sensible to the time_t transition. > Please see the attached debdiff as a *very* crude attempt to fix it in > Ubuntu. I'm hoping it'll be possible to come up with a neater way to > solve this? Thanks for the patch! Applied it for now, but I agree that manual struct packing is not ideal. I guess the right fix would be to add a small XS module with Arch: any (or to use a dependency that does it, which exists for struct flock but AFAICT not for timeval). Cheers, -- Guilhem. signature.asc Description: PGP signature
Bug#1070314: cryptsetup: backward incompatible change for plain mode when relying on defaults
Package: release-notes Severity: wishlist Hi, cryptsetup 2:2.7.0~rc0-1 has a backward incompatible change for plain mode when relying on defaults cipher and password hashing algorithm. The change affects users upgrading from bookworm to trixie. Plain mode is generally advised against but it still makes sense to include the NEWS entry into the release notes. --8<->8-- Default cipher and password hashing for plain mode have respectively been changed to aes-xts-plain64 and sha256 (from aes-cbc-essiv:sha256 resp. ripemd160). The new values matches what is used for LUKS, but the change does NOT affect LUKS volumes. This is a backward incompatible change for plain mode when relying on the defaults, which (for plain mode only) is strongly advised against. For many releases the Debian wrappers found in the ‘cryptsetup’ binary package have spewed a loud warning for plain devices from crypttab(5) where ‘cipher=’ or ‘hash=’ are not explicitly specified. The cryptsetup(8) executable now issue such a warning as well. --8<->8-- (Original text from https://salsa.debian.org/cryptsetup-team/cryptsetup/-/blob/debian/latest/debian/cryptsetup-bin.NEWS ) Cheers, -- Guilhem. signature.asc Description: PGP signature
Bug#1068415: nghttp2: CVE-2024-28182: Reading unbounded number of HTTP/2 CONTINUATION frames to cause excessive CPU usage
Hi Tomasz, On Fri, 5 Apr 2024 at 01:11:41 +0200, Tomasz Buchert wrote: > Looking into older versions and appropriately patching them will take > more time. I'm preparing an update for this issue for Buster LTS and can hand tested debdiffs over to the Security Team for newer suites if you'd like. (AFAICT the fix is the same but pending feedback I haven't tested it thoroughly yet.) Cheers, -- Guilhem. signature.asc Description: PGP signature
Bug#1068849: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1
On Sat, 27 Apr 2024 at 02:07:21 +0200, Christoph Anton Mitterer wrote: > So you say it's a glibc thingy, that this doesn't show up anymore? Yup, that's what I wrote https://bugs.debian.org/1032235#97 | It was intentional, see the article | https://developers.redhat.com/articles/2021/12/17/why-glibc-234-removed-libpthread . | Unfortunately that change broke initramfs-tools' fix for https://bugs.debian.org/950254 | which we (src:cryptsetup maintainers) relied on for cryptsetup-initramfs. | Until last week src:argon2 had never been rebuilt with the newer glibc, | so it's just unfortunate that we missed that at the time. On the one hand it was unfortunate to find such a severe RC bug (unbootable system with the default config) so late in the freeze, on the other hand it would have been even worse if src:argon2 would have been uploaded to bookworm-security or -pu after the stable release :-) > $ ldd /usr/bin/argon2 > linux-vdso.so.1 (0x7ffcc67d4000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f1a1ee48000) > /lib64/ld-linux-x86-64.so.2 (0x7f1a1f058000) > > I should use libc for determination? Don't know if that's the best or most robust solution but that's what I'd do as workaround at least. > Would you recommend me to reassign #1069912 to initramfs-tools, asking > for a more user-friendly solution? Yup that'd make sense to me (and I see you did that already), thanks! -- Guilhem. signature.asc Description: PGP signature
Bug#1068849: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1
Hi, On Sat, 27 Apr 2024 at 00:33:51 +0200, Christoph Anton Mitterer wrote: > Now the problem is that argon2 is statically linked, so there's no > libpthread showing up in its ldd, and thus copy_exec doesn't realise it > needs to invoke copy_libgcc. Even it weren't, libpthread wouldn't show up since src:argon2 from bookworm and later is built using glibc ≥2.34. AFAICT the “if the ldd output includes libpthread then run copy_libgcc()” logic from initramfs-tools is mostly moot now, see https://bugs.debian.org/1032235#97 . We used the following workaround to manually call copy_libgcc() https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/4cade1eae57abd93e0d6491eebce5f5f163ef186#a630d04e2df57150e6a092fc23f955c6ea0ce412 https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/369cb651abad11a3844fa38ea86ece40f4f40078 for Bookworm, but removed it with 2:2.7.2-1 since src:cryptsetup no longer uses libargon. There is no stability guaranty for transitive dependencies so I'd indeed argue the regression is not src:cryptsetup's fault :-) Adapting the above workarounds to your custom hookfile should solve the issue, though. > Did anyone of your report this issue anywhere else? Some years ago I asked the initramfs-tools maintainers to inconditionally copy libgcc_s to the initramfs image, but IIRC Ben argued it was too seldom used to justify the cost in size and impemented the libpthread detection logic + copy_libgcc() instead. I don't know if the detection logic can be improved/fixed in initramfs-tools, but despite what I promised elbrus in https://bugs.debian.org/1032235#87 it looks like I didn't file a bug. -- Guilhem. signature.asc Description: PGP signature
Bug#1069768: The 'no-agent-forwarding' key restriction disables server alive message support
Control: reassign -1 dropbear-bin 2022.83-1+deb12u1 Control: retitle -1: The 'no-agent-forwarding' key restriction disables server alive message support Control: tag -1 upstream On Wed, 24 Apr 2024 at 18:38:26 +0200, Guilhem Moulin wrote: > On Wed, 24 Apr 2024 at 17:10:57 +0200, Guilhem Moulin wrote: >>> It should be trivially reproducible by running `ssh -o ServerAliveCountMax=3 >>> -o ServerAliveInterval=1 root@yourdropbearserver`. The client should then >>> disconnect after 3 seconds. >> >> Seems to work as expected for me: >> >> $ ssh -oLogLevel=DEBUG3 \ >> -oServerAliveCountMax=3 -oServerAliveInterval=1 \ >> -oUserKnownHostsFile=/tmp/known_hosts \ >> -i /tmp/test.key \ >> -l user -p 10022 127.0.0.1 sleep 300 >> […] > > No wait, this works in the main system but indeed at initramfs stage the > client doesn't get responses to its alive probes. The above was misleading, turns out this was not due to the initramfs per se, but because its authorized_keys file had the following restrictions (which were set in my test environment per cryptsetup-initramfs' recommendations): no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="/bin/cryptroot-unlock" Lee, I assume you have the ‘no-port-forwarding’ restriction too? It appears to disable server alive message support for some reason. This is reproducible at initramfs stage as well as in the main system. -- Guilhem. signature.asc Description: PGP signature
Bug#1069768: dropbear-initramfs becomes unresponsive after several connection attempts
Control: tag -1 - moreinfo unreproducible On Wed, 24 Apr 2024 at 17:10:57 +0200, Guilhem Moulin wrote: >> It should be trivially reproducible by running `ssh -o ServerAliveCountMax=3 >> -o ServerAliveInterval=1 root@yourdropbearserver`. The client should then >> disconnect after 3 seconds. > > Seems to work as expected for me: > > $ ssh -oLogLevel=DEBUG3 \ > -oServerAliveCountMax=3 -oServerAliveInterval=1 \ > -oUserKnownHostsFile=/tmp/known_hosts \ > -i /tmp/test.key \ > -l user -p 10022 127.0.0.1 sleep 300 > […] No wait, this works in the main system but indeed at initramfs stage the client doesn't get responses to its alive probes. My bad for assuming the behavior would be the same given it's the same binary. -- Guilhem. signature.asc Description: PGP signature
Bug#1069768: dropbear-initramfs becomes unresponsive after several connection attempts
On Wed, 24 Apr 2024 at 16:32:09 +0200, Lee Garrett wrote: > Although the dropbear man page is not explicit, I'm assuming it refers to > TCP keepalive. I think this assumption is incorrect: https://sources.debian.org/src/dropbear/2024.84-1/src/common-session.c/#L497 > It should be trivially reproducible by running `ssh -o ServerAliveCountMax=3 > -o ServerAliveInterval=1 root@yourdropbearserver`. The client should then > disconnect after 3 seconds. Seems to work as expected for me: $ ssh -oLogLevel=DEBUG3 \ -oServerAliveCountMax=3 -oServerAliveInterval=1 \ -oUserKnownHostsFile=/tmp/known_hosts \ -i /tmp/test.key \ -l user -p 10022 127.0.0.1 sleep 300 […] debug1: Sending command: sleep 300 debug2: channel 0: request exec confirm 1 debug3: send packet: type 98 debug3: client_repledge: enter debug2: channel_input_open_confirmation: channel 0: callback done debug2: channel 0: open confirm rwindow 65536 rmax 32759 debug3: receive packet: type 99 debug2: channel_input_status_confirm: type 99 id 0 debug2: exec request accepted on channel 0 debug3: send packet: type 80 debug3: receive packet: type 82 debug3: send packet: type 80 debug3: receive packet: type 82 debug3: send packet: type 80 debug3: receive packet: type 82 debug3: send packet: type 80 debug3: receive packet: type 82 […] debug3: send packet: type 80 debug3: receive packet: type 82 debug3: receive packet: type 96 debug2: channel 0: rcvd eof debug2: channel 0: output open -> drain debug2: channel 0: obuf empty debug2: chan_shutdown_write: channel 0: (i0 o1 sock -1 wfd 5 efd 6 [write]) debug2: channel 0: output drain -> closed debug3: receive packet: type 98 debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug3: receive packet: type 97 debug2: channel 0: rcvd close debug2: chan_shutdown_read: channel 0: (i0 o3 sock -1 wfd 4 efd 6 [write]) debug2: channel 0: input open -> closed debug3: channel 0: will not send data after close debug2: channel 0: almost dead debug2: channel 0: gc: notify user debug2: channel 0: gc: user detached debug2: channel 0: send close debug3: send packet: type 97 debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 [session] r0 i3/0 o3/0 e[write]/0 fd -1/-1/6 sock -1 cc -1 io 0x00/0x00) debug3: send packet: type 1 Transferred: sent 15360, received 7448 bytes, in 300.0 seconds Bytes per second: sent 51.2, received 24.8 debug1: Exit status 0 There is one packet 80/82 exchange per second until the `sleep 300` terminates. The output is similar with OpenSSH's sshd. -- Guilhem. signature.asc Description: PGP signature
Bug#1069768: dropbear-initramfs becomes unresponsive after several connection attempts
Control: tag -1 unreproducible moreinfo Hi, On Wed, 24 Apr 2024 at 14:42:43 +0200, Lee Garrett wrote: > After some debugging, it turns out that ServerAliveInterval != 0 will cause > the > ssh client to reset the connection, which dropbear will count as unlock > attempt, > and after three tries it will fail and drop to initramfs shell, after which > it's > not reachable anymore. AFAICT dropbear does support timeout messages (see -K in the manual). I'm unable to reproduce the issue anyway, do you start dropbear with -I? Can you try to start your client with -oLogLevel=DEBUG3 to see why the connection is terminated (from the client's perspective)? Also to take cryptroot out of the picture you could try using `cat -A` as the remote command. -- Guilhem. signature.asc Description: PGP signature
Bug#1059412: netcat-openbsd: diff for NMU version 1.226-1.1
Hi Chris, On Mon, 22 Apr 2024 at 01:43:26 +0200, Chris Hofstaedtler wrote: > I've prepared an NMU for netcat-openbsd (versioned as 1.226-1.1) and > uploaded it to DELAYED/7. Please feel free to tell me if I > should delay it longer. Ooops sorry, that bug fell off-screen. No issue with the NMU, feel free to push your changes to the repository too. Cheers -- Guilhem. signature.asc Description: PGP signature
Bug#1068849: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1
Control: reopen -1 Control: tag -1 - unreproducible moreinfo On Sun, 14 Apr 2024 at 21:26:25 +0200, Guilhem Moulin wrote: > At this point something triggered rebuilding a new initramfs image, but > that's not src:cryptsetup as none of its binary packages have been > upgraded yet. On second thought that was likely incorrect. The log doesn't show anything from src:cryptsetup but likely cryptsetup-initramfs was already upgraded at that point while libcryptsetup12 wasn't. The package dependency constraints are indeed not strict enough. cryptsetup-initramfs now assumes neither cryptsetup(8) nor libcryptsetup.so.12 are linked with libargon2, but since no new symbols were added in 2.7.2 cryptsetup-bin only has Depends: libcryptsetup12 (>= 2:2.7), and it's therefore possible to upgrade cryptsetup-initramfs while keeping the old libcryptsetup12. Upgrading from testing (2:2.6.1-6) works thanks to the Depends: libcryptsetup12 (>= 2:2.7), but upgrading from ≥2:2.7~, <2:2.7.2-1 may yield a broken initramfs image if libcryptsetup12 is not upgraded before cryptsetup-initramfs. -- Guilhem. signature.asc Description: PGP signature
Bug#1068848: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1
On Sat, 13 Apr 2024 at 10:06:32 -0400, Wesley Schwengle wrote: > I had the same issue a while back, because of the t64 transitioning I chaulked > it up to that. I fixed it as described in Ubuntu bug: > > https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1958594 libcryptsetup12 doesn't use libargon2 anymore, so that shouldn't be needed. -- Guilhem. signature.asc Description: PGP signature
Bug#1068849: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1
On Fri, 12 Apr 2024 at 14:37:16 +0200, Guilhem Moulin wrote:
> What is that “GUI” view? src:cryptsetup doesn't provide that, I wonder
> if it might be what needs libphtread.
FWIW, I later noticed you used a splash screen (plymouth) and thought it
might be because of that, but I still cannot reproduce the issue in a
bookworm VM upgraded to sid (using d-i's “encrypted LVM” layout + a
splash screen).
>> After a ctrl-alt-del, I got to the console and there it showed an error about
>> libgcc_s.so.1 not available and aborting.
What was that error message exactly?
> If you still have the broken initramfs image, please extract it with
> `unmkinitramfs /path/to/broken.initrd.img /path/to/destdir` and try to
> find which executable / shared library needs libphtread, for instance
> with
>
>cd /path/to/destdir
>for p in $(find -P {usr/,}lib/x86_64-linux-gnu {usr/,}{,s}bin/ -type f);
> do objdump -p "$p" 2>/dev/null | grep -q pthread && echo "$p"; done
Erm no, that likely won't work since pthread functions have moved from
libpthread.so.1 to libc.so.6 with glibc 2.34. Otherwise copy_exec()
would have pulled in libgcc_s. New attempt:
rm -rf /tmp/initramfs-destdir && \
mkdir -m0700 /tmp/initramfs-destdir && \
unmkinitramfs /path/to/broken.initrd.img /tmp/initramfs-destdir && \
for p in $(find /tmp/initramfs-destdir/main -type f | sort); do \
objdump -T "$p" 2>&1 | grep pthread_exit && echo "^^ $p"; \
done
--
Guilhem.
signature.asc
Description: PGP signature
Bug#1068849: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1
Control: tag -1 + unreproducible moreinfo
On Fri, 12 Apr 2024 at 12:45:09 +0200, Milan Broz wrote:
> Just FYI (for upstream code): if cryptsetup/libcryptsetup is linked with
> OpenSSL >= 3.2,
> it does not need libphtread (as threads are implemented in OpenSSL for Argon2
> internally).
Thanks for confirming! We're now linking with OpenSSL 3.2 indeed, and
our CI confirms that unlocking works in that environment.
2:2.7.2-1 builds with OpenSSL 3.2 *and* removes the libgcc_s/libargon2
workaround from the initramfs hook:
https://tracker.debian.org/news/1517996/accepted-cryptsetup-2272-1-source-into-unstable/
>> It would also be nice if the "gui" view could show the error or at
>> least tell the user to pres ctrl-alt-del to get to a more informative
>> view, took me ages to figure out that one :-(
What is that “GUI” view? src:cryptsetup doesn't provide that, I wonder
if it might be what needs libphtread.
Otherwise, my guess is a race where the the initramfs image was somehow
rebuilt before libcryptsetup12 was upgraded, but AFAICT the dependencies
are properly set to avoid that. Does the broken initramfs image contain
libargon2.so, if so does its libcryptsetup12 use it?
If you still have the broken initramfs image, please extract it with
`unmkinitramfs /path/to/broken.initrd.img /path/to/destdir` and try to
find which executable / shared library needs libphtread, for instance
with
cd /path/to/destdir
for p in $(find -P {usr/,}lib/x86_64-linux-gnu {usr/,}{,s}bin/ -type f);
do objdump -p "$p" 2>/dev/null | grep -q pthread && echo "$p"; done
This will hopefully shed some light on this.
--
Guilhem.
signature.asc
Description: PGP signature
Bug#1068465: plugin thunderbird_labels and keyboard_shortcuts causing traces
On Sat, 06 Apr 2024 at 13:37:23 +0200, Christian Schwamborn wrote: > Just out of curiosity: Why aren't those patches the current stable > bookworm package of roundcube-plugins-extra included? Because the issues were not fixed in time for the Bookworm freeze. An upload to bookworm-backports might be provided later. -- Guilhem. signature.asc Description: PGP signature
Bug#1067154: dropbear-initramfs: please allow generating distinct hostkey instead of copying host's
On Tue, 19 Mar 2024 at 13:50:34 +0100, Daniel Gröber wrote: > Ah, that makes sense. Well that's easy enough for me to fix then not sure > how I missed that while staring at the hook script. I really should have my > green tea before reporting bugs ;) > > Sorry for the noise. No worries :-) I believe removing /etc/dropbear/initramfs/dropbear_*_host_key and running `dpkg-reconfigure dropbear-initramfs` will generate new keys for initramfs use. -- Guilhem. signature.asc Description: PGP signature
Bug#1067154: dropbear-initramfs: please allow generating distinct hostkey instead of copying host's
Control: tag -1 moreinfo Hi, On Tue, 19 Mar 2024 at 12:37:08 +0100, Daniel Gröber wrote: > In that setup there's really no point to reusing the hosts' private > keys and expose them in the initrd unencrypted. Agreed, but AFAICT that's not the case anymore since 2015.68-1. New host keys are generated at postinst stage, and used for initramfs only. But not when upgrading of course, as this would break pinned key material. https://salsa.debian.org/debian/dropbear/-/commit/1c4975743d659b121231b30f8e641b211b1448ee So AFAICT the host's private keys are only used when upgrading from pre-2015.68-1, and in that case the change should be announced via d/NEWS. > Would you accept a patch to allow configuring the dropbear hook > behaviour to generate a new host key instead of reusing the host's > key? What would be use case of generating transient keys when generating the initramfs image? Such keys would not be pinable, and if that's acceptable then a similar behavior (keys generated at boot time not at initramfs generation time) can be achieved with DROPBEAR_OPTIONS="-R". Cheers, -- Guilhem. signature.asc Description: PGP signature
Bug#1065529: interimap: Testsuite fails with openssl 3.2
Hi Sebastian, Great to hear OpenSSL 3.2 will soon be entering sid! :-) On Wed, 06 Mar 2024 at 07:59:53 +0100, Sebastian Andrzej Siewior wrote: > I'm currently puzzled where to look at. Could you please have a look? It seems openssl-req(1ssl) now generates X.509 version 3 certificates by default. (A new flag `-509v1` was added to revert back to version 1.) interimap's test suite generates a transient CAs, but didn't pass any X.509 v3 basic constraints as it assumed v1. The resulting “CA” was therefore generated without CA:TRUE thereby failing peer validation. The fix is trivial, I'll simply change the test suite to generate a v3 CA instead and pass CA:TRUE. But I thought it might be useful to spell the fix out in case there are other affected packages. Cheers, -- Guilhem. signature.asc Description: PGP signature
Bug#1060270: cryptsetup /usr-move DEP17
Hi Helmut, On Tue, 27 Feb 2024 at 14:28:33 +0100, Helmut Grohne wrote: > Please reupload the patch to experimental (with a version higher than > unstable) assuming that cryptsetup-nuke-password will use version 5 as I > am in contact with Raphael Hertzog. Done in 2:2.7.0-1+exp2. Note though that this version (like all uploads to experimental since December) isn't suitable for an upload to sid since it uses OpenSSL's own argon2 implementation rather than libargon2's, and sid's openssl is currently too old for that. I was hopping the openssl transition would happen sooner, but for now we're stuck with rebase/merge/revert between the two branches. I didn't revert the argon2-related changes in 2:2.7.0-1+exp1 or 2:2.7.0-1+exp2 as they are orthogonal to DEP-17. > I hope cryptsetup makes it to testing soon (it'll migrate with lvm2) > such that we can move forward here. I rest my case about this anyway: what I hoped to be a smooth transition to testing will likely take longer as lvm2 is currently RC-buggy :-/ Moreover Ubuntu picked 2:2.7.0-1 already. Let me know once it is time for an upload to sid. If you want to upload both packages in a single dput call I can provide the _source.changes for cryptsetup. Cheers, -- Guilhem. signature.asc Description: PGP signature
Bug#1065073: cryptsetup: Make the information about changes of default cypher and hash in 2.7.0 more visible
Control: reassign -1 cryptsetup-bin
Hi,
On Thu, 29 Feb 2024 at 11:57:52 +, Jurij Smakov wrote:
> While this change is mentioned in the upstream release notes, I could not
> find any mention of it in the Debian's changelog or NEWS file.
The (upstream) change is in the cryptsetup-bin binary package not cryptsetup.
Its NEWS file reads:
cryptsetup (2:2.7.0~rc0-1) experimental; urgency=medium
Default cipher and password hashing for plain mode have respectively
been changed to aes-xts-plain64 and sha256 (from aes-cbc-essiv:sha256
resp. ripemd160).
The new values matches what is used for LUKS, but the change does NOT
affect LUKS volumes.
This is a backward incompatible change for plain mode when relying on
the defaults, which (for plain mode only) is strongly advised against.
For many releases the Debian wrappers found in the ‘cryptsetup’ binary
package have spewed a loud warning for plain devices from crypttab(5)
where ‘cipher=’ or ‘hash=’ are not explicitly specified. The
cryptsetup(8) executable now issue such a warning as well.
-- Guilhem Moulin Wed, 29 Nov 2023 17:19:10 +0100
Also the source package has the following changelog entry:
cryptsetup (2:2.7.0~rc0-1) experimental; urgency=medium
* New upstream release candidate 2.7.0:
[…]
+ plain mode: Set default cipher to aes-xts-plain64 and password hashing
to sha256. This is a backward incompatible change for plain mode when
relying on the defaults. It doesn't affect LUKS volumes. Defaults
for
plain mode should not be relied upon anyway; for many releases the
Debian wrappers found in the ‘cryptsetup’ binary package spew a loud
warning when ‘cipher=’ or ‘hash=’ are not explicitly specified in the
crypttab(5) options of plain devices. The cryptsetup(8) executable
now
issue such a warning as well.
[…]
-- Guilhem Moulin Wed, 29 Nov 2023 17:19:10 +0100
--
Guilhem.
signature.asc
Description: PGP signature
Bug#1060270: closed by Debian FTP Masters (reply to Guilhem Moulin ) (Bug#1060270: fixed in cryptsetup 2:2.7.0-1)
On Tue, 27 Feb 2024 at 13:19:16 +0100, Helmut Grohne wrote: > Can you explain why you reverted? We need this change in unstable > sooner rather than later to move forward with base-files and I already > announced my intention to NMU. The first message of this bug reads: | * Please upload these changes to experimental first. That allows |running them past QA systems such as piuparts, dumat and others and |also lets us double check the version constraints. There is also a coming freeze for Ubuntu 24.04 and I hear they'd like to have 2.7.0. My bad for delaying this, but right now I want 2.7.0 to transition to testing first and not risk blocking on cryptsetup-nuke-password or potential regressions. I intend to upload to sid after the transition. -- Guilhem. signature.asc Description: PGP signature
Bug#1062756: cryptsetup-initramfs Debian bug with libpam-tmpdir and /tmp mounted with noexec
On Wed, 14 Feb 2024 at 13:58:00 +, Patrick Schleizer wrote: > This is not a bug in a downstream distribution. > […] > Could this be fixed in Debian please? I don't see how this would be a bug in cryptsetup-initramfs when mkinitramfs(8) explicitely says DESTDIR should not be mounted with the noexec mount option. -- Guilhem. signature.asc Description: PGP signature
Bug#1063835: roundcube: When upgrading from roundcube 1.4.15+dfsg.1-1~deb11u2 to 1.6.5+dfsg-1~deb12u1 error "table roundcube.filestore does not exist" is thrown, not handled
Control: reassign -1 roundcube-mysql
Control: tag - 1 unreproducible
On Tue, 13 Feb 2024 at 11:47:12 +, Andrew Gallagher via
Pkg-roundcube-maintainers wrote:
> When upgrading roundcube to the latest version, the mariadb schema
> upgrade fails due to a missing table "roundcube.filestore".
> This table apparently never existed, however this did not seem to
> cause any noticeable issues before the upgrade.
It definitely is part of the schema and should have been created when
you installed roundcube-mysql ≥1.4.1-1 or upgraded from <1.4. Piuparts
doesn't croak either.
> It appears therefore that the schema migration makes too many assumptions
> about the state of the current database,
> and so does not handle the missing (but apparently optianal) table
> gracefully. Missing tables should be created if they do not exist..
Schema upgrades come from upstream so that would be a (wishlist)
upstream bug. When using roundcube-{mysql,pgsql,sqlite3} I think it's
reasonable to assume the schema version based on the roundcube version
alone. dbconfig has no way to guess if/how the database has been
manually tampered with, and I'm not sure a more robust migration is even
doable reliably as it's not only about table creation but also indices,
foreign keys, types and constraints on columns etc.
--
Guilhem.
signature.asc
Description: PGP signature
Bug#1062756: cryptsetup-initramfs: cryptkeyctl script fails to discover decrypt_keyctl even when present
Control: tag -1 moreinfo Hi, On Fri, 02 Feb 2024 at 18:44:43 -0500, abrasamji wrote: > update-initramfs log excerpt with set -x: > > Calling hook cryptkeyctl > + PREREQ=cryptroot > + . /usr/share/initramfs-tools/hook-functions > + [ ! -x /tmp/user/0/mkinitramfs_LhQz6c/lib/cryptsetup/scripts/decrypt_keyctl > ] > + exit 0 > > A check with ls -la while update-initramfs was running, prior to > cryptkeyctl being executed, in order to prove it's presence: > > /tmp/user/0/mkinitramfs_LhQz6c/usr/lib/cryptsetup/scripts: > total 4 > drwxr-xr-x 2 root root 60 Feb 2 17:44 . > drwxr-xr-x 3 root root 100 Feb 2 17:44 .. > -rwxr-xr-x 1 root root 2042 Apr 20 2023 decrypt_keyctl > > I changed the '-x' flag in the if statement to a '-s' flag. This fixed > it and I don't know why, and I don't know if its a bug in initramfs, > dash, or cryptsetup or something else. Seems like your update-initramfs is running under TMPDIR=/tmp/user/0, is is perhaps mounted with the ‘noexec’ flag set? That would cause `test -x` to fail on an existing path with the exec bit set, and per mkinitramfs(8) this not supported: ENVIRONMENT mkinitramfs honours the TMPDIR environment variable. If set, it uses subdirectories in the given directory to create its temporary working directories. Else it uses /var/tmp as default value for that purpose. The given directory should be on a filesystem which allows the execution of files stored there, i.e. should not be mounted with the noexec mount option. -- Guilhem. signature.asc Description: PGP signature
Bug#1062471: Does not handle OAuth2 + unauthenticated setups correctly
On Thu, 01 Feb 2024 at 17:08:39 +0100, Jordi Mallach wrote: > Upstream fixed this in > https://github.com/roundcube/roundcubemail/commit/504cdb89a5ed2c0c3491f99abb206dfb42b1200b > and the patch applies well to the bookworm branch. That branch aims at following upstream's 1.6.x so I'm reluctant to backport upstream changes from master. AFAICT upstream hasn't applied the change to their release-1.6 branch. Could you please ask them to do that first? -- Guilhem. signature.asc Description: PGP signature
Bug#1061472: bullseye-pu: package tinyxml/2.6.2-4+deb11u2
On Thu, 25 Jan 2024 at 04:44:12 +0100, Guilhem Moulin wrote:
> [ Changes ]
>
> Fix CVE-2023-34194: Reachable assertion (and application exit) via a
> crafted XML document with a '\0' located after whitespace.
Per https://bugs.debian.org/1061473#12 I guess you'd like CVE-2023-40462
to be removed from d/changelog for bullseye-pu as well. New debdiff
attached.
--
Guilhem.
diffstat for tinyxml-2.6.2 tinyxml-2.6.2
changelog|9 +
patches/CVE-2023-34194.patch | 27 +++
patches/series |1 +
3 files changed, 37 insertions(+)
diff -Nru tinyxml-2.6.2/debian/changelog tinyxml-2.6.2/debian/changelog
--- tinyxml-2.6.2/debian/changelog 2022-10-20 16:32:51.0 +0200
+++ tinyxml-2.6.2/debian/changelog 2024-01-25 04:12:05.0 +0100
@@ -1,3 +1,12 @@
+tinyxml (2.6.2-4+deb11u2) bullseye; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix CVE-2023-34194: Reachable assertion (and application exit) via a
+crafted XML document with a '\0' located after whitespace.
+ (Closes: #1059315)
+
+ -- Guilhem Moulin Thu, 25 Jan 2024 04:12:05 +0100
+
tinyxml (2.6.2-4+deb11u1) bullseye; urgency=medium
* Import fix for CVE-2021-42260.
diff -Nru tinyxml-2.6.2/debian/patches/CVE-2023-34194.patch
tinyxml-2.6.2/debian/patches/CVE-2023-34194.patch
--- tinyxml-2.6.2/debian/patches/CVE-2023-34194.patch 1970-01-01
01:00:00.0 +0100
+++ tinyxml-2.6.2/debian/patches/CVE-2023-34194.patch 2024-01-25
04:12:05.00000 +0100
@@ -0,0 +1,27 @@
+From: Guilhem Moulin
+Date: Sat, 30 Dec 2023 14:15:54 +0100
+Subject: Avoid reachable assertion via crafted XML document with a '\0'
+ located after whitespace
+
+Bug: https://www.forescout.com/resources/sierra21-vulnerabilities
+Bug-Debian: https://bugs.debian.org/1059315
+Bug-Debian: https://security-tracker.debian.org/tracker/CVE-2023-34194
+---
+ tinyxmlparser.cpp | 4
+ 1 file changed, 4 insertions(+)
+
+diff --git a/tinyxmlparser.cpp b/tinyxmlparser.cpp
+index 8aa0dfa..1601962 100644
+--- a/tinyxmlparser.cpp
b/tinyxmlparser.cpp
+@@ -1606,6 +1606,10 @@ const char* TiXmlDeclaration::Parse( const char* p,
TiXmlParsingData* data, TiXm
+ }
+
+ p = SkipWhiteSpace( p, _encoding );
++ if ( !p || !*p )
++ {
++ break;
++ }
+ if ( StringEqual( p, "version", true, _encoding ) )
+ {
+ TiXmlAttribute attrib;
diff -Nru tinyxml-2.6.2/debian/patches/series
tinyxml-2.6.2/debian/patches/series
--- tinyxml-2.6.2/debian/patches/series 2022-10-20 16:32:49.0 +0200
+++ tinyxml-2.6.2/debian/patches/series 2024-01-25 04:12:05.0 +0100
@@ -1,3 +1,4 @@
enforce-use-stl.patch
entity-encoding.patch
CVE-2021-42260.patch
+CVE-2023-34194.patch
signature.asc
Description: PGP signature
Bug#1061473: bookworm-pu: package tinyxml/2.6.2-6+deb12u1
Control: tags -1 - moreinfo
On Mon, 29 Jan 2024 at 21:55:37 +, Adam D. Barratt wrote:
>
> On Thu, 2024-01-25 at 04:45 +0100, Guilhem Moulin wrote:
>> Fix CVE-2023-34194: Reachable assertion (and application exit) via a
>> crafted XML document with a '\0' located after whitespace.
>
> + * Fix CVE-2023-34194 / CVE-2023-40462: Reachable assertion (and
> application
>
> As far as I can tell from the Security Tracker, CVE-2023-40462
> specifically refers to TinyXML's use in software that isn't in Debian.
> Does it make sense to mention it in the changelog?
That CVE was assigned to TinyXML until
https://salsa.debian.org/security-tracker-team/security-tracker/-/commit/7e507c932b999df48f808969c00f07a638e3357b
,
see also https://bugs.debian.org/1059315 .
But fair enough, new debiff attached :-)
--
Guilhem.
diffstat for tinyxml-2.6.2 tinyxml-2.6.2
changelog|9 +
patches/CVE-2023-34194.patch | 27 +++
patches/series |1 +
3 files changed, 37 insertions(+)
diff -Nru tinyxml-2.6.2/debian/changelog tinyxml-2.6.2/debian/changelog
--- tinyxml-2.6.2/debian/changelog 2021-12-12 23:53:05.0 +0100
+++ tinyxml-2.6.2/debian/changelog 2024-01-25 04:27:36.0 +0100
@@ -1,3 +1,12 @@
+tinyxml (2.6.2-6+deb12u1) bookworm; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix CVE-2023-34194: Reachable assertion (and application exit) via a
+crafted XML document with a '\0' located after whitespace.
+(Closes: #1059315)
+
+ -- Guilhem Moulin Thu, 25 Jan 2024 04:27:36 +0100
+
tinyxml (2.6.2-6) unstable; urgency=medium
* Import fix for CVE-2021-42260.
diff -Nru tinyxml-2.6.2/debian/patches/CVE-2023-34194.patch
tinyxml-2.6.2/debian/patches/CVE-2023-34194.patch
--- tinyxml-2.6.2/debian/patches/CVE-2023-34194.patch 1970-01-01
01:00:00.0 +0100
+++ tinyxml-2.6.2/debian/patches/CVE-2023-34194.patch 2024-01-25
04:27:36.0 +0100
@@ -0,0 +1,27 @@
+From: Guilhem Moulin
+Date: Sat, 30 Dec 2023 14:15:54 +0100
+Subject: Avoid reachable assertion via crafted XML document with a '\0'
+ located after whitespace
+
+Bug: https://www.forescout.com/resources/sierra21-vulnerabilities
+Bug-Debian: https://bugs.debian.org/1059315
+Bug-Debian: https://security-tracker.debian.org/tracker/CVE-2023-34194
+---
+ tinyxmlparser.cpp | 4
+ 1 file changed, 4 insertions(+)
+
+diff --git a/tinyxmlparser.cpp b/tinyxmlparser.cpp
+index 8aa0dfa..1601962 100644
+--- a/tinyxmlparser.cpp
b/tinyxmlparser.cpp
+@@ -1606,6 +1606,10 @@ const char* TiXmlDeclaration::Parse( const char* p,
TiXmlParsingData* data, TiXm
+ }
+
+ p = SkipWhiteSpace( p, _encoding );
++ if ( !p || !*p )
++ {
++ break;
++ }
+ if ( StringEqual( p, "version", true, _encoding ) )
+ {
+ TiXmlAttribute attrib;
diff -Nru tinyxml-2.6.2/debian/patches/series
tinyxml-2.6.2/debian/patches/series
--- tinyxml-2.6.2/debian/patches/series 2021-12-12 23:48:07.0 +0100
+++ tinyxml-2.6.2/debian/patches/series 2024-01-25 04:27:36.0 +0100
@@ -1,3 +1,4 @@
enforce-use-stl.patch
entity-encoding.patch
CVE-2021-42260.patch
+CVE-2023-34194.patch
signature.asc
Description: PGP signature
Bug#1061622: Some e-mail attachments are invisible
Control: reassign -1 roundcube-core 1.6.6+dfsg-1 Control: forwarded -1 https://github.com/roundcube/roundcubemail/issues/5051 Control: tag -1 upstream On Sat, 27 Jan 2024 at 15:38:43 +0100, BohwaZ wrote: > I am suggesting this patch here as upstream doesn't want to fix > this longstanding issue: > https://github.com/roundcube/roundcubemail/pull/9150 Upstream has given a rationale for not accepting that PR, but that doesn't mean they're not interested in fixing the issue in the first place (I note that issue 5051 is still open). Not keen to maintain such a patch though in Debian, but leaving this bug open to track its status upstream (via forwarded URL). -- Guilhem. signature.asc Description: PGP signature
Bug#1061556: bullseye-pu: package dropbear/2020.81-3+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: dropb...@packages.debian.org Control: affects -1 + src:dropbear [ Reason ] dropbear 2020.81-3 is vulnerable to CVE-2021-36369 and CVE-2023-48795 (terrapin attack). The security team argued these issues didn't warrant a CVE, and suggested to go via s-pu instead. [ Impact ] Bullseye users will remain vulnerable to CVE-2021-36369 and CVE-2023-48795. For the latter, details about what that entails has been discussed on the upstream bug tracker at https://github.com/mkj/dropbear/issues/270 , where one the terrapin finders wrote that | While it is true that not sending server-sig-algs does not prevent the | client from trying SHA2-based RSA signatures, we observed the suggested | behavior (preferring SHA-1 over SHA-2 when server-sig-algs is missing) | in a wide variety of SSH clients. Also, the order of algorithms in | server-sig-algs is used by some clients in case multiple private keys | are present, potentially leading to downgrades as well. | | However, we do not consider this application of the Terrapin attack to | have a significant impact. Instead, our main concern is the combination | of Terrapin with implementation bugs, as seen in AsyncSSH. We evaluated | only a handful of SSH implementations, where one already allowed for | in-session man-in-the-middle attacks. Given the wide variety of SSH | implementations, one can estimate with sufficient probability that other | implementations face similar issues. [ Tests ] I manually checked the updated dropbear SSHd/dbclient against the Terrapin scanner, and also the new -oDisableTrivialAuth=yes option on the client. [ Risks ] Risk is low: all patches come from upstream and applied cleanly. [ 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 [ Changes ] * Add option -oDisableTrivialAuth=yes to mitigate CVE-2021-36369. * Implement Strict KEX mode to fix CVE-2023-48795 (terrapin attack). * d/t/on-lvm-and-luks: Target bullseye not sid. * d/t/on-lvm-and-luks: Bump disk image size to 4G as the previous size was too small for bullseye-security updates (kernel etc.). * Salsa CI: Target bullseye and disable lintian job. -- Guilhem. diffstat for dropbear-2020.81 dropbear-2020.81 changelog| 18 +++ patches/CVE-2021-36369.patch | 182 + patches/CVE-2023-48795.patch | 232 +++ patches/series |2 salsa-ci.yml |8 + tests/on-lvm-and-luks| 16 +- 6 files changed, 448 insertions(+), 10 deletions(-) diff -Nru dropbear-2020.81/debian/changelog dropbear-2020.81/debian/changelog --- dropbear-2020.81/debian/changelog 2021-01-14 21:14:26.0 +0100 +++ dropbear-2020.81/debian/changelog 2024-01-26 12:00:26.0 +0100 @@ -1,3 +1,21 @@ +dropbear (2020.81-3+deb11u1) bullseye; urgency=medium + + * Fix CVE-2021-36369: Due to a non-RFC-compliant check of the available +authentication methods in the client-side SSH code, it is possible for an +SSH server to change the login process in its favor. + * Fix CVE-2023-48795 (terrapin attack): The SSH transport protocol with +certain OpenSSH extensions allows remote attackers to bypass integrity +checks such that some packets are omitted (from the extension negotiation +message), and a client and server may consequently end up with a +connection for which some security features have been downgraded or +disabled, aka a Terrapin attack. (Closes: #1059001) + * d/t/on-lvm-and-luks: Target bullseye not sid. + * d/t/on-lvm-and-luks: Bump disk image size to 4G as the previous size was +too small for bullseye-security updates (kernel etc.). + * Salsa CI: Target bullseye and disable lintian job. + + -- Guilhem Moulin Fri, 26 Jan 2024 12:00:26 +0100 + dropbear (2020.81-3) unstable; urgency=medium * Initramfs: Use 10 placeholders in ~root template. diff -Nru dropbear-2020.81/debian/patches/CVE-2021-36369.patch dropbear-2020.81/debian/patches/CVE-2021-36369.patch --- dropbear-2020.81/debian/patches/CVE-2021-36369.patch1970-01-01 01:00:00.0 +0100 +++ dropbear-2020.81/debian/patches/CVE-2021-36369.patch2024-01-26 12:00:26.0 +0100 @@ -0,0 +1,182 @@ +From: Manfred Kaiser <37737811+manfred-kai...@users.noreply.github.com> +Date: Thu, 19 Aug 2021 17:37:14 +0200 +Subject: Added option to disable trivial auth methods + +* added option to disable trivial auth methods + +* rename argument to match with other ssh clients + +* fixed trivial auth detection for pubkeys + +Origin: https://github.com/mkj/dropbear/commit/210a9833496ed2a93b8da93924874938127ce0b5 +Origin: https://github.com/m
Bug#1061549: bookworm-pu: package dropbear/2022.83-1+deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: dropb...@packages.debian.org Control: affects -1 + src:dropbear [ Reason ] dropbear 2022.83-1 is vunerable to CVE-2023-48795 (terrapin attack). https://terrapin-attack.com/ Based on https://bugs.debian.org/1059001 the security team argued this didn't warrant a CVE, and suggested to go via s-pu instead. [ Impact ] Bookworm users will remain vulnerable to CVE-2023-48795. Details about what that entails has been discussed on the upstream bug tracker at https://github.com/mkj/dropbear/issues/270 , where one the terrapin finder wrote that | While it is true that not sending server-sig-algs does not prevent the | client from trying SHA2-based RSA signatures, we observed the suggested | behavior (preferring SHA-1 over SHA-2 when server-sig-algs is missing) | in a wide variety of SSH clients. Also, the order of algorithms in | server-sig-algs is used by some clients in case multiple private keys | are present, potentially leading to downgrades as well. | | However, we do not consider this application of the Terrapin attack to | have a significant impact. Instead, our main concern is the combination | of Terrapin with implementation bugs, as seen in AsyncSSH. We evaluated | only a handful of SSH implementations, where one already allowed for | in-session man-in-the-middle attacks. Given the wide variety of SSH | implementations, one can estimate with sufficient probability that other | implementations face similar issues. [ Tests ] I checked the updated dropbear SSHd/dbclient against the Terrapin scanner. [ Risks ] Risk is low: the patch comes from upstream and applied cleanly (no upstream version was released since Bookworm was released). [ 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 [ Changes ] Implement Strict KEX mode to fix CVE-2023-48795 (terrapin attack). -- Guilhem. diffstat for dropbear-2022.83 dropbear-2022.83 changelog| 11 ++ patches/CVE-2023-48795.patch | 232 +++ patches/series |1 salsa-ci.yml |8 + 4 files changed, 252 insertions(+) diff -Nru dropbear-2022.83/debian/changelog dropbear-2022.83/debian/changelog --- dropbear-2022.83/debian/changelog 2022-11-14 22:16:35.0 +0100 +++ dropbear-2022.83/debian/changelog 2024-01-26 10:01:00.0 +0100 @@ -1,3 +1,14 @@ +dropbear (2022.83-1+deb12u1) bookworm; urgency=medium + + * Fix CVE-2023-48795: (terrapin attack): The SSH transport protocol with +certain OpenSSH extensions allows remote attackers to bypass integrity +checks such that some packets are omitted (from the extension negotiation +message), and a client and server may consequently end up with a +connection for which some security features have been downgraded or +disabled, aka a Terrapin attack. (Closes: #1059001) + + -- Guilhem Moulin Fri, 26 Jan 2024 10:01:00 +0100 + dropbear (2022.83-1) unstable; urgency=medium * New upstream release 2022.83. Support for ssh-dss (DSA) host and user diff -Nru dropbear-2022.83/debian/patches/CVE-2023-48795.patch dropbear-2022.83/debian/patches/CVE-2023-48795.patch --- dropbear-2022.83/debian/patches/CVE-2023-48795.patch1970-01-01 01:00:00.0 +0100 +++ dropbear-2022.83/debian/patches/CVE-2023-48795.patch2024-01-26 10:01:00.0 +0100 @@ -0,0 +1,232 @@ +From: Matt Johnston +Date: Mon, 20 Nov 2023 14:02:47 +0800 +Subject: Implement Strict KEX mode + +As specified by OpenSSH with kex-strict-c-...@openssh.com and +kex-strict-s-...@openssh.com. + +Origin: https://github.com/mkj/dropbear/commit/6e43be5c7b99dbee49dc72b6f989f29fdd7e9356 +Bug-Debian: https://security-tracker.debian.org/tracker/CVE-2023-48795 +Bug-Debian: https://bugs.debian.org/1059001 +--- + cli-session.c| 11 +++ + common-algo.c| 6 ++ + common-kex.c | 26 +- + kex.h| 3 +++ + process-packet.c | 34 +++--- + ssh.h| 4 + svr-session.c| 3 +++ + 7 files changed, 71 insertions(+), 16 deletions(-) + +diff --git a/cli-session.c b/cli-session.c +index 5981b24..d261c8f 100644 +--- a/cli-session.c b/cli-session.c +@@ -46,6 +46,7 @@ static void cli_finished(void) ATTRIB_NORETURN; + static void recv_msg_service_accept(void); + static void cli_session_cleanup(void); + static void recv_msg_global_request_cli(void); ++static void cli_algos_initialise(void); + + struct clientsession cli_ses; /* GLOBAL */ + +@@ -117,6 +118,7 @@ void cli_session(int sock_in, int sock_out, struct dropbear_progress_connection + } + + chaninitialise(cli_chantypes); ++ cli_algos_initi
Bug#1061473: bookworm-pu: package tinyxml/2.6.2-6+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: tiny...@packages.debian.org
Control: affects -1 + src:tinyxml
[ Reason ]
Fix CVE-2023-34194: Reachable assertion (and application exit) via a
crafted XML document with a '\0' located after whitespace.
The issue has been fixed in buster LTS as well as sid (via NMU). The
security team argued it didn't warrant a DSA, and suggested to go via
s-pu instead.
[ Impact ]
Buster users will regress when upgrading to bookworm.
[ Tests ]
The vulnerability report came with POCs which was checked against.
[ Risks ]
The patch is trivial but tinyxml appears to be abandoned upstream so I
wrote it myself.
[ 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 stable
[x] the issue is verified as fixed in unstable
[ Changes ]
Fix CVE-2023-34194: Reachable assertion (and application exit) via a
crafted XML document with a '\0' located after whitespace.
--
Guilhem.
diffstat for tinyxml-2.6.2 tinyxml-2.6.2
changelog|9 +
patches/CVE-2023-34194.patch | 27 +++
patches/series |1 +
3 files changed, 37 insertions(+)
diff -Nru tinyxml-2.6.2/debian/changelog tinyxml-2.6.2/debian/changelog
--- tinyxml-2.6.2/debian/changelog 2021-12-12 23:53:05.0 +0100
+++ tinyxml-2.6.2/debian/changelog 2024-01-25 04:27:36.0 +0100
@@ -1,3 +1,12 @@
+tinyxml (2.6.2-6+deb12u1) bookworm; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix CVE-2023-34194 / CVE-2023-40462: Reachable assertion (and application
+exit) via a crafted XML document with a '\0' located after whitespace.
+ (Closes: #1059315)
+
+ -- Guilhem Moulin Thu, 25 Jan 2024 04:27:36 +0100
+
tinyxml (2.6.2-6) unstable; urgency=medium
* Import fix for CVE-2021-42260.
diff -Nru tinyxml-2.6.2/debian/patches/CVE-2023-34194.patch
tinyxml-2.6.2/debian/patches/CVE-2023-34194.patch
--- tinyxml-2.6.2/debian/patches/CVE-2023-34194.patch 1970-01-01
01:00:00.0 +0100
+++ tinyxml-2.6.2/debian/patches/CVE-2023-34194.patch 2024-01-25
04:27:36.0 +0100
@@ -0,0 +1,27 @@
+From: Guilhem Moulin
+Date: Sat, 30 Dec 2023 14:15:54 +0100
+Subject: Avoid reachable assertion via crafted XML document with a '\0'
+ located after whitespace
+
+Bug: https://www.forescout.com/resources/sierra21-vulnerabilities
+Bug-Debian: https://bugs.debian.org/1059315
+Bug-Debian: https://security-tracker.debian.org/tracker/CVE-2023-34194
+---
+ tinyxmlparser.cpp | 4
+ 1 file changed, 4 insertions(+)
+
+diff --git a/tinyxmlparser.cpp b/tinyxmlparser.cpp
+index 8aa0dfa..1601962 100644
+--- a/tinyxmlparser.cpp
b/tinyxmlparser.cpp
+@@ -1606,6 +1606,10 @@ const char* TiXmlDeclaration::Parse( const char* p,
TiXmlParsingData* data, TiXm
+ }
+
+ p = SkipWhiteSpace( p, _encoding );
++ if ( !p || !*p )
++ {
++ break;
++ }
+ if ( StringEqual( p, "version", true, _encoding ) )
+ {
+ TiXmlAttribute attrib;
diff -Nru tinyxml-2.6.2/debian/patches/series
tinyxml-2.6.2/debian/patches/series
--- tinyxml-2.6.2/debian/patches/series 2021-12-12 23:48:07.0 +0100
+++ tinyxml-2.6.2/debian/patches/series 2024-01-25 04:27:36.0 +0100
@@ -1,3 +1,4 @@
enforce-use-stl.patch
entity-encoding.patch
CVE-2021-42260.patch
+CVE-2023-34194.patch
signature.asc
Description: PGP signature
Bug#1061472: bullseye-pu: package tinyxml/2.6.2-4+deb11u2
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: tiny...@packages.debian.org
Control: affects -1 + src:tinyxml
[ Reason ]
Fix CVE-2023-34194: Reachable assertion (and application exit) via a
crafted XML document with a '\0' located after whitespace.
The issue has been fixed in buster LTS as well as sid (via NMU). The
security team argued it didn't warrant a DSA, and suggested to go via
s-pu instead.
[ Impact ]
Buster users will regress when upgrading to bullseye.
[ Tests ]
The vulnerability report came with POCs which was checked against.
[ Risks ]
The patch is trivial but tinyxml appears to be abandoned upstream so I
wrote it myself.
[ 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 oldstable
[x] the issue is verified as fixed in unstable
[ Changes ]
Fix CVE-2023-34194: Reachable assertion (and application exit) via a
crafted XML document with a '\0' located after whitespace.
--
Guilhem.
diffstat for tinyxml-2.6.2 tinyxml-2.6.2
changelog|9 +
patches/CVE-2023-34194.patch | 27 +++
patches/series |1 +
3 files changed, 37 insertions(+)
diff -Nru tinyxml-2.6.2/debian/changelog tinyxml-2.6.2/debian/changelog
--- tinyxml-2.6.2/debian/changelog 2022-10-20 16:32:51.0 +0200
+++ tinyxml-2.6.2/debian/changelog 2024-01-25 04:12:05.0 +0100
@@ -1,3 +1,12 @@
+tinyxml (2.6.2-4+deb11u2) bullseye; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix CVE-2023-34194 / CVE-2023-40462: Reachable assertion (and application
+exit) via a crafted XML document with a '\0' located after whitespace.
+ (Closes: #1059315)
+
+ -- Guilhem Moulin Thu, 25 Jan 2024 04:12:05 +0100
+
tinyxml (2.6.2-4+deb11u1) bullseye; urgency=medium
* Import fix for CVE-2021-42260.
diff -Nru tinyxml-2.6.2/debian/patches/CVE-2023-34194.patch
tinyxml-2.6.2/debian/patches/CVE-2023-34194.patch
--- tinyxml-2.6.2/debian/patches/CVE-2023-34194.patch 1970-01-01
01:00:00.0 +0100
+++ tinyxml-2.6.2/debian/patches/CVE-2023-34194.patch 2024-01-25
04:12:05.0 +0100
@@ -0,0 +1,27 @@
+From: Guilhem Moulin
+Date: Sat, 30 Dec 2023 14:15:54 +0100
+Subject: Avoid reachable assertion via crafted XML document with a '\0'
+ located after whitespace
+
+Bug: https://www.forescout.com/resources/sierra21-vulnerabilities
+Bug-Debian: https://bugs.debian.org/1059315
+Bug-Debian: https://security-tracker.debian.org/tracker/CVE-2023-34194
+---
+ tinyxmlparser.cpp | 4
+ 1 file changed, 4 insertions(+)
+
+diff --git a/tinyxmlparser.cpp b/tinyxmlparser.cpp
+index 8aa0dfa..1601962 100644
+--- a/tinyxmlparser.cpp
b/tinyxmlparser.cpp
+@@ -1606,6 +1606,10 @@ const char* TiXmlDeclaration::Parse( const char* p,
TiXmlParsingData* data, TiXm
+ }
+
+ p = SkipWhiteSpace( p, _encoding );
++ if ( !p || !*p )
++ {
++ break;
++ }
+ if ( StringEqual( p, "version", true, _encoding ) )
+ {
+ TiXmlAttribute attrib;
diff -Nru tinyxml-2.6.2/debian/patches/series
tinyxml-2.6.2/debian/patches/series
--- tinyxml-2.6.2/debian/patches/series 2022-10-20 16:32:49.0 +0200
+++ tinyxml-2.6.2/debian/patches/series 2024-01-25 04:12:05.0 +0100
@@ -1,3 +1,4 @@
enforce-use-stl.patch
entity-encoding.patch
CVE-2021-42260.patch
+CVE-2023-34194.patch
signature.asc
Description: PGP signature
Bug#1061471: bullseye-pu: package xerces-c/3.2.3+debian-3+deb11u1
On Thu, 25 Jan 2024 at 03:54:46 +0100, Guilhem Moulin wrote:
> [x] attach debdiff against the package in oldstable
Oops, doing that now :-)
--
Guilhem.
diffstat for xerces-c-3.2.3+debian xerces-c-3.2.3+debian
changelog | 12
patches/CVE-2018-1311-mitigation.patch | 52
patches/CVE-2018-1311.patch | 653
++
patches/CVE-2023-37536.patch| 79
+
patches/Fix-NetAccessorTest-to-exit-with-non-zero-status-in-case-.patch | 44
patches/series |4
salsa-ci.yml|9
7 files changed, 800 insertions(+), 53 deletions(-)
diff -Nru xerces-c-3.2.3+debian/debian/changelog
xerces-c-3.2.3+debian/debian/changelog
--- xerces-c-3.2.3+debian/debian/changelog 2020-12-14 17:43:13.0
+0100
+++ xerces-c-3.2.3+debian/debian/changelog 2023-12-31 12:43:25.0
+0100
@@ -1,3 +1,15 @@
+xerces-c (3.2.3+debian-3+deb11u1) bullseye; urgency=high
+
+ * Non-maintainer upload.
+ * Fix CVE-2018-1311: Use-after-free on external DTD scan. This replaces
+RedHat's mitigation patch (which introduced a memory leak).
+Closes: #947431
+ * Fix CVE-2023-37536: Integer overflows in DFAContentModel class.
+ * Upstream tests: Cherry-pick upstream patch to fix NetAccessorTest to exit
+with non-zero status in case of error.
+
+ -- Guilhem Moulin Sun, 31 Dec 2023 12:43:25 +0100
+
xerces-c (3.2.3+debian-3) unstable; urgency=medium
* Fix MemHandlerTest1 on 32-bit systems to compensate for CVE-2018-1311 fix
diff -Nru xerces-c-3.2.3+debian/debian/patches/CVE-2018-1311-mitigation.patch
xerces-c-3.2.3+debian/debian/patches/CVE-2018-1311-mitigation.patch
--- xerces-c-3.2.3+debian/debian/patches/CVE-2018-1311-mitigation.patch
2020-12-14 17:43:13.0 +0100
+++ xerces-c-3.2.3+debian/debian/patches/CVE-2018-1311-mitigation.patch
1970-01-01 01:00:00.0 +0100
@@ -1,52 +0,0 @@
-
-https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-1311
-
a/src/xercesc/internal/IGXMLScanner.cpp
-+++ b/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);
a/tests/expected/MemHandlerTest1.log
-+++ b/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.
/dev/null
-+++ b/tests/expected/MemHandlerTest1_32.log
-@@ -0,0 +1,4 @@
-+At destruction, domBuilderMemMonitor has 180 bytes.
-+At destruction, sax2MemMonitor has 180 bytes.
-+At destruction, sax1MemMonitor has 180 bytes.
-+At destruction, staticMemMonitor has 0 bytes.
a/scripts/run-test.in
-+++ b/scripts/run-test.in
-@@ -46,6 +46,11 @@ run_test() {
- sed -i -e 's;\( *[0-9][0-9]* *ms *\);{timing removed};' "$output"
-
- exp=$(cat "${srcdir}/expected/${name}.log")
-+
-+if [ "${name}" = "MemHandlerTest1" ] && [ "$(dpkg-architecture -q
DEB_HOST_ARCH_BITS)" -eq 32 ]; then
-+exp=$(cat "${srcdir}/expected/${name}_32.log")
-+fi
-+
- obs=$(cat "$output")
-
- echo "--"
diff -Nru xerces-c-3.2.3+debian/debian/patches/CVE-2018-1311.patch
xerces-c-3.2.3+debian/debian/patches/CVE-2018-1311.patch
--- xerces-c-3.2.3+debian/debian/patches/CVE-2018-1311.patch1970-01-01
01:00:00.0 +0100
+++ xerces-c-3.2.3+debian/debian/patches/CVE-2018-1311.patch2023-12-31
12:43:25.0 +0100
@@ -0,0 +1,653 @@
+From: Karen Arutyunov
+Date: Wed, 13 Dec 2023 09:59:07 +0200
+Subject: XERCESC-2188 - Use-after-free on external DTD scan (CVE-2018-1311)
+
+These are the instructions for observing the bug (before this commit):
+
+$ git clone https://github.com/apache/xerces-c.git
+$ cd xerces-c
+$ mkdir build
+$ cd build
+$ c
Bug#1061471: bullseye-pu: package xerces-c/3.2.3+debian-3+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: xerce...@packages.debian.org Control: affects -1 + src:xerces-c [ Reason ] xerces-c 3.2.3+debian-3 is vulnerable to CVE-2023-37536 (Integer overflows in DFAContentModel class). Also, while it ships a mitigation for CVE-2018-1311, it does so at the expense of a memory leak, cf. #947431. These issues have both been fixed in buster LTS. The “better” (upstream-vetted) fix for CVE-2018-1311 have also landed in sid via NMU and migrated to testing last month. The security team argued the issues didn't warrant a DSA, and suggested to go via s-pu instead. [ Impact ] Buster users will regress when upgrading to bullseye. [ Tests ] The vulnerabilities reports came with POCs which were checked against: https://issues.apache.org/jira/browse/XERCESC-2241 https://issues.apache.org/jira/browse/XERCESC-2188 Also the package runs the upstream test suite at build time. [ Risks ] AFAICT no alternative exists. I think the risk of regression given the upstream patches cleanly applied. Also the fixes are already shipped in buster and sid/trixie. [ 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 oldstable [x] the issue is verified as fixed in unstable [ Changes ] * Fix CVE-2018-1311: Use-after-free on external DTD scan. This replaces RedHat's mitigation patch (which introduced a memory leak). Closes: #947431 * Fix CVE-2023-37536: Integer overflows in DFAContentModel class. * Upstream tests: Cherry-pick upstream patch to fix NetAccessorTest to exit with non-zero status in case of error. -- Guilhem. signature.asc Description: PGP signature
Bug#1059001: dropbear: CVE-2023-48795
Hi, On Tue, 19 Dec 2023 at 09:08:00 +0100, Salvatore Bonaccorso wrote: > The following vulnerability was published for dropbear. > > CVE-2023-48795[0]: > […] > Dropbear commit [1] implements the Strict KEX mode as well. In my > understanding of [2] the issue might be less of a security concern for > Dropbear itself, not reducing the Dropbear security. FWIW this has been clarified at https://github.com/mkj/dropbear/issues/270 , where dropbear upstream as well as a terrapin author have chimed in. I've backported the upstream fix to 2022.83 and will propose fixes for (old)stable via s-pu. Cheers, -- Guilhem. signature.asc Description: PGP signature
Bug#1060270: /lib/cryptsetup/askpass: coordinated move to /usr for DEP17
Hi, On Tue, 23 Jan 2024 at 10:15:02 +0100, Raphael Hertzog wrote: > when do you plan to upload a cryptsetup moving the files to /usr? I can have a look after the week-end or in early February. There are other issues I'd like to fix in the next upload. | I see that this may sound scary. We'll get past this mess together. If | things break, I'll keep the pieces and I've done so for molly-guard | already. Thanks! It looks specially scary indeed with the several iterations of the attached patch :-) Cheers -- Guilhem. signature.asc Description: PGP signature
Bug#1059745: ITP: cryptsetup-2fa -- 2FA plugin for cryptsetup
On Sun, 31 Dec 2023 at 22:07:07 +0800, YunQiang Su wrote: > systemd-cryptsetup doesn't have suspend support. > cryptsetup-suspend will fails. Hence a wishlish bug? :-) FWIW I'm part of the cryptsetup packaging team, which is upstream for cryptsetup-suspend. cryptsetup-suspend supports all unlock methods supported by cryptsetup-initramfs, and I believe this will remain the case once FIDO2 and TPM support is added to cryptsetup-initramfs. > In fact, hibernate is an option for me, but currently, Linux kernel cannot > support hibernate if crypt disk is used. It can and does, but the initramfs needs some logic to unlock the disks holding the resume device(s). It already works in interactive mode or when unlocking via key files, smartcards, kernel keyring, etc. For FIDO2 resp. TPM, it'll work once #1023700 resp. #1031254 is fixed. > This script will only in initramfs You might intend to use it that way, but AFAICT there is nothing preventing its use outside an initramfs. -- Guilhem. signature.asc Description: PGP signature
Bug#1059745: ITP: cryptsetup-2fa -- 2FA plugin for cryptsetup
On Sun, 31 Dec 2023 at 21:22:36 +0800, YunQiang Su wrote: >> Is there any reason to not just use systemd-cryptenroll? > > Yes. I tried to use systemd-cryptenroll, while it cannot work with > cryptsetup-suspend. > I need a way to suspend or hibernate without disks decrypted. Seems like this should be a wishlist bug against cryptsetup-suspend not an ITP. I don't foresee any reason why this wouldn't work once #1023700 and #1031254 are fixed. > The passphrase is stored in /var/cache, and switch_root will clean > all of them, so I guess it won't leak. The partition might be backed by plain-test drives or similar, so it can't be used to write sensitive data. -- Guilhem. signature.asc Description: PGP signature
Bug#1059745: ITP: cryptsetup-2fa -- 2FA plugin for cryptsetup
Hi, On Sun, 31 Dec 2023 at 18:49:30 +0800, YunQiang Su wrote: > 2 mthods are supported for 2 FA: > - Yubikey Challenge > - TPM2 Keypair If your concern is to make these work with cryptsetup-initramfs, there are #1023700 and #1031254 open against src:cryptsetup. The plan is to have that in trixie. Did you check if the solutions proposed there cover your use case? Otherwise, IMHO a wishlist bug against src:cryptsetup would be better than using a separate source package. > PIN-less is also supported, if the PINs are present in > /etc/cryptsetup/2fa.conf. I'm not really thrilled to see /etc/cryptsetup (and /lib/cryptsetup) used outside src:cryptsetup. These directories are not documented as drop-in. -- Guilhem. signature.asc Description: PGP signature
Bug#947431: xerces-c: CVE-2018-1311: use-after-free vulnerability processing external DTD
Hi, On Thu, 28 Dec 2023 at 13:28:53 -0500, de...@blough.us wrote: > Thanks for doing this. > > I don't have a lot of free time at the moment, so please feel free to NMU. Thanks for the fast reply! 3.2.4+debian-1.1 is now in trixie, you'll find the commits and tag at https://salsa.debian.org/lts-team/packages/xerces-c.git I also filed a MR to update your repository with that NMU: https://salsa.debian.org/bblough/xerces-c/-/merge_requests/3 Cheers, -- Guilhem. signature.asc Description: PGP signature
Bug#1059315: tinyxml: CVE-2023-34194 CVE-2023-40462 CVE-2023-40458
On Sat, 30 Dec 2023 at 21:02:16 +0100, Felix Geyer wrote: > There are some minor changes staged in the salsa git repo. It would be good > to include them as well. Feel free to push the patch to git and upload. > Alternatively a merge request works as well of course. Thanks for the fast response! Tagged and uploaded. Security team, if you agree with my assessment that CVE-2023-40462 is a duplicate of CVE-2023-34194 (but for a separate project that embeds libxml) and that CVE-2023-40458 is a duplicate of CVE-2021-42260 (but for a separate project that embeds libxml), I can propose debdiffs for bullseye and bookworm. -- Guilhem. signature.asc Description: PGP signature
Bug#1059315: tinyxml: CVE-2023-34194 CVE-2023-40462 CVE-2023-40458
Control: tag -1 + patch
Hi,
I had a look at these issues for Buster (LTS). Unfortunately the
upstream project appears to be inactive.
On Fri, 22 Dec 2023 at 14:50:57 +0100, Moritz Mühlenhoff wrote:
> CVE-2023-34194[0]:
> | StringEqual in TiXmlDeclaration::Parse in tinyxmlparser.cpp in
> | TinyXML through 2.6.2 has a reachable assertion (and application
> | exit) via a crafted XML document with a '\0' located after
> | whitespace.
I attach a patch for this. Felix, I can upload an NMU for sid if you'd
like.
> CVE-2023-40462[1]:
> | The ACEManager component of ALEOS 4.16 and earlier does not
> | perform input sanitization during authentication, which could
> | potentially result in a Denial of Service (DoS) condition for
> | ACEManager without impairing other router functions. ACEManager
> | recovers from the DoS condition by restarting within ten seconds of
> | becoming unavailable.
AFAICT this is identical to CVE-2023-34194, but for ALEOS' ACEManager:
“TinyXML has not been supported for some years, but ALEOS still embeds its
source code directly into one of its libraries (libSWIALEOS.so).
[…]
For ACEmanager, the bug can be triggered similarly to CVE-2023-40458, as
shown below in Figure 20. Unlike CVE-2023-40458, though, it crashes the
application, and since ACEmanager runs as a service, it will be
automatically restarted in a few seconds. However, attackers can keep
sending malformed XML documents, prolonging the DoS indefinitely. All
currently logged-in users are also immediately logged out. Attackers do
not need to be authenticated to exploit the issue.” [0]
> CVE-2023-40458[2]:
> | Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability
> | in Sierra Wireless, Inc ALEOS could potentially allow a remote
> | attacker to trigger a Denial of Service (DoS) condition for
> | ACEManager without impairing other router functions. This condition
> | is cleared by restarting the device.
AFAICT this issue is a duplicate of CVE-2021-42260. §9.4 of the
report[0] reads that CVE-2023-40458 is triggered by a malformed XML
document containing 0xef (TIXML_UTF_LEAD_0) followed (p+1 or p+2) by
0x00, which is exactly what CVE-2021-42260 is about.
https://sourceforge.net/p/tinyxml/git/merge-requests/1/ , which is
included in buster-security, bullseye, bookworm and sid, evade the
infinite loop by blindly advancing the pointer.
Cheers,
--
Guilhem.
[0] https://www.forescout.com/resources/sierra21-vulnerabilities
From: Guilhem Moulin
Date: Sat, 30 Dec 2023 14:15:54 +0100
Subject: Avoid reachable assertion via crafted XML document with a '\0'
located after whitespace
Bug: https://www.forescout.com/resources/sierra21-vulnerabilities
Bug-Debian: https://bugs.debian.org/1059315
Bug-Debian: https://security-tracker.debian.org/tracker/CVE-2023-34194
Bug-Debian: https://security-tracker.debian.org/tracker/CVE-2023-40462
---
tinyxmlparser.cpp | 4
1 file changed, 4 insertions(+)
diff --git a/tinyxmlparser.cpp b/tinyxmlparser.cpp
index 8aa0dfa..1601962 100644
--- a/tinyxmlparser.cpp
+++ b/tinyxmlparser.cpp
@@ -1606,6 +1606,10 @@ const char* TiXmlDeclaration::Parse( const char* p, TiXmlParsingData* data, TiXm
}
p = SkipWhiteSpace( p, _encoding );
+ if ( !p || !*p )
+ {
+ break;
+ }
if ( StringEqual( p, "version", true, _encoding ) )
{
TiXmlAttribute attrib;
signature.asc
Description: PGP signature
Bug#947431: xerces-c: CVE-2018-1311: use-after-free vulnerability processing external DTD
Hi, Upstream has now released 3.2.5 which fixes the issue https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12352411&styleName=Text&projectId=10510 The fix can be found at https://github.com/apache/xerces-c/pull/54 https://github.com/apache/xerces-c/commit/e0024267504188e42ace4dd9031d936786914835 I'll prepare an upload for buster (LTS) with the above. Bill, do you plan to upload 3.2.5 to sid soon? Otherwise I can offer an NMU with the upstream patch. Cheers, -- Guilhem. signature.asc Description: PGP signature
Bug#1058928: bookworm-pu: package cryptsetup/2:2.6.1-4~deb12u2
Control: tag -1 - moreinfo Hi, On Thu, 21 Dec 2023 at 21:59:40 +, Jonathan Wiltshire wrote: > On Mon, Dec 18, 2023 at 02:10:20PM +0100, Guilhem Moulin wrote: >> [ Reason ] >> >> 1. cryptsetup-suspend 2:2.6.1-4~deb12u1 was found incompatible with >> systemd 254.1-3 and later, in particular with systemd/bookworm-backports. >> >> 2. cryptsetup-initramfs 2:2.6.1-4~deb12u2 dos not support kernel >> shipping compressed modules under MODULES=dep, as is done by default >> with linux 6.6 (currently in Debian experimental). > > Aren't these problems better sorted out in the relevant suites, e.g. with > Breaks? It seems an unnecessary change in stable when stable isn't actually > broken. It's correct that stable isn't broken at the moment, but some users also build their own kernels, and we can't warn about the incompatibilty there; they just won't be able to boot when these 3 conditions are satisfied: 1. Linux is configured with CONFIG_MODULE_COMPRESS_* (Debian currently does that in experimental only but the setting is also available in <6.0); 2. initramfs.conf(5) sets MODULES=dep; and 3. There is a device to be unlocked at initramfs stage (for instance the root FS). Moreover the issue stands in the way of kernel maintainers enabling CONFIG_MODULE_COMPRESS_* in stable should that be needed or desired in some point release. (Compressed modules are already suported in Bookworm's initramfs-tools, but currently not in cryptsetup-initramfs.) The other issue I see with ‘Breaks: cryptsetup-initramfs (<< 2:2.6.1-6~)’ without having a recent enough cryptsetup-initramfs available is that apt will hapilly suggest to remove cryptsetup-initramfs. That too would yield an unbootable system whenever there is any device to be unlocked at initramfs stage. Note that the proposed change is a no-op with Bookworm's current kernel and systemd. It just adds forward compatibility in the same way initramfs-tools did. -- Guilhem. signature.asc Description: PGP signature
Bug#1058928: bookworm-pu: package cryptsetup/2:2.6.1-4~deb12u2
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: cryptse...@packages.debian.org
Control: affects -1 + src:cryptsetup
[ Reason ]
1. cryptsetup-suspend 2:2.6.1-4~deb12u1 was found incompatible with
systemd 254.1-3 and later, in particular with systemd/bookworm-backports.
2. cryptsetup-initramfs 2:2.6.1-4~deb12u2 dos not support kernel
shipping compressed modules under MODULES=dep, as is done by default
with linux 6.6 (currently in Debian experimental).
[ Impact ]
1. Users installing systemd from bookworm-backports will not be able to
use cryptsetup-suspend to suspend-on-ram.
2. Users installing linux ≥6.6.4-1~exp1 will not be able to boot under
MODULES=dep when there is any device to be unlocked at initramfs stage.
(initramfs.conf(5)'s defaults to MODULES=most, but not being able to
boot anymore is obviously a serious regression.)
[ Tests ]
DEP-8 check suspend-on-ram and initramfs unlocking for various setups,
all using stock bookworm packages. In addition, manual tests were made
to check behaviour with systemd/bookworm-backports and/or linux-image-amd64/
experimental.
[ Risks ]
The patches were backported from sid, where 2:2.6.1-5 resp. 2:2.6.1-6
was uploaded to on Aug 27 resp. Dec 05. The diff is pretty trivial and
doesn't affect libcryptsetup12 nor cryptsetup-bin.
[ 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 stable
[x] the issue is verified as fixed in unstable
[ Changes ]
* Also add compressed kernel modules in the initramfs hook script.
* Fix DEP-8 tests to work with compressed kernel modules.
* Don't error out when /lib/systemd/system-sleep does not exist (cf.
#1036920 and #1050606).
--
Guilhem.
diffstat for cryptsetup-2.6.1 cryptsetup-2.6.1
changelog | 18 ++
initramfs/hooks/cryptroot |4 ++--
salsa-ci.yml |1 +
scripts/suspend/cryptsetup-suspend-wrapper |1 +
tests/cryptroot-legacy.d/mock |2 +-
tests/utils/mkinitramfs|9 -
6 files changed, 27 insertions(+), 8 deletions(-)
diff -Nru cryptsetup-2.6.1/debian/changelog cryptsetup-2.6.1/debian/changelog
--- cryptsetup-2.6.1/debian/changelog 2023-04-21 00:54:29.0 +0200
+++ cryptsetup-2.6.1/debian/changelog 2023-12-18 03:41:04.0 +0100
@@ -1,3 +1,21 @@
+cryptsetup (2:2.6.1-4~deb12u2) bookworm; urgency=medium
+
+ [ Michael Biebl ]
+ * cryptsetup-suspend-wrapper: Don't error out on missing
+/lib/systemd/system-sleep directory as systemd 254.1-3 and later no longer
+ship empty directories. (Closes: #1050606)
+
+ [ Kevin Locke ]
+ * cryptsetup-initramfs: Add support for compressed kernel modules, which is
+the default as linux-image 6.6.4-1~exp1. (Closes: #1036049, #1057441)
+
+ [ Guilhem Moulin ]
+ * add_modules(): Change suffix drop logic to match initramfs-tools.
+ * Fix DEP-8 tests with kernels shipping compressed modules.
+ * d/salsa-ci.yml: Set RELEASE=bookworm.
+
+ -- Guilhem Moulin Mon, 18 Dec 2023 03:41:04 +0100
+
cryptsetup (2:2.6.1-4~deb12u1) bookworm; urgency=medium
* Rebuild for Bookworm.
diff -Nru cryptsetup-2.6.1/debian/initramfs/hooks/cryptroot
cryptsetup-2.6.1/debian/initramfs/hooks/cryptroot
--- cryptsetup-2.6.1/debian/initramfs/hooks/cryptroot 2023-04-21
00:54:29.0 +0200
+++ cryptsetup-2.6.1/debian/initramfs/hooks/cryptroot 2023-12-18
03:41:04.0 +0100
@@ -266,8 +266,8 @@
add_modules() {
local glob="$1" found=n
shift
-for mod in $(find -H "$@" -name "$glob.ko" -type f -printf '%f\n'); do
-manual_add_modules "${mod%.ko}"
+for mod in $(find -H "$@" -name "$glob.ko*" -type f -printf '%f\n'); do
+manual_add_modules "${mod%%.*}"
found=y
done
[ "$found" = y ] && return 0 || return 1
diff -Nru cryptsetup-2.6.1/debian/salsa-ci.yml
cryptsetup-2.6.1/debian/salsa-ci.yml
--- cryptsetup-2.6.1/debian/salsa-ci.yml2023-04-21 00:54:29.0
+0200
+++ cryptsetup-2.6.1/debian/salsa-ci.yml2023-12-18 03:41:04.0
+0100
@@ -3,6 +3,7 @@
-
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/recipes/debian.yml
variables:
+ RELEASE: 'bookworm'
# Skip all DEP-8 tests except 'cryptroot-lvm': each 'cryptroot-*' test
# takes 20-30min on Salsa CI runners as they don't support KVM acceleration
# cf. https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/266 ,
diff -Nru cryptsetup-2.6.1/debian/scripts/suspend/cryptsetup-suspend-wrapper
cryptsetup-2.6.1/debian/scripts/suspend/cryptsetup-suspend-wrapper
--- cryptsetup-2.6.1/debian/scripts/suspend/cryptsetup
Bug#1057849: [Pkg-roundcube-maintainers] Bug#1057849: roundcube-core: Can't open file /etc/roundcube/plugins/jqueryui/config.inc.php.dpkg-new
On Sun, 10 Dec 2023 at 19:05:05 +0100, Daniel Huhardeaux via Pkg-roundcube-maintainers wrote: > root@wwwmail11:/etc/roundcube# ls -l /etc/roundcube/plugins/jqueryui/ > total 20 > -rw-r--r-- 1 root root 1030 14 oct. 18:34 composer.json > -rw-r--r-- 1 root root 307 14 oct. 18:34 config.inc.php.dist > -rw-r--r-- 1 root root 5256 18 oct. 23:40 jqueryui.php > drwxr-xr-x 2 root root 4096 10 déc. 18:46 js > drwxr-xr-x 5 root root 46 6 nov. 2021 themes It looks like you tried to manually install the plugin from composer. 1.4.15+dfsg.1-1~deb11u2, and AFAIK all versions since at least 1.1, ship only /etc/roundcube/plugins/jqueryui/config.inc.php Please try to move the content of /etc/roundcube/plugins/jqueryui/ to a seperate location and try again. You might also want to recreate /etc/roundcube/plugins/jqueryui/config.inc.php: signature.asc Description: PGP signature
Bug#1057849: roundcube-core: Can't open file /etc/roundcube/plugins/jqueryui/config.inc.php.dpkg-new
Control: tag -1 moreinfo unreproducible Hi, On Sat, 09 Dec 2023 at 16:37:58 +0100, tootai via Pkg-roundcube-maintainers wrote: > -- Configuration Files: > /etc/roundcube/defaults.inc.php changed: Hmm I guess we shouldn't ship that file as a conffile, but since 1.4.1+dfsg.1-1 its header reads WARNING: Do not edit this file! Copy configuration to config.inc.php. Does replacing that file with the one shipped in the binary package (and applying your local changes to /etc/roundcube/config.inc.php) help in any way? I wonder if the configuration migration logic takes into accounts changes to defaults.inc.php. That said, there is not much difference between 1.4.15+dfsg.1-1~deb11u1 and ~deb11u2, and nothing related to maintenance scripts or jqueryui. Please provide the output of the following commands: $ readlink -e /etc/roundcube/plugins/jqueryui $ readlink -e /etc/roundcube/plugins/jqueryui/* $ ls -l /etc/roundcube/plugins/jqueryui/ > // -- > // SQL DATABASE > // -- > // Database connection string (DSN) for read+write operations > // Format (compatible with PEAR MDB2): > db_provider://user:password@host/database > // Currently supported db_providers: mysql, pgsql, sqlite, mssql or sqlsrv > // For examples see > http://pear.php.net/manual/en/package.database.mdb2.intro-dsn.php > // NOTE: for SQLite use absolute path: > 'sqlite:full/path/to/sqlite.db?mode=0646' > $config['db_dsnw'] = 'mysql://roundcube:4aKs6sT@localhost/roundcube'; If that's really your production password you'll probably want to change it. -- Guilhem. signature.asc Description: PGP signature
Bug#1056577: suspend-to-disk is broken after upgrade Debian 11 --> 12
Control: tag -1 moreinfo unreproducible On Thu, 23 Nov 2023 at 12:26:21 +0100, Harald Dunkel wrote: > If you upgrade your Laptop from Debian 11 to 12, then resume from an > encrypted swap partition is broken. There is a passphrase dialog at > boot time as usual, but the image on the swap partition is ignored. > Debian is started from scratch. I'm not able to reproduce this. Unfortunately with that little info this bug is not actionable. Please use reportbug(1) to include relevant information about your system and follow https://cryptsetup-team.pages.debian.net/cryptsetup/README.debug.html and https://wiki.debian.org/InitramfsDebug#Saving_debug_information to get a debug trace. > After installing the > > cryptsetup-suspend > > package this problem was gone While d/t/cryptroot-lvm checks both suspend-to-disk and suspend-to-ram, the test still works just fine after removing the latter and not installing cryptsetup-suspend. -- Guilhem. signature.asc Description: PGP signature
Bug#1057061: The service roundcube-cleandb should depend on mariadb.service
Control: tag -1 - wontfix On Thu, 30 Nov 2023 at 00:22:45 +0100, Guilhem Moulin wrote: > On Thu, 30 Nov 2023 at 00:13:44 +0100, Dmitry Katsubo wrote: >> For the subsequent calls I ma not sure – I've got an impression that >> this service is run only once at system startup. > > No, it's supposed to run once a day at 00:05 local time, see the > associated .timer unit. > > If the impact is only that the first run after a reboot or during a > RDBMS restart fails, then I don't think it's worth trying to fix the > race. The service might fail for various other reasons, but as long as > garbage doesn't pile up forever (i.e., as long as it doesn't *always* > fail) this is not an issue. Thinking more about it, the easiest and least disruptive solution would be to set ‘Persistent=false’ in the .timer units, after all there is no reason to clean the DB ASAP after boot. The old cron jobs wait until the next calendar occurrence, and it makes sense to align the .timer units on that behavior. The race condition is still present, but at least booting a system that's been down for a long while won't show any failure in the `systemctl status` output. -- Guilhem. signature.asc Description: PGP signature
Bug#1057061: The service roundcube-cleandb should depend on mariadb.service
On Thu, 30 Nov 2023 at 00:13:44 +0100, Dmitry Katsubo wrote: > For the subsequent calls I ma not sure – I've got an impression that > this service is run only once at system startup. No, it's supposed to run once a day at 00:05 local time, see the associated .timer unit. If the impact is only that the first run after a reboot or during a RDBMS restart fails, then I don't think it's worth trying to fix the race. The service might fail for various other reasons, but as long as garbage doesn't pile up forever (i.e., as long as it doesn't *always* fail) this is not an issue. -- Guilhem. signature.asc Description: PGP signature
Bug#1057061: The service roundcube-cleandb should depend on mariadb.service
On Wed, 29 Nov 2023 at 19:48:09 +0100, Dmitry Katsubo wrote: > After= is not the same as Requires= > If the service is not present, it is just noop. > You might wish to add all supported RDBMS into After=. One could also imagine systems where one (or more) of these .service files exists but isn't used by Roundcube. In that case it's not a noop. I'll need to check what other maintainer do. > Otherwise I have no good idea how to cure the error I got... making an > explicit delay? You can also add the After= relevant for your setup as a separate file override. What's the impact of this anyway? The race condition might cause the first run to fail but subsequent ones should succeed no? -- Guilhem. signature.asc Description: PGP signature
Bug#1033802: dropbear-initramfs: sleep and cat not found
On Wed, 29 Nov 2023 at 14:11:09 +0100, William Desportes wrote:
> I had put an interface name: ens9.123 thinking it would take the VLAN tag.
> But it triggered the crash. Removing the ".123" fixes it.
That's #1015287.
As written in msg#42 dropbear-initramfs doesn't configure the network by
itself; all it does is calling initramfs-tools' configure_networking().
And that function currently doesn't support VLAN tags, which is what
the aforementioned wishlist bug is about.
> That said, sleep and cat are still not into the initramfs image.
What makes you say that? What's the output of `lsinitramfs /initrd.img | grep
-e/{sleep,cat}`?
You still haven't replied whether setting DROPBEAR_SHUTDOWN_TIMEOUT=300
fixes this or not, and I still have reasons to believe it's the
(non-)issue described earlier in this bug.
--
Guilhem.
signature.asc
Description: PGP signature
Bug#1057061: The service roundcube-cleandb should depend on mariadb.service
Control: tag -1 moreinfo On Wed, 29 Nov 2023 at 01:14:27 +0100, Dmitry Katsubo via Pkg-roundcube-maintainers wrote: > The service roundcube-cleandb should be run after MySQL/MariaDB is started: > > === file /lib/systemd/system/roundcube-cleandb.service === > > [Unit] > After=mariadb.service > > === end === I don't think it's that simple: MariaDB is only one of several supported RDBMS, and the server might be on a different system. -- Guilhem. signature.asc Description: PGP signature
Bug#1056274: reportbug: dropbear-initramfs makes initramfs non-reproducible due to randomly generated /root-XXXXXXX directory
On Mon, 20 Nov 2023 at 11:24:00 +0100, Yannik Sembritzki wrote: > I just had a look at your patch. I think it's the right idea to rather use > what is already there, instead of always creating our own stuff/overwriting > existing /etc/passwd and /etc/nsswitch. > > Thank you! You're welcome :-) > There is only one thing I don't understand: > The patch still uses a random /root-X if a root directory doesn't exist > yet. (As is the case with default initramfs-tools) > I understand that I can fix that with the custom hook, but why not just make > this deterministic by default? > Right now, this creates an extra hurdle for users to find what is breaking > the reproducability, understand the dropbear hook (or find this bug) and > create the custom hook. > Is this really necessary? I'm not keen to use a name containing ‘dropbear’ since ~root doesn't belong to src:dropbear, and creating a generic name has a risk of collision with hooks from other packages (and/or custom hooks). Furthermore, using a deterministic name now with the option to change later might cause trouble to people hardcoding the name (not something recommended of course, but people do that anyway). IMHO the remaining part of the fix belongs to initramfs-tools. If the maintainers want to take care of setting up the root user and its homedir we'll remove the fallback in dropbear-initramfs and just tighten the version number of its dependency. -- Guilhem. signature.asc Description: PGP signature
Bug#1056274: reportbug: dropbear-initramfs makes initramfs non-reproducible due to randomly generated /root-XXXXXXX directory
On Mon, 20 Nov 2023 at 10:42:30 +0100, Yannik Sembritzki wrote:
> Would you be open to a two step approach like this:
>
> 1. fix the reproducibility bug
> 2. improve the root directory creation process (I can create another bug to
> track this)
Just pushed
https://salsa.debian.org/debian/dropbear/-/commit/1c709e951d97a132a9d4f3de4b9cc406a83e0b64
,
~root will now be reused if the root user is already set up. Ideally
the latter should be done by initramfs-tools itself, but in the meantime
copyping the enclosed hook into /usr/share/initramfs-tools/hooks should
solve the issue (once 2022.83-3 lands in sid).
--
Guilhem.
#!/bin/sh
PREREQ=""
prereqs() {
echo "$PREREQ"
}
case "$1" in
prereqs)
prereqs
exit 0
;;
esac
. /usr/share/initramfs-tools/hook-functions
home="/rootuser"
echo "root:*:0:0::$home:/bin/sh" >"$DESTDIR/etc/passwd"
mkdir -m0700 "$DESTDIR$home"
signature.asc
Description: PGP signature
Bug#1056274: reportbug: dropbear-initramfs makes initramfs non-reproducible due to randomly generated /root-XXXXXXX directory
Control: retitle -1 dropbear-initramfs makes initramfs non-reproducible Control: severity -1 wishlist Control: tag -1 - patch Hi, On Sun, 19 Nov 2023 at 15:45:22 +0100, Yannik Sembritzki wrote: > One solution would be to simply always use /root-dropbear-initramfs. I'm not in favour of that solution, as ~root doesn't belong to dropbear-initramfs. I think it would be best if the root user and its homedir were created by initramfs-tools itself; failing that it could be created by another directory hook outside src:dropbear (possibly your own custom hook), and dropbear-initramfs's hook could use that. -- Guilhem. signature.asc Description: PGP signature
Bug#1055489: roundcube-plugins: File 'opengpg.js.min' for the 'enigma' plugin is missing
Control: tag -1 wontfix Hi, On Tue, 07 Nov 2023 at 10:38:49 +0100, Marco Emilio Poleggi wrote: > It looks like the file 'opengpg.js.min' for the 'enigma' plugin is > missing. This is intentional, see roundcube-plugins.NEWS: https://salsa.debian.org/roundcube-team/roundcube/-/blob/debian/latest/debian/roundcube-plugins.NEWS -- Guilhem. signature.asc Description: PGP signature
Bug#1055421: roundcube: cross-site scripting (XSS) vulnerability in setting Content-Type/Content-Disposition for attachment preview/download
Source: roundcube Version: 1.6.4+dfsg-1 Severity: important Control: found -1 1.6.4+dfsg-1~deb12u1 Tags: security upstream Roundcube webmail upstream has recently released 1.6.5 which fixes the following vulnerability: * Fix cross-site scripting (XSS) vulnerability in setting Content-Type/Content-Disposition for attachment preview/download. https://github.com/roundcube/roundcubemail/commit/81ac3c342a4f288deb275590895b52ec3785cf8a AFAICT no CVE-ID has been published for this issue. -- Guilhem. signature.asc Description: PGP signature
Bug#1054079: roundcube: cross-site scripting (XSS) vulnerability in handling of SVG in HTML messages
Source: roundcube Version: 1.6.3+dfsg-2 Severity: important Tags: security upstream Control: found -1 1.3.17+dfsg.1-1~deb10u3 Control: found -1 1.4.14+dfsg.1-1~deb11u1 Control: found -1 1.6.3+dfsg-1~deb12u1 Control: forwarded -1 https://github.com/roundcube/roundcubemail/issues/9168 In a recent post roundcube webmail upstream has announced the following security fix: * Fix cross-site scripting (XSS) vulnerability in handling of SVG in HTML messages. AFAICT no CVE ID has been assigned or requested yet, so I'll file a request to that effect. Upstream fixes for stable and LTS branches: 1.6.x https://github.com/roundcube/roundcubemail/commit/41756cc3331b495cc0b71886984474dc529dd31d 1.4.x https://github.com/roundcube/roundcubemail/commit/7b2df52ede57bab9e87e9c3bc00601eeca591a5e https://github.com/roundcube/roundcubemail/commit/dc7b6850c68870570b438d79c0949a5031522127 1.3.x is no longer supported upstream but AFAICT affected nonetheless. -- Guilhem. signature.asc Description: PGP signature
Bug#1052629: bookworm-pu: package roundcube/1.6.3+dfsg-1~deb12u1
On Thu, 28 Sep 2023 at 18:53:46 +0100, Adam D. Barratt wrote: > --- a/CHANGELOG.md > +++ b/CHANGELOG.md > @@ -1,5 +1,54 @@ > # Changelog Roundcube Webmail > > +## Unreleased > + > > That seems wrong, given that you're uploading a released version. Well spotted but that one is upstream's, see https://github.com/roundcube/roundcubemail/blob/1.6.3/CHANGELOG.md :-) (Also there also a few occurrences of “Version 1.6-git” in that release, upstream probably forgot to run the pre-release script.) > Please go ahead. Thanks! -- Guilhem. signature.asc Description: PGP signature
Bug#1052059: bookworm-pu?
On Thu, 28 Sep 2023 at 18:26:07 +0300, Martin Dosch via Pkg-roundcube-maintainers wrote: > Are there plans to also upload it to stable-pu? See #1052629 -- Guilhem.
Bug#1052611: bullseye-pu: package roundcube/1.4.14+dfsg.1-1~deb11u1
gelog2023-09-25 11:32:59.0
+0200
@@ -1,3 +1,14 @@
+roundcube (1.4.14+dfsg.1-1~deb11u1) bullseye; urgency=high
+
+ * New security/bugfix upstream release:
++ Fix CVE-2023-43770: cross-site scripting (XSS) vulnerability in handling
+ of linkrefs in plain text messages. (Closes: #1052059)
++ Enigma: Fix initial synchronization of private keys.
+ * d/u/signing-key.asc: Add Alec's key BEE674A019359DC1.
+ * Refresh d/patches.
+
+ -- Guilhem Moulin Mon, 25 Sep 2023 11:32:59 +0200
+
roundcube (1.4.13+dfsg.1-1~deb11u1) bullseye-security; urgency=high
* New security upstream release, with fix for CVE-2021-46144: XSS
diff -Nru
roundcube-1.4.13+dfsg.1/debian/patches/fix-FTBFS-with-phpunit-8.5.13-1.patch
roundcube-1.4.14+dfsg.1/debian/patches/fix-FTBFS-with-phpunit-8.5.13-1.patch
---
roundcube-1.4.13+dfsg.1/debian/patches/fix-FTBFS-with-phpunit-8.5.13-1.patch
2022-01-06 08:51:41.0 +0100
+++
roundcube-1.4.14+dfsg.1/debian/patches/fix-FTBFS-with-phpunit-8.5.13-1.patch
2023-09-25 11:32:59.0 +0200
@@ -1335,7 +1335,7 @@
/**
diff --git a/tests/Framework/StringReplacer.php
b/tests/Framework/StringReplacer.php
-index ace8bf6..9d56fe2 100644
+index 16dff6a..756eddd 100644
--- a/tests/Framework/StringReplacer.php
+++ b/tests/Framework/StringReplacer.php
@@ -5,7 +5,7 @@
@@ -1348,7 +1348,7 @@
/**
diff --git a/tests/Framework/Text2Html.php b/tests/Framework/Text2Html.php
-index db2dbac..273eeed 100644
+index 1d6ffd2..8f86b86 100644
--- a/tests/Framework/Text2Html.php
+++ b/tests/Framework/Text2Html.php
@@ -5,7 +5,7 @@
diff -Nru
roundcube-1.4.13+dfsg.1/debian/patches/fix-FTBFS-with-phpunit-9.5.0-1.patch
roundcube-1.4.14+dfsg.1/debian/patches/fix-FTBFS-with-phpunit-9.5.0-1.patch
--- roundcube-1.4.13+dfsg.1/debian/patches/fix-FTBFS-with-phpunit-9.5.0-1.patch
2022-01-06 08:51:41.0 +0100
+++ roundcube-1.4.14+dfsg.1/debian/patches/fix-FTBFS-with-phpunit-9.5.0-1.patch
2023-09-25 11:32:59.0 +0200
@@ -52,19 +52,19 @@
function test_links()
diff --git a/tests/Framework/StringReplacer.php
b/tests/Framework/StringReplacer.php
-index 9d56fe2..d60cbd0 100644
+index 756eddd..32ce877 100644
--- a/tests/Framework/StringReplacer.php
+++ b/tests/Framework/StringReplacer.php
-@@ -75,8 +75,8 @@ class Framework_StringReplacer extends
\PHPUnit\Framework\TestCase
+@@ -77,8 +77,8 @@ class Framework_StringReplacer extends
\PHPUnit\Framework\TestCase
$result = $replacer->replace($input);
$result = $replacer->resolve($result);
-$this->assertContains('[http://en.wikipedia.org/wiki/Email";>1] to', $result, "Numeric linkref
replacements");
-$this->assertContains('[http://www.link-ref.com";>ref0]
repl', $result, "Alphanum linkref replacements");
--$this->assertContains('of [Roundcube].', $result, "Don't touch
strings wihtout an index entry");
+-$this->assertContains('of [Roundcube].[ref<0]', $result, "Don't touch
strings wihtout an index entry");
+$this->assertStringContainsString('[http://en.wikipedia.org/wiki/Email";>1] to', $result, "Numeric linkref
replacements");
+$this->assertStringContainsString('[http://www.link-ref.com";>ref0] repl', $result, "Alphanum linkref
replacements");
-+$this->assertStringContainsString('of [Roundcube].', $result, "Don't
touch strings wihtout an index entry");
++$this->assertStringContainsString('of [Roundcube].[ref<0]', $result,
"Don't touch strings wihtout an index entry");
}
}
diff --git a/tests/Framework/Utils.php b/tests/Framework/Utils.php
diff -Nru roundcube-1.4.13+dfsg.1/debian/patches/fix-install-path.patch
roundcube-1.4.14+dfsg.1/debian/patches/fix-install-path.patch
--- roundcube-1.4.13+dfsg.1/debian/patches/fix-install-path.patch
2022-01-06 08:51:41.0 +0100
+++ roundcube-1.4.14+dfsg.1/debian/patches/fix-install-path.patch
2023-09-25 11:32:59.0 +0200
@@ -161,10 +161,10 @@
require_once INSTALL_PATH . 'program/include/clisetup.php';
diff --git a/program/include/iniset.php b/program/include/iniset.php
-index 1f8bfd7..a26900e 100644
+index d9388db..11142d2 100644
--- a/program/include/iniset.php
+++ b/program/include/iniset.php
-@@ -28,7 +28,7 @@ define('RCMAIL_VERSION', '1.4.13');
+@@ -28,7 +28,7 @@ define('RCMAIL_VERSION', '1.4.14');
define('RCMAIL_START', microtime(true));
if (!defined('INSTALL_PATH')) {
diff -Nru
roundcube-1.4.13+dfsg.1/debian/patches/hint-at-which-packages-needs-installing-under-PHP8.patch
roundcube-1.4.14+dfsg.1/debian/patches/hint-at-which-packages-needs-installing-under-PHP8.patch
---
roundcube-1
Bug#1052547: unable to boot, no luks passwort prompt shown
Control: tag -1 + moreinfo unreproducible Hi, On Sun, 24 Sep 2023 at 14:42:27 +0200, Eduard Bloch wrote: > we have a problem here. After latest upgrades, I am no longer able to > boot into a system with LUKS-encrypted rootfs. This worked just fine a few > weeks ago. I jumped in circles in the search for the cause, and only > after downgrading cryptsetup-initramfs to 2:2.6.1-4 it suddenly started > working again. I don't see how downgrading cryptsetup-initramfs from 2:2.6.1-5 to 2:2.6.1-4 could solve this: https://salsa.debian.org/cryptsetup-team/cryptsetup/-/compare/debian%2F2%252.6.1-4...debian%2F2%252.6.1-5?from_project_id=21364&straight=false Anyway, this bug is not actionable with so little information. Please provide a debug trace per https://cryptsetup-team.pages.debian.net/cryptsetup/README.debug.html#debug-cryptroot-initramfs-script cheers -- Guilhem. signature.asc Description: PGP signature
Bug#1052059: roundcube: Please apply security fix from 1.6.3
On Fri, 22 Sep 2023 at 10:56:59 +0300, Guilhem Moulin wrote:
> I'll suggest debdiffs targetting {bullseye,bookworm}-security after
> the week-end.
Oh, didn't see the Security Team tagged this as no-dsa. Will target
{bullseye,bookworm} then.
--
Guilhem.
signature.asc
Description: PGP signature
Bug#1052059: roundcube: Please apply security fix from 1.6.3
Control: retitle -1 roundcube: CVE-2023-43770: XSS vulnerability in handling of
linkrefs in plain text messages
On Mon, 18 Sep 2023 at 13:59:47 +0200, Guilhem Moulin wrote:
> I requested a CVE ID for this issue.
CVE-2023-43770 for this. I'll suggest debdiffs targetting {bullseye,bookworm}-
security after the week-end.
--
Guilhem.
signature.asc
Description: PGP signature
Bug#1052238: [pkg-php-pear] Bug#1052238: php-net-smtp: Please, consider this email address
On Thu, 21 Sep 2023 at 13:58:18 +0200, J.L. Fernandez Jambrina wrote: > Unfortunatelly I don't know how to use setDebug() to see what's is > being passed to send() Please see https://github.com/pear/Net_SMTP#debugging to debug Net_SMTP. > but I used two calls to var_dump() to see it: AFAICT this show what's being passed to Mail_Mime or Mail, not Net_SMTP. Net_SMTP treats data as as opaque string containing both the header and body parts, just like the SMTP protocol itself. -- Guilhem. signature.asc Description: PGP signature
Bug#1052290: cryptsetup-initramfs: askpass is not executed; cryptroot-unlock fails
Control: tag -1 moreinfo On Tue, 19 Sep 2023 at 22:39:40 +0100, Tj wrote: > On reaching initialramfs it fails to unlock either of the LUKS devices; > eventually dropping to the shell after reporting: > > Error: Timeout reached while waiting for askpass. > > After using `break=mount` and investigating with `sh -x > /bin/cryptsetup-unlock` it seems it fails because it is not finding > `askpass` in the process list. cryptsetup-unlock waits until the initramfs boot script is blocking on passphrase prompt. This is only useful for injecting passphrases from outside the initramfs console (for instance from a remote shell). When you set ‘break=mount’ our boot script isn't running in the background, so cryptsetup-unlock timeouts. This is expected. Why are you running cryptsetup-unlock in the first place instead of relying on the builtin initramfs logic? Also, FWIW ‘break=mount’ breaks *after* unlocking whatever block devices need to be unlocked, so cryptsetup-initramfs has nothing more to do at this point. -- Guilhem. signature.asc Description: PGP signature
