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.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#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.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 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/mkj/dr
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_initialise
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
+$ cmake -G "U
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=Text=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-suspend-wrapper
2023-04-21 00:54:29.0 +0200
+++ cryptsetup-2.6.1
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
023-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.4.13+dfsg.1/debian/patches/hint-at-which-packages-needs-installing-under-PHP8.patch
2022-01-06 08:51:41.0 +0100
+++
roundcube-1.4.14+dfsg.1/debian/patches/hint-at-which-packages-needs-installing-und
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=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
Bug#1052238: php-net-smtp: fails to send MIME multipart email properly
Control: tag -1 moreinfo Hi, On Tue, 19 Sep 2023 at 12:42:34 +0200, J.L. Fernandez Jambrina wrote: > As php-mail didn't change in the upgrade and I verified the arguments > to the MAIL::send method are the same in both cases I suspect from the > underlying php-net-smtp package, but I can be wrong. php-net-smtp treats the SMTP DATA as an opaque string, please use setDebug() to see what's being passed to send(). -- Guilhem. signature.asc Description: PGP signature
Bug#1052156: cryptsetup: please (temporarily) disable cryptroot-sysvinit autopkgtest
Control: tag -1 moreinfo Hi, On Mon, 18 Sep 2023 at 10:46:30 +0100, Luca Boccassi wrote: > With sysvinit scripts no longer being mandatory, the udev one has been > removed from src:systemd. It is in the process of being adopted by > src:sysvinit, but being optional and all that might take some time yet. > > Cryptsetup has a sysvinit autopkgtest that no longer works due to this, > could you please disable it so that src:systemd can migrate? Given https://tracker.debian.org/news/1464127/accepted-sysvinit-308-1-source-into-unstable/ I suppose this is no longer necessary? At least our cryptroot-sysvinit autopkgtest passes with sysv-rc=3.08-1 and udev=254.3-1. -- Guilhem. signature.asc Description: PGP signature
Bug#1052059: roundcube: Please apply security fix from 1.6.3
I requested a CVE ID for this issue. -- Guilhem. signature.asc Description: PGP signature
Bug#1050680: yubikey-luks: Depends on removed package cryptsetup-run
On Mon, 28 Aug 2023 at 01:56:04 +0200, Guilhem Moulin wrote:
> cryptsetup-run has been a transitional package since the buster release,
> and has now been removed following #1038285. Looks like I failed to
> properly check reverse depends; yubikey-luks should replace ‘Depends:
> cryptsetup-run’ with ‘Depends: cryptsetup’.
Uploaded the attached debdiff to DELAYED/7.
--
Guilhem.
diffstat for yubikey-luks-0.5.1+29.g5df2b95 yubikey-luks-0.5.1+29.g5df2b95
changelog |8
control |2 +-
2 files changed, 9 insertions(+), 1 deletion(-)
diff -Nru yubikey-luks-0.5.1+29.g5df2b95/debian/changelog
yubikey-luks-0.5.1+29.g5df2b95/debian/changelog
--- yubikey-luks-0.5.1+29.g5df2b95/debian/changelog 2022-10-15
12:58:53.0 +0200
+++ yubikey-luks-0.5.1+29.g5df2b95/debian/changelog 2023-08-28
01:59:49.0 +0200
@@ -1,3 +1,11 @@
+yubikey-luks (0.5.1+29.g5df2b95-6.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Replace ‘Depends: cryptsetup-run’ with ‘Depends: cryptsetup’ as
+src:cryptsetup no longer ships the former (Closes: #1050680)
+
+ -- Guilhem Moulin Mon, 28 Aug 2023 01:59:49 +0200
+
yubikey-luks (0.5.1+29.g5df2b95-6.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru yubikey-luks-0.5.1+29.g5df2b95/debian/control
yubikey-luks-0.5.1+29.g5df2b95/debian/control
--- yubikey-luks-0.5.1+29.g5df2b95/debian/control 2021-01-02
17:38:35.0 +0100
+++ yubikey-luks-0.5.1+29.g5df2b95/debian/control 2023-08-28
01:59:43.0 +0200
@@ -13,7 +13,7 @@
Package: yubikey-luks
Architecture: all
-Depends: cryptsetup-run, initramfs-tools, yubikey-personalization (>= 1.5),
${misc:Depends}
+Depends: cryptsetup, initramfs-tools, yubikey-personalization (>= 1.5),
${misc:Depends}
Recommends: cryptsetup-initramfs, expect
Description: YubiKey two factor authentication for LUKS disks
With this extension to the initramfs-tools, you can unlock a LUKS encrypted
signature.asc
Description: PGP signature
Bug#1050680: yubikey-luks: Depends on removed package cryptsetup-run
Source: yubikey-luks Version: 0.5.1+29.g5df2b95-6.1 Severity: serious Hi, cryptsetup-run has been a transitional package since the buster release, and has now been removed following #1038285. Looks like I failed to properly check reverse depends; yubikey-luks should replace ‘Depends: cryptsetup-run’ with ‘Depends: cryptsetup’. Cheers, -- Guilhem. signature.asc Description: PGP signature
Bug#1040705: Call to undefined function GuzzleHttp\json_decode()
Control: tag -1 pending On Sun, 09 Jul 2023 at 13:13:55 -0400, David Mandelberg via Pkg-roundcube-maintainers wrote: > I tried setting up oauth2 in roundcube, but when the OIDC provider redirects > back to roundcube, I get an "Oops... something went wrong!" page. When that > happens, /var/log/roundcube/errors.log shows: > > [09-Jul-2023 17:00:49 UTC] PHP Fatal error: Uncaught Error: Call to > undefined function GuzzleHttp\json_decode() in > /usr/share/roundcube/program/include/rcmail_oauth.php:237 It's unfortunate that tests/Rcmail/Oauth.php doesn't cover this :-( I think https://salsa.debian.org/roundcube-team/roundcube/-/commit/3f5fd4677abdf25224a2c05047a5a9d7490cf159 (more precisely the part that patches program/include/rcmail_oauth.php) fixes the issue. -- Guilhem. signature.asc Description: PGP signature
Bug#1043395: roundcube-core: Cron job triggers gc.sh 60 times
Control: tag -1 pending Control: found -1 1.6.1+dfsg-1 On Thu, 10 Aug 2023 at 07:46:40 +0300, Antti Kultanen via Pkg-roundcube-maintainers wrote: > in the crontab file /etc/cron.d/roundcube-core file the garbage collector > is set run 60 times, or every minute from 5:00 to 5:59. > […] > Is there a reason for this or is it just a typo? Thanks for the report! It was a mistake indeed, fixed at https://salsa.debian.org/roundcube-team/roundcube/-/commit/851a1cd0894b95d431170d5604c449dd5d9228ea . -- Guilhem. signature.asc Description: PGP signature
Bug#1041976: pandoc: CVE-2023-35936
On Tue, 25 Jul 2023 at 14:39:29 +0200, Jonas Smedegaard wrote: > I have no objections at all - on the contrary: Thanks! > > I will have a look at applying the patch to trixie, then - since there > is unfortunately little hope that the whole Haskell stack will get > upgrading any time soon, so wi can have a more modern Pandoc. Thanks for the quick fix! Filed #1042057 resp. #1042058 for 2.9.2.1-1+deb11u1 resp. 2.17.1.1-2~deb12u1. You'll find the branches and tags at https://salsa.debian.org/lts-team/packages/pandoc.git . -- Guilhem. signature.asc Description: PGP signature
Bug#1042058: bookworm-pu: package pandoc/2.17.1.1-2~deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: pan...@packages.debian.org, Guilhem Moulin Control: affects -1 + src:pandoc [ Reason ] pandoc 2.17.1.1-1.1 is vulnerable to CVE-2023-35936: Arbitrary file write vulnerability via specially crafted image element in the input when generating files using the `--extract-media` option or outputting to PDF format. The Security Team decided not to issue a DSA for that CVE, but it's now fixed in buster-security (2.2.1-3+deb10u1) as well as sid (2.17.1.1-2), so it makes sense to fix it via (o)s-pu too. [ Impact ] For users uprading from buster-security to bookworm, that would be a security regression. [ Tests ] A new unit test was added upstream, and backported along with the code fixes. I also manually verified that the PoC were fixed. [ Risks ] Regression risks are low: all upstream commits applied cleanly, and test coverage is good. (Upstream changes to pandoc.cabal are a no-op as far as debian packaging is concerned.) [ 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 ] * Add d/salsa-ci.yml for Salsa CI. * Fix CVE-2023-35936 and CVE-2023-38745: Arbitrary file write vulnerability via specially crafted image element in the input when generating files using the `--extract-media` option or outputting to PDF format. (Closes: #1041976) -- Guilhem. diffstat for pandoc-2.17.1.1 pandoc-2.17.1.1 changelog | 17 + copyright_hints |6 + patches/020230620~5e381e3.patch | 116 ++ patches/020230623.1~54561e9.patch | 24 +++ patches/020230623.2~df4f13b.patch | 85 +++ patches/020230623.3~fe62da6.patch | 87 patches/020230623.4~5246f02.patch | 52 + patches/020230720~eddedbf.patch | 90 + patches/series|6 + salsa-ci.yml |9 ++ 10 files changed, 492 insertions(+) diff -Nru pandoc-2.17.1.1/debian/changelog pandoc-2.17.1.1/debian/changelog --- pandoc-2.17.1.1/debian/changelog2022-11-19 14:13:51.0 +0100 +++ pandoc-2.17.1.1/debian/changelog2023-07-25 23:01:50.0 +0200 @@ -1,3 +1,20 @@ +pandoc (2.17.1.1-2~deb12u1) bookworm; urgency=high + + * Non-maintainer upload. + * Rebuild for bookworm. + * Add d/salsa-ci.yml for Salsa CI. + + -- Guilhem Moulin Tue, 25 Jul 2023 23:01:50 +0200 + +pandoc (2.17.1.1-2) unstable; urgency=high + + * add patches cherry-picked upstream +to fix arbitrary file write vulnerability; +closes: bug#1041976, thanks to Guilhem Moulin; +CVE-2023-35936 CVE-2023-35936 + + -- Jonas Smedegaard Tue, 25 Jul 2023 18:43:57 +0200 + pandoc (2.17.1.1-1.1) unstable; urgency=low * Non-maintainer upload. diff -Nru pandoc-2.17.1.1/debian/copyright_hints pandoc-2.17.1.1/debian/copyright_hints --- pandoc-2.17.1.1/debian/copyright_hints 2022-08-13 16:27:42.0 +0200 +++ pandoc-2.17.1.1/debian/copyright_hints 2023-07-25 23:01:50.0 +0200 @@ -236,6 +236,12 @@ debian/pandoc.lintian-overrides debian/patches/020220218~2a70d9c.patch debian/patches/020220531~9aff861.patch + debian/patches/020230620~5e381e3.patch + debian/patches/020230623.1~54561e9.patch + debian/patches/020230623.2~df4f13b.patch + debian/patches/020230623.3~fe62da6.patch + debian/patches/020230623.4~5246f02.patch + debian/patches/020230720~eddedbf.patch debian/patches/series debian/rules debian/source/format diff -Nru pandoc-2.17.1.1/debian/patches/020230620~5e381e3.patch pandoc-2.17.1.1/debian/patches/020230620~5e381e3.patch --- pandoc-2.17.1.1/debian/patches/020230620~5e381e3.patch 1970-01-01 01:00:00.0 +0100 +++ pandoc-2.17.1.1/debian/patches/020230620~5e381e3.patch 2023-07-25 23:01:50.0 +0200 @@ -0,0 +1,116 @@ +Description: fix a security vulnerability in MediaBag and T.P.Class.IO.writeMedia + This vulnerability, discovered by Entroy C, + allows users to write arbitrary files to any location + by feeding pandoc a specially crafted URL in an image element. + The vulnerability is serious + for anyone using pandoc to process untrusted input. + The vulnerability does not affect pandoc + when run with the `--sandbox` flag. +Origin: upstream, https://github.com/jgm/pandoc/commit/5e381e3 +Author: John MacFarlane +Bug: https://github.com/jgm/pandoc/security/advisories/GHSA-xj5q-fv23-575g +Bug-Debian: https://security-tracker.debian.org/tracker/CVE-2023-35936 +Forwarded: yes +Last-Update: 2023-07-25 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +--- a/src/Text/Pandoc/Class/IO.hs b/src/Text/Pandoc/Class/IO.hs +@@ -49,7 +49,7 @@ + import
Bug#1042057: bullseye-pu: package pandoc/2.9.2.1-1+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: pan...@packages.debian.org, Guilhem Moulin Control: affects -1 + src:pandoc [ Reason ] pandoc 2.9.2.1-1 is vulnerable to CVE-2023-35936: Arbitrary file write vulnerability via specially crafted image element in the input when generating files using the `--extract-media` option or outputting to PDF format. The Security Team decided not to issue a DSA for that CVE, but it's now fixed in buster-security (2.2.1-3+deb10u1) as well as sid (2.17.1.1-2), so it makes sense to fix it via (o)s-pu too. [ Impact ] For users uprading from buster-security to bullseye, that would be a security regression. [ Tests ] A new unit test was added upstream, and backported along with the code fixes. The test suite is now run at build time (this was not the case before due to #1010179 — in fact some unit tests had to be updated for the suite to pass). I also manually verified that the PoC were fixed. [ Risks ] The upstream fixes were not trivial to backport due to major refactoring, but test coverage is good. (Upstream changes to pandoc.cabal are a no-op as far as debian packaging is concerned.) [ 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 ] * Add d/salsa-ci.yml for Salsa CI. * Fix upstream test suite and make sure it is run at build time (cf. #1010179). * Fix CVE-2023-35936 and CVE-2023-38745: Arbitrary file write vulnerability via specially crafted image element in the input when generating files using the `--extract-media` option or outputting to PDF format. (Closes: #1041976) -- Guilhem. diffstat for pandoc-2.9.2.1 pandoc-2.9.2.1 changelog | 13 + patches/2001_templates_avoid_privacy_breach.patch | 72 ++- patches/Adjust-tests.patch| 133 patches/CVE-2023-35936.patch | 144 ++ patches/CVE-2023-38745.patch | 92 ++ patches/series|3 rules |2 salsa-ci.yml |8 + 8 files changed, 462 insertions(+), 5 deletions(-) diff -Nru pandoc-2.9.2.1/debian/changelog pandoc-2.9.2.1/debian/changelog --- pandoc-2.9.2.1/debian/changelog 2020-08-23 10:24:33.0 +0200 +++ pandoc-2.9.2.1/debian/changelog 2023-07-21 19:59:53.0 +0200 @@ -1,3 +1,16 @@ +pandoc (2.9.2.1-1+deb11u1) bullseye; urgency=high + + * Non-maintainer upload. + * Add d/salsa-ci.yml for Salsa CI. + * Fix upstream test suite and make sure it is run at build time (cf. +#1010179). + * Fix CVE-2023-35936 and CVE-2023-38745: Arbitrary file write vulnerability +via specially crafted image element in the input when generating files +using the `--extract-media` option or outputting to PDF format. (Closes: +#1041976) + + -- Guilhem Moulin Fri, 21 Jul 2023 19:59:53 +0200 + pandoc (2.9.2.1-1) unstable; urgency=medium [ upstream ] diff -Nru pandoc-2.9.2.1/debian/patches/2001_templates_avoid_privacy_breach.patch pandoc-2.9.2.1/debian/patches/2001_templates_avoid_privacy_breach.patch --- pandoc-2.9.2.1/debian/patches/2001_templates_avoid_privacy_breach.patch 2020-08-23 09:39:53.0 +0200 +++ pandoc-2.9.2.1/debian/patches/2001_templates_avoid_privacy_breach.patch 2023-07-21 19:59:53.0 +0200 @@ -1,9 +1,12 @@ Description: Avoid potential privacy breaches in templates Author: Jonas Smedegaard License: GPL-3+ -Last-Update: 2018-06-12 +Last-Update: 2023-07-21 --- This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ + +diff --git a/data/dzslides/template.html b/data/dzslides/template.html +index 56ef896..c3c4c9e 100644 --- a/data/dzslides/template.html +++ b/data/dzslides/template.html @@ -48,7 +48,7 @@ @@ -42,9 +45,11 @@ font-size: 30px; } +diff --git a/data/templates/default.dzslides b/data/templates/default.dzslides +index 11103ab..21bb8fa 100644 --- a/data/templates/default.dzslides +++ b/data/templates/default.dzslides -@@ -20,15 +20,12 @@ +@@ -20,15 +20,12 @@ $for(css)$ $endfor$ $else$ @@ -61,9 +66,11 @@ font-size: 30px; } +diff --git a/data/templates/default.html5 b/data/templates/default.html5 +index 0676215..724cde4 100644 --- a/data/templates/default.html5 +++ b/data/templates/default.html5 -@@ -23,9 +23,6 @@ +@@ -23,9 +23,6 @@ $endfor$ $if(math)$ $math$ $endif$ @@ -73,9 +80,11 @@ $for(header-includes)$ $header-includes$ $endfor$ +diff --git a/src/Text/Pandoc/Options.hs b/src/Text/Pandoc/Options.hs +index fde8a9a..c40c3ec 100644 --- a/src/Text/Pandoc/Options.hs +++ b/src/Text/Pandoc
Bug#1041976: pandoc: CVE-2023-35936
Package: pandoc Version: 2.17.1.1-1.1 Severity: important Tags: security upstream patch Control: found -1 2.2.1-3 Control: found -1 2.9.2.1-1 X-Debbugs-Cc: guil...@debian.org Hi, The following vulnerability was published for pandoc. CVE-2023-35936[0]: | Starting in version 1.13 and prior to version 3.1.4, Pandoc is | susceptible to an arbitrary file write vulnerability, which can be | triggered by providing a specially crafted image element in the input | when generating files using the `--extract-media` option or outputting | to PDF format. This vulnerability allows an attacker to create or | overwrite arbitrary files on the system, depending on the privileges of | the process running pandoc. It only affects systems that pass untrusted | user input to pandoc and allow pandoc to be used to produce a PDF or | with the `--extract-media` option. […] Note that the `--sandbox` | option, which only affects IO done by readers and writers themselves, | does not block this vulnerability. I discovered that the upstream fix was incomplete while backporting it to buster (LTS). Reported the finding upstream who promptly fixed it in 3.1.6 [1]. Another CVE ID was assigned for this, namely CVE-2023-38745 [2]. The Security Team decided not to issue a DSA for these vulnerabilities, but given they're about to be patched in buster it makes sense to patch other suites, too. Please consider MR !3 for unstable: https://salsa.debian.org/haskell-team/pandoc/-/merge_requests/3 . debdiff attached for convenience. I've also prepared (and tested) a fix for bullseye [3] which I'm planing to submit to -pu once sid is patched. Also planing to rebuild the targeted fix for bookworm and submit it to s-pu. Let me know if you object :-) Cheers, -- Guilhem. [0] https://security-tracker.debian.org/tracker/CVE-2023-35936 https://github.com/jgm/pandoc/security/advisories/GHSA-xj5q-fv23-575g [1] https://github.com/jgm/pandoc/commit/eddedbfc14916aa06fc01ff04b38aeb30ae2e625 [2] https://security-tracker.debian.org/tracker/CVE-2023-38745 https://nvd.nist.gov/vuln/detail/CVE-2023-38745 [3] https://salsa.debian.org/lts-team/packages/pandoc/-/compare/debian%2F2.9.2.1-1...debian%2Fbullseye?from_project_id=22949=false diffstat for pandoc-2.17.1.1 pandoc-2.17.1.1 changelog|9 + patches/CVE-2023-35936.patch | 205 +++ patches/CVE-2023-38745.patch | 98 patches/series |2 4 files changed, 314 insertions(+) diff -Nru pandoc-2.17.1.1/debian/changelog pandoc-2.17.1.1/debian/changelog --- pandoc-2.17.1.1/debian/changelog2022-11-19 14:13:51.0 +0100 +++ pandoc-2.17.1.1/debian/changelog2023-07-21 20:22:42.0 +0200 @@ -1,3 +1,12 @@ +pandoc (2.17.1.1-1.2) unstable; urgency=high + + * Non-maintainer upload. + * Cherry-pick upstream fixes for CVE-2023-35936 from 3.1.4 release. (Closes: +#-1) + * Cherry-pick upstream fix for CVE-2023-35936 from 3.1.6 release. + + -- Guilhem Moulin Fri, 21 Jul 2023 20:22:42 +0200 + pandoc (2.17.1.1-1.1) unstable; urgency=low * Non-maintainer upload. diff -Nru pandoc-2.17.1.1/debian/patches/CVE-2023-35936.patch pandoc-2.17.1.1/debian/patches/CVE-2023-35936.patch --- pandoc-2.17.1.1/debian/patches/CVE-2023-35936.patch 1970-01-01 01:00:00.0 +0100 +++ pandoc-2.17.1.1/debian/patches/CVE-2023-35936.patch 2023-07-21 20:22:42.0 +0200 @@ -0,0 +1,205 @@ +From: John MacFarlane +Date: Tue, 20 Jun 2023 13:50:13 -0700 +Subject: Fix a security vulnerability in MediaBag and + T.P.Class.IO.writeMedia. + +This vulnerability, discovered by Entroy C, allows users to write +arbitrary files to any location by feeding pandoc a specially crafted +URL in an image element. The vulnerability is serious for anyone +using pandoc to process untrusted input. + +Origin: https://github.com/jgm/pandoc/commit/5e381e3878b5da87ee7542f7e51c3c1a7fd84b89 +Origin: https://github.com/jgm/pandoc/commit/54561e9a6667b36a8452b01d2def9e3642013dd6 +Origin: https://github.com/jgm/pandoc/commit/df4f13b262f7be5863042f8a5a1c365282c81f07 +Origin: https://github.com/jgm/pandoc/commit/fe62da61dfd33e6b4c0c03895c528a47a0405bf7 +Origin: https://github.com/jgm/pandoc/commit/5246f02f0bb9c176a6d2f6e3d0c03407d8a67445 +Bug: https://github.com/jgm/pandoc/security/advisories/GHSA-xj5q-fv23-575g +Bug-Debian: https://security-tracker.debian.org/tracker/CVE-2023-35936 +--- + pandoc.cabal| 2 ++ + src/Text/Pandoc/Class/IO.hs | 12 ++-- + src/Text/Pandoc/MediaBag.hs | 27 --- + test/Tests/MediaBag.hs | 37 + + test/test-pandoc.hs | 2 ++ + 5 files changed, 63 insertions(+), 17 deletions(-) + create mode 100644 test/Tests/MediaBag.hs + +diff --git a/pandoc.cabal b/pandoc.cabal +index 52506e3..c5129a8 100644 +--- a/pandoc.cabal b/pandoc.cabal +@@ -791,6 +791,7 @@ test-suite test-pandoc + tasty
Bug#1037086: dropbear-initramfs: /etc/dropbear/initramfs/dropbear_dss_host_key file not generated
On Fri, 30 Jun 2023 at 11:14:35 -0500, Michael Meier wrote: > I had to edit the file /usr/share/initramfs-tools-hooks so it also copies the > dss key: src:dropbear doesn't ship that file, do you mean /usr/share/initramfs-tools/hooks/dropbear? > The option DROPBEAR_OPTIONS="-E" should be default, so the user gets some > kind of error message if something is not working. Would have saved me an > hour or so... -E is the default in debug mode… Need a debug trace anyway to track this down, because it works just fine here (and in ci). -- Guilhem. signature.asc Description: PGP signature
Bug#1039708: bullseye-pu: package lua5.3/5.3.3-1.1+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: lua...@packages.debian.org
Control: affects -1 + src:lua5.3
[ Reason ]
lua5.3=5.3.3-1.1 (buster, bullseye) is vulnerable to CVE-2019-6706 and
CVE-2020-24370. These were fixed in an a recent buster-security upload
(cf. DLA-3469-1). The Security Team didn't think a DSA was warranted
for bullseye, and suggested to go via bullseye-pu instead.
[ Impact ]
* bullseye's lua5.3 would remain vulnerable to CVE-2019-6706 and
CVE-2020-24370 (unlike buster-security).
* buster-security version (5.3.3-1.1+deb10u1) would remain higher than
bullseye's (5.3.3-1.1).
[ Tests ]
* CVE-2019-6706 and CVE-2020-24370 POCs.
* (Adapted) upstream test suite from v5.3.6.
* (Local tests only, the above isn't run at build time nor in
autopkgtests.)
[ Risks ]
Trivial patches backported from upstream's 5.3 branch. The same patches
have been uploaded to buster-security on June 23.
[ 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 fix for CVE-2019-6706: Use after free in
lua_upvaluejoin in lapi.c. (Closes: #920321)
* Backport upstream fix CVE-2020-24370: Segmentation fault in getlocal
and setlocal functions in ldebug.c. (Closes: #988734)
* Add d/salsa-ci.yml for Salsa CI.
[ Other info ]
The suggested debdiff is exactly (modulo d/changelog and d/salsa-ci.yml)
what was uploaded to buster-security.
--
Guilhem.
diffstat for lua5.3-5.3.3 lua5.3-5.3.3
changelog| 10 +++
patches/CVE-2019-6706.patch | 57 +++
patches/CVE-2020-24370.patch | 39 +
patches/series |2 +
salsa-ci.yml |9 ++
5 files changed, 117 insertions(+)
diff -Nru lua5.3-5.3.3/debian/changelog lua5.3-5.3.3/debian/changelog
--- lua5.3-5.3.3/debian/changelog 2018-12-28 20:10:13.0 +0100
+++ lua5.3-5.3.3/debian/changelog 2023-06-22 22:03:38.0 +0200
@@ -1,3 +1,13 @@
+lua5.3 (5.3.3-1.1+deb11u1) bullseye; urgency=high
+
+ * Non-maintainer upload.
+ * Fix CVE-2019-6706: Use after free in lua_upvaluejoin in lapi.c. (Closes:
+#920321)
+ * Fix CVE-2020-24370: Segmentation fault in getlocal and setlocal functions
+in ldebug.c. (Closes: #988734)
+
+ -- Guilhem Moulin Thu, 22 Jun 2023 22:03:38 +0200
+
lua5.3 (5.3.3-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru lua5.3-5.3.3/debian/patches/CVE-2019-6706.patch
lua5.3-5.3.3/debian/patches/CVE-2019-6706.patch
--- lua5.3-5.3.3/debian/patches/CVE-2019-6706.patch 1970-01-01
01:00:00.0 +0100
+++ lua5.3-5.3.3/debian/patches/CVE-2019-6706.patch 2023-06-22
22:03:38.0 +0200
@@ -0,0 +1,57 @@
+From: Roberto Ierusalimschy
+Date: Wed, 27 Mar 2019 14:30:12 -0300
+Subject: Fixed bug in 'lua_upvaluejoin'
+
+Bug-fix: joining an upvalue with itself could cause a use-after-free
+crash.
+
+Origin:
https://github.com/lua/lua/commit/89aee84cbc9224f638f3b7951b306d2ee8ecb71e
+Bug: http://lua-users.org/lists/lua-l/2019-01/msg00039.html
+Bug-Debian: https://security-tracker.debian.org/tracker/CVE-2019-6706
+Bug-Debian: https://bugs.debian.org/920321
+---
+ src/lapi.c | 12 ++--
+ 1 file changed, 6 insertions(+), 6 deletions(-)
+
+diff --git a/src/lapi.c b/src/lapi.c
+index c9455a5..86eac00 100644
+--- a/src/lapi.c
b/src/lapi.c
+@@ -1253,13 +1253,12 @@ LUA_API const char *lua_setupvalue (lua_State *L, int
funcindex, int n) {
+ }
+
+
+-static UpVal **getupvalref (lua_State *L, int fidx, int n, LClosure **pf) {
++static UpVal **getupvalref (lua_State *L, int fidx, int n) {
+ LClosure *f;
+ StkId fi = index2addr(L, fidx);
+ api_check(L, ttisLclosure(fi), "Lua function expected");
+ f = clLvalue(fi);
+ api_check(L, (1 <= n && n <= f->p->sizeupvalues), "invalid upvalue index");
+- if (pf) *pf = f;
+ return >upvals[n - 1]; /* get its upvalue pointer */
+ }
+
+@@ -1268,7 +1267,7 @@ LUA_API void *lua_upvalueid (lua_State *L, int fidx, int
n) {
+ StkId fi = index2addr(L, fidx);
+ switch (ttype(fi)) {
+ case LUA_TLCL: { /* lua closure */
+- return *getupvalref(L, fidx, n, NULL);
++ return *getupvalref(L, fidx, n);
+ }
+ case LUA_TCCL: { /* C closure */
+ CClosure *f = clCvalue(fi);
+@@ -1285,9 +1284,10 @@ LUA_API void *lua_upvalueid (lua_State *L, int fidx,
int n) {
+
+ LUA_API void lua_upvaluejoin (lua_State *L, int fidx1, int n1,
+ int fidx2, int n2) {
+- LClosure *f1;
+- UpVal **up1 = getupvalref(L, fidx1, n1, );
+- UpVal **up2 = getupvalref(L, fidx2, n2, NULL);
++ UpVal **up1 = getupvalref(L, fidx1, n1);
++ UpVal **up2 = getu
Bug#1034847: First commit
Hi, On Sun, 25 Jun 2023 at 21:19:10 +, Bastien Roucariès wrote: > I found the commit that remove the stack overlfow check line 688 > https://github.com/lua/lua/commit/287b302acb8d925178e9edb800f0a8d18c7d35f6 That also matching my finding from https://bugs.debian.org/1034847#12 . Asked for confirmation upstream at http://lua-users.org/lists/lua-l/2023-06/msg00059.html and waiting for a reply. -- Guilhem. signature.asc Description: PGP signature
Bug#1034847: lua5.3: CVE-2021-43519
Hi carnil, On Fri, 23 Jun 2023 at 21:49:21 +0200, Salvatore Bonaccorso wrote: > thanks for the analysis. I want to point out that it's really > important to not rely on the POC for making the not-affected > assessment (and when not confirmed, rather err on the safe side and > keep something marked affected). Sure, I started digging further after wondering why I wasn't able to reproduce this in 5.3 :-) > Your analysis at first glance seems to make sense, but to be on safe > side, unless jmm seems it to fit, I would rather go with the still > affected, but ignored for stable and older suites. Ack > If you can prod upstream to double-check with them if you have indeed > found the introducing commit, then we can update the CVE entry > accordingly. FWIW I just noticed the issue is listed at https://www.lua.org/bugs.html#5.4.3-7 , with a link to the upstream fix 74d99057 (unfortunately the page doesn't list any CVE ID), and indeed reads “existed since 5.4.2”. Also in the CVE description (“5.1.0~5.4.4”) the upper bound is definitely wrong since 74d99057 is an ancestor of v5.4.4. -- Guilhem. signature.asc Description: PGP signature
Bug#1034847: lua5.3: CVE-2021-43519
On Thu, 22 Jun 2023 at 18:08:39 +0200, Guilhem Moulin wrote: > bullseye > > > $ lua5.1 ./cstack.lua > testing stack overflow detection > nesting coroutines running after recoverable errors > final count:198 > > $ lua5.2 ./cstack.lua > testing stack overflow detection > nesting coroutines running after recoverable errors > final count:197 > > $ lua5.3 ./cstack.lua > testing stack overflow detection > nesting coroutines running after recoverable errors > final count:197 > > $ lua5.4 ./cstack.lua > testing stack overflow detection > nesting coroutines running after recoverable errors > E: Child terminated by signal ‘Segmentation fault’ One more thing: cstack.lua attached earlier contains the unit test upstream added to v5.4.4 in https://github.com/lua/lua/commit/74d99057a5146755e737c479850f87fd0e3b6868 . crash.lua from http://lua-users.org/lists/lua-l/2021-10/msg00123.html yields the same result: only bullseye's lua5.4=5.4.2-2 results in a crash. All other versions error out in a (controlled) stack overflow as intended (like for example1.lua and example2.lua). > AFAICT lua5.3 is unaffected since there L->nCcalls is incremented in > lua_resume() i.e., outside LUAI_THROW: > https://sources.debian.org/src/lua5.3/5.3.3-1.1/src/ldo.c/#L659 > > Didn't try to bisect but I believe this was introduced upstream at > https://github.com/lua/lua/commit/287b302acb8d925178e9edb800f0a8d18c7d35f6#diff-a1e6f0be3689739fa1e5707427e78d792c7f6a333bed95fd05c4382d60bda7c4L687-R689 Tried to build released versions from lua-all.tar.gz meanwhile (in a bullseye chroot), I was indeed only able to reproduce this in 5.4.2 and 5.4.3 (the above 287b302a was added between 5.4.1 and 5.4.2). version crash.lua --- - 5.0 SIGSEGV 5.0.1SIGSEGV 5.0.2SIGSEGV 5.0.3SIGSEGV 5.1 SIGSEGV 5.1.1SIGSEGV 5.1.2SIGSEGV 5.1.3success 5.1.4success 5.1.5success 5.2.0SIGSEGV 5.2.1success 5.2.2success 5.2.3success 5.2.4success 5.3.0success 5.3.1success 5.3.2success 5.3.3success 5.3.4success 5.3.5success 5.3.6success 5.4.0success 5.4.1success 5.4.2SIGSEGV 5.4.3SIGSEGV 5.4.4success 5.4.5success 5.4.6success All releases in 5.3.x pass the test. 5.0 releases, as well as early 5.1 releases, and 5.2.0, do segfault, but I believe the reason is unrelated and was documented at https://www.lua.org/bugs.html#5.1.2-4 resp. https://www.lua.org/bugs.html#5.2.0-4. Either way the test passes on bullseye's lua5.1=5.1.5-8.1+b3, lua5.2=5.2.4-1.1+b3, and lua5.3=5.3.3-1.1+b1. I didn't adjust affected versions CVE/list so the Security Team can make their own assessment (also buster and bullseye have the same version and AFAIK it's not possible to mark only one release as ). Cheers -- Guilhem. signature.asc Description: PGP signature
Bug#1034847: lua5.3: CVE-2021-43519
Hi Moritz,
On Tue, 25 Apr 2023 at 20:58:00 +0200, Moritz Mühlenhoff wrote:
> CVE-2021-43519[0]:
> | Stack overflow in lua_resume of ldo.c in Lua Interpreter 5.1.0~5.4.4
> | allows attackers to perform a Denial of Service via a crafted script
> | file.
While trigaging this for LTS I was unable to trigger the crash with
lua5.1, lua5.2, or lua5.3 on buster, bullseye, or bookworm. AFAICT only
bullseye's lua5.4 is affected:
buster
==
$ lua5.1 ./cstack.lua
testing stack overflow detection
nesting coroutines running after recoverable errors
final count:198
$ lua5.2 ./cstack.lua
testing stack overflow detection
nesting coroutines running after recoverable errors
final count:197
$ lua5.3 ./cstack.lua
testing stack overflow detection
nesting coroutines running after recoverable errors
final count:197
bullseye
$ lua5.1 ./cstack.lua
testing stack overflow detection
nesting coroutines running after recoverable errors
final count:198
$ lua5.2 ./cstack.lua
testing stack overflow detection
nesting coroutines running after recoverable errors
final count:197
$ lua5.3 ./cstack.lua
testing stack overflow detection
nesting coroutines running after recoverable errors
final count:197
$ lua5.4 ./cstack.lua
testing stack overflow detection
nesting coroutines running after recoverable errors
E: Child terminated by signal ‘Segmentation fault’
bookworm
$ lua5.1 ./cstack.lua
testing stack overflow detection
nesting coroutines running after recoverable errors
final count:198
$ lua5.2 ./cstack.lua
testing stack overflow detection
nesting coroutines running after recoverable errors
final count:197
$ lua5.3 ./cstack.lua
testing stack overflow detection
nesting coroutines running after recoverable errors
final count:197
$ lua5.4 ./cstack.lua
testing stack overflow detection
nesting coroutines running after recoverable errors
final count:197
As the reporter suggested at
http://lua-users.org/lists/lua-l/2021-10/msg00123.html,
the issue is that L->nCcalls is incremented in resume(), but that
function is called via luaD_rawrunprotected() which resets the state on
error: https://sources.debian.org/src/lua5.4/5.4.2-2/src/ldo.c/#L716 .
AFAICT lua5.3 is unaffected since there L->nCcalls is incremented in
lua_resume() i.e., outside LUAI_THROW:
https://sources.debian.org/src/lua5.3/5.3.3-1.1/src/ldo.c/#L659
Didn't try to bisect but I believe this was introduced upstream at
https://github.com/lua/lua/commit/287b302acb8d925178e9edb800f0a8d18c7d35f6#diff-a1e6f0be3689739fa1e5707427e78d792c7f6a333bed95fd05c4382d60bda7c4L687-R689
Cheers,
--
Guilhem.
-- $Id: testes/cstack.lua $
-- See Copyright Notice in file all.lua
local tracegc = require"tracegc"
print"testing stack overflow detection"
local function checkerror (msg, f, ...)
local s, err = pcall(f, ...)
assert(not s and string.find(err, msg))
end
do-- bug in 5.4.2
print("nesting coroutines running after recoverable errors")
local count = 0
local function foo()
count = count + 1
pcall(1) -- create an error
-- running now inside 'precover' ("protected recover")
coroutine.wrap(foo)() -- call another coroutine
end
checkerror("C stack overflow", foo)
print("final count: ", count)
end
-- track collections
local M = {}
-- import list
local setmetatable, stderr, collectgarbage =
setmetatable, io.stderr, collectgarbage
_ENV = nil
local active = false
-- each time a table is collected, remark it for finalization on next
-- cycle
local mt = {}
function mt.__gc (o)
stderr:write'.'-- mark progress
if active then
setmetatable(o, mt) -- remark object for finalization
end
end
function M.start ()
if not active then
active = true
setmetatable({}, mt)-- create initial object
end
end
function M.stop ()
if active then
active = false
collectgarbage() -- call finalizer for the last time
end
end
return M
signature.asc
Description: PGP signature
Bug#1037537: Upgrade To Bookworm Fails with Roundcube Update
On Tue, 13 Jun 2023 at 20:45:19 -0500, Bryan K. Walton wrote: > Previous Roundcube version: 1.4.13+dfsg.1-1~deb11u1 > Previous Debian version: 11.7 Which DB backend are you using? I'm unable to reproduce this in a Bullseye (11.7) VM with roundcube-mysql (the default): ~# apt install -y default-mysql-server ~# apt install -y roundcube-core ## don't change pre-selected debconf values ## replace /etc/roundcube/config.inc.php with yours (except $config['des_key']) ~# sed -i s/bullseye/bookworm/ /etc/apt/sources.list ~# apt update ~# apt dist-upgrade Works here, both when selecting “install the package maintainer's version” or “keep the local version currently installed” for /etc/roundcube/config.inc.php. (In both cases, I answered “Yes” to “Perform upgrade on database for roundcube with dbconfig-common?”.) Does `apt install -f` fix the problem for you? If not, you might want to edit /var/lib/dpkg/info/roundcube-core.postinst and replace `set -e` with `set -ex` to get a debug trace. > $config['plugins'] = array( > 'archive', > 'twofactor_gauthenticator', > 'carddav', > 'chbox', > ); AFAICT ‘twofactor_gauthenticator’, ‘carddav’ and ‘chbox’ don't come from Debian. Does it help to remove these 3 from the array? -- Guilhem. signature.asc Description: PGP signature
Bug#1037537: Upgrade To Bookworm Fails with Roundcube Update
Control: tag -1 unreproducible moreinfo On Tue, 13 Jun 2023 at 16:16:51 -0500, Bryan K. Walton via Pkg-roundcube-maintainers wrote: > Today, I tried to upgrade my webserver to Debian 12.0 (bookworm). > Everything succeeded but Roundcube. What was the previous Roundcube (and Debian itself) version? Please also share your roundcube configuration file. piuparts checks the upgrade path of the stock config (for all of DB backends) and that appear to be smooth. -- Guilhem. signature.asc Description: PGP signature
Bug#1037086: dropbear-initramfs: /etc/dropbear/initramfs/dropbear_dss_host_key file not generated
Control: tag -1 moreinfo unreproducible Hi, On Sun, 04 Jun 2023 at 10:41:56 +0200, Georg Gast wrote: > But dropbear did not start as it was complaining about the missing dss host > key. > […] > If i delete /etc/dropbear/initramfs/dropbear_dss_host_key and generate a new > one > dropbearkeygen -t dss -f /etc/dropbear/initramfs/dropbear_dss_host_key > in the resuce shell dropbear starts. Which version of the dropbear-bin package is that? 2022.83-1 doesn't support DSS, see the NEWS-file. > Versions of packages dropbear-initramfs depends on: > ii busybox-static [busybox] 1:1.35.0-4+b3 > pn dropbear-bin > ii initramfs-tools 0.142 > ii udev 252.6-1 dropbear-initramfs=2022.83-1 has ‘Depends: dropbear-bin (>= 2022.83-1)’, so it can skip over DSS key generation when dependencies are fulfilled. -- Guilhem. signature.asc Description: PGP signature
Bug#962629: rainloop: Rainloop stores passwords in cleartext in logfile
Control: tag -1 unreproducible
On Wed, 10 Jun 2020 at 23:19:41 +0200, Marco Herrn wrote:
> When writing into a logfile, rainloop writes the passwords of all
> login attempts (successful or not) into the logfile in cleartext.
FWIW I'm not able to reproduce this with the version from Debian buster
(1.12.1-2). Stock config, just replaced ‘enable = Off’ with ‘enable = On’
in /etc/rainloop/application.ini's ‘[logs]’ section. (‘hide_passwords’
remains set as per default.) I see my username in the log, but the
passphrase is replaced with (a fixed number of) asterisks in both in
succesful and failed sessions:
INFO[DATA]:
[DATE:27.05.23][OFFSET:-00][RL:1.12.1][PHP:7.3.31-1~deb10u3][IP:127.0.0.1][PID:976085][nginx/1.14.2][fpm-fcgi]
INFO[DATA]:
[Suhosin:off][APC:off][MB:off][PDO:~][Streams:tcp,udp,unix,udg,ssl,tls,tlsv1.0,tlsv1.1,tlsv1.2]
REQUEST[NOTE]: [POST] http://127.0.0.1/?/Ajax/[]=/0/
AJAX[NOTE]: Action: DoLogin
POST[DATA]:
{"Email":"guil...@example.net","Login":"","Password":"***","Language":"","AdditionalCode":"","AdditionalCodeSignMe":"0","SignMe":"0","Action":"Login","XToken":"[…]"}
IMAP[NOTE]: Start connection to "ssl://imap.example.net:993"
IMAP[NOTE]: Connected (success)
IMAP[DATA]: < * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE
IDLE LITERAL+ AUTH=PLAIN AUTH=LOGIN] howdy, ready.\r\n
IMAP[DATA]: > TAG1 AUTHENTICATE PLAIN\r\n
IMAP[DATA]: < + \r\n
IMAP[SECURE]: > ***\r\n
IMAP[DATA]: < TAG1 NO [AUTHENTICATIONFAILED] Authentication failed.\r\n
IMAP[WARNING]: MailSo\Imap\Exceptions\NegativeResponseException:
MailSo-Imap-Exceptions-NegativeResponseException (ImapClient.php ~ 1874) in
/usr/share/rainloop/app/libraries/MailSo/Imap/ImapClient.php:1874
Stack trace:
#0 /usr/share/rainloop/app/libraries/MailSo/Imap/ImapClient.php(1951):
MailSo\Imap\ImapClient->validateResponse(Array)
#1 /usr/share/rainloop/app/libraries/MailSo/Imap/ImapClient.php(281):
MailSo\Imap\ImapClient->parseResponseWithValidation()
#2 /usr/share/rainloop/app/libraries/MailSo/Mail/MailClient.php(92):
MailSo\Imap\ImapClient->Login('guilhem@example', '***', '', true, false)
#3 /usr/share/rainloop/app/libraries/RainLoop/Model/Account.php(451):
MailSo\Mail\MailClient->Login('guilhem@example', '***', '', true, false)
#4 /usr/share/rainloop/app/libraries/RainLoop/Actions.php(2078):
RainLoop\Model\Account->IncConnectAndLoginHelper(Object(RainLoop\Plugins\Manager),
Object(MailSo\Mail\MailClient), Object(RainLoop\Config\Application))
#5 /usr/share/rainloop/app/libraries/RainLoop/Actions.php(2329):
RainLoop\Actions->CheckMailConnection(Object(RainLoop\Model\Account), true)
#6 /usr/share/rainloop/app/libraries/RainLoop/Actions.php(2381):
RainLoop\Actions->LoginProcess('guilhem@example', '***', '', '', false)
#7 /usr/share/rainloop/app/libraries/RainLoop/ServiceActions.php(172):
RainLoop\Actions->DoLogin()
#8 /usr/share/rainloop/app/libraries/RainLoop/Service.php(146):
RainLoop\ServiceActions->ServiceAjax('')
#9 /usr/share/rainloop/app/libraries/RainLoop/Service.php(56):
RainLoop\Service->localHandle()
#10 /usr/share/rainloop/app/libraries/RainLoop/Service.php(79):
RainLoop\Service->__construct()
#11 /usr/share/rainloop/app/handle.php(94): RainLoop\Service::Handle()
#12 /usr/share/rainloop/include.php(228): include('/usr/share/rain...')
#13 /usr/share/rainloop/index.php(13): include('/usr/share/rain...')
#14 {main}
IMAP[NOTICE]: MailSo\Imap\Exceptions\NegativeResponseException:
MailSo-Imap-Exceptions-NegativeResponseException (ImapClient.php ~ 1874) in
/usr/share/rainloop/app/libraries/MailSo/Imap/ImapClient.php:1874
Stack trace:
#0 /usr/share/rainloop/app/libraries/MailSo/Imap/ImapClient.php(1951):
MailSo\Imap\ImapClient->validateResponse(Array)
#1 /usr/share/rainloop/app/libraries/MailSo/Imap/ImapClient.php(281):
MailSo\Imap\ImapClient->parseResponseWithValidation()
#2 /usr/share/rainloop/app/libraries/MailSo/Mail/MailClient.php(92):
MailSo\Imap\ImapClient->Login('guilhem@example', '***', '', true, false)
#3 /usr/share/rainloop/app/libraries/RainLoop/Model/Account.php(451):
MailSo\Mail\MailClient->Login('guilhem@example', '***', '', true, false)
#4 /usr/share/rainloop/app/libraries/RainLoop/Actions.php(2078):
RainLoop\Model\Account->IncConnectAndLoginHelper(Object(RainLoop\Plugins\Manager),
Object(MailSo\Mail\MailClient), Object(RainLoop\Config\Application))
#5 /usr/share/rainloop/app/libraries/RainLoop/Actions.php(2329):
RainLoop\Actions->CheckMailConnection(Object(RainLoop\Model\Account), true)
#6 /usr/share/rainloop/app/libraries/RainLoop/Actions.php(2381):
RainLoop\Actions->LoginProcess('guilhem@example', '***', '', '', false)
#7 /usr/share/rainloop/app/libraries/RainLoop/ServiceActions.php(172):
RainLoop\Actions->DoLogin()
#8 /usr/share/rainloop/app/libraries/RainLoop/Service.php(146):
Bug#1018730: lvm2: Initramfs does not activate root LVs if VG is incomplete since 2.03.15 or 2.03.16, boot failure
On Thu, 11 May 2023 at 18:12:52 +0200, Bastian Blank wrote: > Nope, not really. Half VG was never a real thing. It might work in > some cases. And these use-cases are unbootable since 2.03.15… > Then, degraded is the default activation mode, so overriding that would > not be appropriate. But forcefully enabling stuff like an incomplete > raid will trigger rebuilds every time. So no, this can't be the default > option. If that's a concern then ‘--activationmode complete’ can be used instead (although the boot scripts used the default mode from lvm.conf). That's enough to fix the systems rapported here, because the required LVs are actually complete. -- Guilhem. signature.asc Description: PGP signature
Bug#1018730: lvm2: Initramfs does not activate root LVs if VG is incomplete since 2.03.15 or 2.03.16, boot failure
Control: severity -1 serious
Control: tag -1 + patch
Please consider the enclosed patch. The aim is to also activate
incomplete VGs at early boot stage, like lvm2 used to do before
2.03.15-1, and be a no op on “normal systems” once execution has been
handed over to init(1).
There might be a better way to detect an initramfs-tools environment
than checking whether ‘/run/initramfs’ exists (and ‘/run/systemd/system’
doesn't).
The patch doesn't break src:cryptsetup's autopkgtests. It also solves
the present regression AFAICT, at least for the reproducers I tested.
--
Guilhem.
From: Guilhem Moulin
Date: Wed, 10 May 2023 00:42:28 +0200
Subject: udev rules: Try to call activate incomplete VGs at initramfs stage.
The upstream udev rules don't autoactivate LVs residing on incomplete
VGs, see https://bugzilla.redhat.com/show_bug.cgi?id=1337220#c10 .
This change adds new rules to try to activate incomplete VGs, should
there be any. The target environment for these rules is an initrd from
initramfs-tools.
lvm <2.03.15-1 used to ship initramfs-tools boot scripts containing `lvm
lvchange -aay -y --sysinit` which by default *does* activate incomplete
VGs, so the deprecation of these scripts in favor of the upstream rules
yield a regression on systems where the root FS and/or resume device(s)
reside on complete LVs while the underlying VG is incomplete (as in, it
contains LVs residing on missing PVs). `lsblk` output on an affected
system is as follows:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
vda254:002G 0 disk
├─vda1 254:102M 0 part
├─vda2 254:20 128M 0 part /boot
└─vda3 254:30 1.8G 0 part
└─vda3_crypt 253:00 1.8G 0 crypt
├─cryptvg-swap 253:10 128M 0 lvm [SWAP]
└─cryptvg-root 253:20 1.7G 0 lvm /
vdb254:16 01G 0 disk
└─vdb_crypt253:30 1008M 0 crypt
└─cryptvg-home 253:40 1004M 0 lvm /home
(There vdb_crypt is not open at early boot stage since it hold neither
the root FS nor the resume device, hence ‘cryptvg’ remains incomplete.
Without this patch the LVs are never activated and the user is
eventually dropped into an initramfs shell.)
Closes: #1018730
Closes: #1034836
---
udev/69-dm-lvm.rules.in | 2 ++
1 file changed, 2 insertions(+)
diff --git a/udev/69-dm-lvm.rules.in b/udev/69-dm-lvm.rules.in
index b32b94a..c46d965 100644
--- a/udev/69-dm-lvm.rules.in
+++ b/udev/69-dm-lvm.rules.in
@@ -87,6 +87,8 @@ GOTO="lvm_end"
LABEL="lvm_direct_vgchange"
ENV{LVM_VG_NAME_COMPLETE}=="?*", RUN+="(LVM_EXEC)/lvm vgchange -aay --autoactivation event $env{LVM_VG_NAME_COMPLETE}"
+TEST!="/run/initramfs", GOTO="lvm_end"
+ENV{LVM_VG_NAME_INCOMPLETE}=="?*", RUN+="(LVM_EXEC)/lvm vgchange --sysinit -aay --activation degraded $env{LVM_VG_NAME_INCOMPLETE}"
GOTO="lvm_end"
LABEL="lvm_end"
signature.asc
Description: PGP signature
Bug#1034836: initramfs-tools: After bullseye -> bookworm upgrade boot stuck in the initramfs shell
Control: tag -1 - unreproducible Control: reassign -1 lvm2 2.03.15-1 Control: forcemerge 1018730 -1 Control: affects -1 cryptsetup-initramfs Thanks for the the reproducer! Much appreciated. So the problem is that your VG spans over multiple PVs, but the LVs that are required at early boot stage (the ones holding the root FS and the resume device) reside only on the first PV so cryptsetup-initramfs rightfully never tries to unlock the second one (which only holds /home hence is not needed that early). This used to work, but it looks like lvm2's udev rules never try to activate complete LVs residing on incomplete VGs, hence the deadlock. This mostly affects cryptsetup-initramfs and perhaps the issue could be mitigated there, but this is an lvm2 regression and non-luks systems can be affected too [0] so I'm reassign the bug accordingly. (Turns out it was already reported, hence also merging.) A quick fix for your particular setup is to edit crypttab(5), add the ‘initramfs’ option for the ‘4Tsolid’, and rebuild the initramfs image. That should force the device to be considered at initramfs stage. -- Guilhem. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1337220#c10 signature.asc Description: PGP signature
Bug#1034836: initramfs-tools: After bullseye -> bookworm upgrade boot stuck in the initramfs shell
Control: tag -1 - moreinfo On Tue, 09 May 2023 at 18:39:33 +0200, Pásztor János wrote: > I have attached the machine definition and already sent the vm images for > you (via filesender.hu). Many thanks! Will have something to put teeth into once the images have been downloaded :-) -- Guilhem. signature.asc Description: PGP signature
Bug#1034836: initramfs-tools: After bullseye -> bookworm upgrade boot stuck in the initramfs shell
Control: tag -1 + unreproducible moreinfo On Tue, 09 May 2023 at 17:10:03 +0200, Pásztor János wrote: > The machine and the disks are having two snapshots named 'good' and 'bad' so > it is easy to jump between the states. > I am willing to share with you the VM(disks + virsh dump) via a filesharing > service. Would you be interested in it? Yes please; I still cannot reproduce the issue. -- Guilhem. signature.asc Description: PGP signature
Bug#1034836: initramfs-tools: After bullseye -> bookworm upgrade boot stuck in the initramfs shell
Control: tag -1 unreproducible moreinfo
What does `lsinitramfs /initrd.img | grep -e{crypt,lvm}` return (after
removing your hook and rebuilding the initramfs image)? And also
install -m0700 -d /tmp/initramfs
unmkinitramfs /initrd.img /tmp/initramfs
cat /tmp/initramfs/cryptroot/crypttab
And also
dpkg -l | grep -e{cryptsetup,lvm}
--
Guilhem.
signature.asc
Description: PGP signature
Bug#1035046: bullseye-pu: package lacme/0.8.0-2+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: la...@packages.debian.org Control: affects -1 + src:lacme [ Reason ] The ACME specification (RFC 8555 sec. 7.1.6) clearly reads that state transition for Order Objects follows (‘pending’ →) ‘ready’ → ‘processing’ → ‘valid’, but lacme 0.8.0-2 fails to handle the transition via ‘processing’ state. https://www.rfc-editor.org/rfc/rfc8555#section-7.1.6 [ Impact ] As of today Order Requests still work on the production Let's Encrypt environment, but now fails on the staging one. It's unclear whether the production server has different timing conditions (faster machine, so the client doesn't have time to issue follow-up request while the server is in ‘processing’ state), or if there was some code change deployed to the staging server which is not in production (yet). In the former case, the lacme client suffers from a race condition that needs to be fixed anyway. In the latter case, lacme will fail to handle Order Requests (incl. certificate renewals) if/when the production ACME server is upgraded. The issue is fixed in unstable (0.8.2-1) and the unblock request for bookworm was filed at #1034879. [ Tests ] Manual tests: I successfully ran the upstream test suite (which includes multiple Order Requests) on the staging server. (There is unfortunately no autopkgtest running the test suite, because it requires inbound 80/tcp and a stable (wildcard) domain name.) I also successfully issued Order Requests to Let's Encrypt's production server. [ Risks ] src:lacme is a leaf package and the diff is rather trivial: AFAICT the only change is a more lax handling of Order Object responses, so there shouldn't be any risk associated with the upgrade. [ 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 bullseye [x] the issue is verified as fixed in unstable [ Changes ] * Point debian-branch to debian/bullseye in debian/gbp.conf. * lacme client: Handle "ready" → "processing" → "valid" status change during newOrder, instead of just "ready" → "valid". The latter may be what we observe when the server is fast enough, but according to RFC 8555 sec. 7.1.6 the state actually transitions via "processing" and the client needs to account for that. It appears Let's Encrypt staging environment now has different timing conditions and lacme is unable to request certificates due to this issue. (Closes: #1034834) -- Guilhem. diffstat for lacme-0.8.0 lacme-0.8.0 changelog | 11 + gbp.conf|2 patches/client-Handle-ready-processing-valid-status-change-during.patch | 76 ++ patches/series |1 4 files changed, 89 insertions(+), 1 deletion(-) diff -Nru lacme-0.8.0/debian/changelog lacme-0.8.0/debian/changelog --- lacme-0.8.0/debian/changelog2021-05-04 01:37:13.0 +0200 +++ lacme-0.8.0/debian/changelog2023-04-28 10:25:54.0 +0200 @@ -1,3 +1,14 @@ +lacme (0.8.0-2+deb11u1) bullseye; urgency=medium + + * client: Handle "ready" → "processing" → "valid" status change during +newOrder, instead of just "ready" → "valid". The latter may be what we +observe when the server is fast enough, but according to RFC 8555 sec. +7.1.6 the state actually transitions via "processing" and we need to +account for that (closes: #1034834). + * d/gbp.conf: Set 'debian-branch = debian/bullseye'. + + -- Guilhem Moulin Fri, 28 Apr 2023 10:25:54 +0200 + lacme (0.8.0-2) unstable; urgency=medium * d/lacme.postrm: Don't delete system users on purge. There might be files diff -Nru lacme-0.8.0/debian/gbp.conf lacme-0.8.0/debian/gbp.conf --- lacme-0.8.0/debian/gbp.conf 2021-05-04 01:37:13.0 +0200 +++ lacme-0.8.0/debian/gbp.conf 2023-04-28 10:25:54.0 +0200 @@ -1,6 +1,6 @@ [DEFAULT] upstream-branch = upstream -debian-branch = debian/latest +debian-branch = debian/bullseye upstream-tag = v%(version)s debian-tag = debian/%(version)s pristine-tar = False diff -Nru lacme-0.8.0/debian/patches/client-Handle-ready-processing-valid-status-change-during.patch lacme-0.8.0/debian/patches/client-Handle-ready-processing-valid-status-change-during.patch --- lacme-0.8.0/debian/patches/client-Handle-ready-processing-valid-status-change-during.patch 1970-01-01 01:00:00.0 +0100 +++ lacme-0.8.0/debian/patches/client-Handle-ready-processing-valid-status-change-during.patch 2023-04-28 10:25:54.0 +0200 @@ -0,0 +1,76 @@ +From: Guilhem Moulin +Date: Tue, 25 Apr 2023 10:5
Bug#1034879: unblock: lacme/0.8.2-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: la...@packages.debian.org
Control: affects -1 + src:lacme
Please unblock package lacme
[ Reason ]
The ACME specification (RFC 8555 sec. 7.1.6) clearly reads that state
transition for Order Objects follows (‘pending’ →) ‘ready’ →
‘processing’ → ‘valid’, but lacme 0.8.1-1 fails to handle the transition
via ‘processing’ state.
https://www.rfc-editor.org/rfc/rfc8555#section-7.1.6
[ Impact ]
As of today Order Requests still work on the production Let's Encrypt
environment, but now fails on the staging one. It's unclear whether the
production server has different timing conditions (faster machine, so
the client doesn't have time to issue follow-up request while the server
is in ‘processing’ state), or if there was some code change deployed to
the staging server which is not in production (yet).
In the former case, the lacme client suffers from a race condition that
needs to be fixed anyway. In the latter case, lacme will fail to handle
Order Requests (incl. certificate renewals) if/when the production ACME
server is upgraded.
[ Tests ]
Manual tests: I successfully ran the upstream test suite (which includes
multiple Order Requests) on the staging server. (There is unfortunately
no autopkgtest running the test suite, because it requires inbound
80/tcp and a stable (wildcard) domain name.)
I also successfully issued Order Requests to Let's Encrypt's production
server.
[ Risks ]
src:lacme is a leaf package and the diff is so trivial I uploaded
0.8.2-1 rather than backported the fix to 0.8.1-1. AFAICT the only
change is a more lax handling of Order Object responses, so there
shouldn't be any risk associated with the upgrade.
[ 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 testing
unblock lacme/0.8.2-1
--
Guilhem.
diffstat for lacme-0.8.1 lacme-0.8.2
Changelog | 11 +++
client | 31 +--
debian/changelog | 12
lacme |2 +-
lacme-accountd |2 +-
tests/old-accountd |2 +-
6 files changed, 43 insertions(+), 17 deletions(-)
diff -Nru lacme-0.8.1/Changelog lacme-0.8.2/Changelog
--- lacme-0.8.1/Changelog 2023-01-25 03:23:51.0 +0100
+++ lacme-0.8.2/Changelog 2023-04-25 20:06:22.0 +0200
@@ -1,3 +1,14 @@
+lacme (0.8.2) upstream;
+
+ + client: Handle "ready" → "processing" → "valid" status change during
+newOrder, instead of just "ready" → "valid". The latter may be what
+we observe when the server is fast enough, but according to RFC 8555
+sec. 7.1.6 the state actually transitions via "processing" state and
+we need to account for that.
+ - Test suite: Point stretch's archive URL to archive.d.o.
+
+ -- Guilhem Moulin Tue, 25 Apr 2023 20:06:22 +0200
+
lacme (0.8.1) upstream;
+ lacme-accountd: improve log messages and refactor logging logic.
diff -Nru lacme-0.8.1/client lacme-0.8.2/client
--- lacme-0.8.1/client 2023-01-25 03:23:51.0 +0100
+++ lacme-0.8.2/client 2023-04-25 20:06:22.0 +0200
@@ -43,7 +43,7 @@
# instance own by another user and created with umask 0177) is not a
# problem since SOCKET_FD can be bound as root prior to the execve(2).
-our $VERSION = '0.8.1';
+our $VERSION = '0.8.2';
my $PROTOCOL_VERSION = 1;
my $NAME = 'lacme-client';
@@ -346,11 +346,12 @@
}
# poll the order URL (to get the status of all challenges at once)
-# until the status become 'valid'
+# until the status become 'valid'; see RFC 8555 sec. 7.1.6 for the
+# the status change flow
my $orderstr = join(', ', map {uc($_->{type}) .":". $_->{value}}
@identifiers);
my $certuri;
-for (my $i = 0;;) {
-my $r = acme($orderurl);
+for (my $i = 0, my $url = $orderurl, my $payload;;) {
+my $r = acme($url => $payload);
my $resp = request_json_decode($r);
if (defined (my $problem = $resp->{error})) { # problem document (RFC
7807)
my $msg = $problem->{status};
@@ -361,19 +362,21 @@
my $status = $resp->{status};
if (!defined $status or $status eq "invalid") {
die "Error: Invalid order $orderstr\n";
-}
-elsif ($status eq "ready") {
-my $r = acme($order->{finalize}, {csr => encode_base64url($csr)});
-my $resp = request_json_decode($r);
-$certuri = $resp->{certificate};
-last;
-}
-elsif ($status eq "valid") {
+} elsif ($status eq "pending") {
+# keep retrying
+} elsif ($status eq "ready") {
+$url = $order->{finalize};
+$payload =
Bug#1034834: lacme: client fails to handle "ready" → "processing" → "valid" status change
Package: lacme Version: 0.8.1-1 Severity: important Control: found -1 0.8.0-2 The lacme client fails to handle "ready" → "processing" → "valid" status change during newOrder, instead of just "ready" → "valid". The latter may be what we observe when the server is fast enough, but according to RFC 8555 sec. 7.1.6 the state actually transitions via "processing" state and we need to account for that. As of today `lacme newOrder` still works on the production Let's Encrypt ACME server, but now fails on the staging one. It's unclear whether the staging environment has different timing conditions, or if there were changes in the boulder codebase which will break lacme once pushed to production. -- Guilhem. signature.asc Description: PGP signature
Bug#1034810: bookworm-pu: package cryptsetup/2:2.6.1-4~deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
Control: affects -1 + src:cryptsetup
Dear Release Team,
[ Reason ]
It was discovered that the upstream patch mitigating #1028250 was
incomplete: `cryptsetup luksFormat` still caused OOM on some memory
constrained systems. This was fixed upstream in a new MR, which is
backported in sid in 2:2.6.1-4.
Unfortunately the version (like -3) is barred from entering testing due
to a dependency on libargon2-1-udeb ≥0~20190702+dfsg, hence the request
to go via t-p-u instead. See https://bugs.debian.org/1032235#107 .
[ Impact ]
Running `cryptsetup luksFormat` might OOM on systems with ≤1G RAM when
the memory pressure exceeds 50%. Concretely, that means one might not
be able to relying use the “encrypted LVM” partitioning scheme from the
graphical installer on such systems.
[ Tests ]
* DEP-8 tests, incl. full upstream test suite and cryptroot tests.
* Comparison of memory costs between releases from d-i depending on the
amount of RAM: https://bugs.debian.org/1028250#78 .
[ Risks ]
The change only affets systems with <2G RAM, and among those only the
ones without swap area. That includes low-memory rescue systems and
d-i, but not “normal systems”.
[ 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 testing
[x] the issue is verified as fixed in unstable
[ Changes ]
Backport upstream MR
https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests/498 :
+ 7893c33d: Check for physical memory available also in PBKDF benchmark.
+ 6721d3a8: Use only half of detected free memory on systems without swap.
[ Other info ]
CC'ing kibi for d-i-ack.
--
Guilhem.
diffstat for cryptsetup-2.6.1 cryptsetup-2.6.1
changelog | 14
+
patches/Check-for-physical-memory-available-also-in-PBKDF-benchma.patch | 74
++
patches/Use-only-half-of-detected-free-memory-on-systems-without-.patch | 43
+
patches/series |2
4 files changed, 133 insertions(+)
diff -Nru cryptsetup-2.6.1/debian/changelog cryptsetup-2.6.1/debian/changelog
--- cryptsetup-2.6.1/debian/changelog 2023-03-26 19:18:59.0 +0200
+++ cryptsetup-2.6.1/debian/changelog 2023-04-21 00:54:29.0 +0200
@@ -1,3 +1,17 @@
+cryptsetup (2:2.6.1-4~deb12u1) bookworm; urgency=medium
+
+ * Rebuild for Bookworm.
+
+ -- Guilhem Moulin Fri, 21 Apr 2023 00:54:29 +0200
+
+cryptsetup (2:2.6.1-4) unstable; urgency=medium
+
+ * Backport upstream MR !498, see #1028250:
++ 7893c33d: Check for physical memory available also in PBKDF benchmark.
++ 6721d3a8: Use only half of detected free memory on systems without swap.
+
+ -- Guilhem Moulin Thu, 20 Apr 2023 23:46:08 +0200
+
cryptsetup (2:2.6.1-3~deb12u1) bookworm; urgency=medium
* Rebuild for Bookworm.
diff -Nru
cryptsetup-2.6.1/debian/patches/Check-for-physical-memory-available-also-in-PBKDF-benchma.patch
cryptsetup-2.6.1/debian/patches/Check-for-physical-memory-available-also-in-PBKDF-benchma.patch
---
cryptsetup-2.6.1/debian/patches/Check-for-physical-memory-available-also-in-PBKDF-benchma.patch
1970-01-01 01:00:00.0 +0100
+++
cryptsetup-2.6.1/debian/patches/Check-for-physical-memory-available-also-in-PBKDF-benchma.patch
2023-04-21 00:54:29.0 +0200
@@ -0,0 +1,74 @@
+From: Milan Broz
+Date: Mon, 3 Apr 2023 13:31:16 +0200
+Subject: Check for physical memory available also in PBKDF benchmark.
+
+Origin:
https://gitlab.com/cryptsetup/cryptsetup/-/commit/7893c33d71cde09e240234c484c6c468f22c2fe7
+Bug: https://gitlab.com/cryptsetup/cryptsetup/-/issues/802#note_1328592911
+Bug-Debian: https://bugs.debian.org/1028250
+---
+ lib/internal.h| 1 +
+ lib/utils_benchmark.c | 9 +
+ lib/utils_pbkdf.c | 4 ++--
+ 3 files changed, 12 insertions(+), 2 deletions(-)
+
+diff --git a/lib/internal.h b/lib/internal.h
+index 98095fa..f261cae 100644
+--- a/lib/internal.h
b/lib/internal.h
+@@ -89,6 +89,7 @@ int crypt_benchmark_pbkdf_internal(struct crypt_device *cd,
+ struct crypt_pbkdf_type *pbkdf,
+ size_t volume_key_size);
+ const char *crypt_get_cipher_spec(struct crypt_device *cd);
++uint32_t pbkdf_adjusted_phys_memory_kb(void);
+
+ /* Device backend */
+ struct device;
+diff --git a/lib/utils_benchmark.c b/lib/utils_benchmark.c
+index 728e4df..a0326ce 100644
+--- a/lib/utils_benchmark.c
b/lib/utils_benchmark.c
+@@ -101,6 +101,7 @@ int crypt_benchmark_pbkdf(struct crypt_device *cd,
+ {
+ int r, priority;
+ const char *kdf_opt;
++ uint32_t memory_kb;
+
+ if (!pbkdf || (!password && password_size))
+ return -EINVAL;
+@@ -113,6 +114,14 @@ int crypt_benchmark_pbkdf(struct crypt
