Re: Re-planning for 12.6
On Mon, Apr 01, 2024 at 01:07:27PM +0100, Adam D. Barratt wrote: > Hi, > > As we had to postpone 12.6, let's look at alternative dates. > Can do all, I think, Andy (amaca...@debian.org) > > Adam >
Bug#1068345: trixie-pu: package chromium/123.0.6312.105-1~deb13u1
Package: release.debian.org Severity: normal Tags: trixie User: release.debian@packages.debian.org Usertags: pu Given the time_t transition, several folks have requested chromium updates via t-p-u. The current version in testing (122.0.6261.57-1) has 20 CVEs that are fixed in newer versions, as well as another pretty serious bug (#1066910). I'd like to go ahead and upload 123.0.6312.105-1~deb13u1 to trixie. No packaging changes between 123.0.6312.105-1 (currently in sid) and 123.0.6312.105-1~deb13u1, other than the d/changelog entry: chromium (123.0.6312.105-1~deb13u1) trixie; urgency=high * Rebuild for trixie. -- Andres Salomon Wed, 03 Apr 2024 20:11:03 + OpenPGP_0x645D0247C36E7637.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068344: bookworm-pu: package curl/7.88.1-10+deb12u6
Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: c...@packages.debian.org, guilhe...@puida.xyz
Control: affects -1 + src:curl
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
1. Fix CVE-2004
> When a protocol selection parameter option disables all protocols
> without adding any then the default set of protocols would remain in
> the allowed set due to an error in the logic for removing protocols.
> The flaw is only present if the set of selected protocols disables the
> entire set of available protocols, in itself a command with no
> practical use and therefore unlikely to be encountered in real
> situations. The curl security team has thus assessed this to be low
> severity bug.
2. Fix CVE-2398
> When an application tells libcurl it wants to allow HTTP/2 server
> push, and the amount of received headers for the push surpasses the
> maximum allowed limit (1000), libcurl aborts the server push. When
> aborting, libcurl inadvertently does not free all the previously
> allocated headers and instead leaks the memory. Further, this error
> condition fails silently and is therefore not easily detected by an
> application.
3. Fix incorrect handling of ldap URLs for IPv6 addresses
(closes: #1053642)
[ Impact ]
As the vulnerabities are present in bookworm's curl code, they can be
exploited by malicious actors.
[ Tests ]
Upstream provides an extensive test suite, and there are no test
failures when building or running autopkgtest.
[ Risks ]
The patches introduced are not very complex, but some amount of
backporting was needed in able to apply the patches to the curl version
currently in bookworm. There is a chance of introducing some bugs here,
but the test suite should catch most of them. samueloph also reviewed my
changes.
[ 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 ]
1. Imported and backported the upstream patch that fixes CVE-2024-2004.
2. Imported and backported the upstream patch that fixes CVE-2024-2398.
3. Imported and backported the upstream patch that fixes #1053643.
--puida
diff -Nru curl-7.88.1/debian/changelog curl-7.88.1/debian/changelog
--- curl-7.88.1/debian/changelog2023-12-10 03:07:30.0 -0300
+++ curl-7.88.1/debian/changelog2024-04-02 20:02:10.0 -0300
@@ -1,3 +1,18 @@
+curl (7.88.1-10+deb12u6) bookworm; urgency=medium
+
+ * Team upload.
+
+ [ Sergio Durigan Junior ]
+ * d/p/openldap-create-ldap-URLs-correctly-for-IPv6-addresses.patch:
+(Closes: #1053643)
+
+ [ Guilherme Puida Moreira ]
+ * Add patches to fix CVE-2024-2004 and CVE-2024-2398.
+ * d/p/openldap-create-ldap-URLs-correctly-for-IPv6-addresses.patch:
+Refresh patch.
+
+ -- Guilherme Puida Moreira Tue, 02 Apr 2024 20:02:10
-0300
+
curl (7.88.1-10+deb12u5) bookworm-security; urgency=high
* Add patches to fix CVE-2023-46218 and CVE-2023-46219
diff -Nru curl-7.88.1/debian/patches/CVE-2024-2004.patch
curl-7.88.1/debian/patches/CVE-2024-2004.patch
--- curl-7.88.1/debian/patches/CVE-2024-2004.patch 1969-12-31
21:00:00.0 -0300
+++ curl-7.88.1/debian/patches/CVE-2024-2004.patch 2024-04-02
20:02:10.0 -0300
@@ -0,0 +1,135 @@
+From 17d302e56221f5040092db77d4f85086e8a20e0e Mon Sep 17 00:00:00 2001
+From: Daniel Gustafsson
+Date: Tue, 27 Feb 2024 15:43:56 +0100
+Subject: [PATCH] setopt: Fix disabling all protocols
+
+When disabling all protocols without enabling any, the resulting
+set of allowed protocols remained the default set. Clearing the
+allowed set before inspecting the passed value from --proto make
+the set empty even in the errorpath of no protocols enabled.
+
+Co-authored-by: Dan Fandrich
+Reported-by: Dan Fandrich
+Reviewed-by: Daniel Stenberg
+Closes: #13004
+
+Backported by: Guilherme Puida Moreira
+ * Small change in the Makefile to add a new test.
+
+---
+ lib/setopt.c| 16
+ tests/data/Makefile.inc | 2 +-
+ tests/data/test1474 | 42 +
+ 3 files changed, 51 insertions(+), 9 deletions(-)
+ create mode 100644 tests/data/test1474
+
+Index: curl/lib/setopt.c
+===
+--- curl.orig/lib/setopt.c
curl/lib/setopt.c
+@@ -150,6 +150,12 @@ static CURLcode setstropt_userpwd(char *
+
+ static CURLcode protocol2num(const char *str, curl_prot_t *val)
+ {
++ /*
++ * We are asked to cherry-pick protocols, so play it safe and disallow all
++ * protocols to start with, and re-add the wanted ones back in.
++ */
++ *val = 0;
++
+ if(!str)
+ return CURLE_BAD_FUNCTION_ARGUMENT;
+
+@@ -158,8 +164,6 @@ static CURLcode protocol2num(const char
+ return CURLE_OK;
+ }
+
+- *val = 0;
+-
+ do {
+ const char *token = str;
+ size_t tlen;
+@@ -2666,22 +2670,18 @@
Processed: bookworm-pu: package curl/7.88.1-10+deb12u6
Processing control commands: > affects -1 + src:curl Bug #1068344 [release.debian.org] bookworm-pu: package curl/7.88.1-10+deb12u6 Added indication that 1068344 affects src:curl -- 1068344: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068344 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1068084: bookworm-pu: package intel-microcode/3.20240312.1~deb12u1
Uploaded. On Mon, Apr 1, 2024, at 08:48, Jonathan Wiltshire wrote: > Control: tag -1 confirmed > > On Sat, Mar 30, 2024 at 07:47:05AM -0300, Henrique de Moraes Holschuh wrote: >> As requested by the security team, I would like to bring the microcode >> update level for Intel processors in Bullseye and Bookworm to match what >> we have in Sid and Trixie. This is the bug report for Bookworm, a >> separate one will be filled for Bullseye. > > Please go ahead. > > Thanks, > > -- > Jonathan Wiltshire j...@debian.org > Debian Developer http://people.debian.org/~jmw > > 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 > ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1 -- Henrique de Moraes Holschuh
Bug#1064810: Bug#1067055: openmpi: error: implicit declaration of function 'OPAL_THREAD_ADD_FETCH64'
On 02/04/2024 21:29, Sebastian Ramacher wrote: To be honest, I don't see these two changes (changing mpi-defaults to mpich on 32 bit; breaking 32 bit build of openmpi) to be ready. It'd be preferable to reinstate a 32-bit compatible pmix and fix openmpi on 32 bit until the time_t transition is done. Cheers It looks like libpmix-dev is only used by mpich, openmpi and slurm-wlm. mpich will be configured not to use pmix on 32-bit systems anyway slurm-wlm builds ok without pmix; it can be patched to use pmix only on 64-bit systems. openmpi in sid (4.1.6-7) has an internal copy of pmix 4.1.2 that it can be configured to use. I can prepare this for openmpi on the debian/trixie branch; to upload with a fix for #1067055, regards Alastair -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e:alast...@mckinstry.ie, im: @alastair:mckinstry.ie
Bug#1068326: bookworm-pu: package mksh/59c-28+deb12u1
Package: release.debian.org Severity: normal Tags: bookworm X-Debbugs-Cc: m...@packages.debian.org, t...@mirbsd.de Control: affects -1 + src:mksh User: release.debian@packages.debian.org Usertags: pu I would like to ask for pre-approval to uploading a proposed stable update for mksh. [ Reason ] There was a discussion on d-devel that ended in suggesting that the /etc/shells file should have both aliased paths for shells, not just the canonical paths, since users could have $SHELL set to either, and some software checks that $SHELL is in shells(5) for security reasons. This change landed in sid and is included here. I’ve also fixed the path wildcards for musl on ARM EABI. I’ve also taken liberty to cherry-pick a few upstream bugfixes and their relevant tests and to include two tiny FAQ updates regarding POSIX compliance and future compatibility/directions. [ Impact ] Users of mksh can run into problems with privilege elevation tools if they are on a usrmerge’d system if this is not applied, and shell scripts can fail or even segfault. [ Tests ] The backported fixes have tests covering them, which all pass when I build this in a nōn-usrmerged bookworm cowbuilder chroot (mirroring the buildd setup). I tested the maintainer script changes by installing the resulting .deb in a copy of both the nōn-usrmerged bookworm chroot and a usrmerged sid chroot. [ Risks ] The patches are small and easy to review and have been in use in sid for a while, except the three-line postinst change, which I manually tested (and inspected both dash and bash to ensure that test -ef does the right thing), so the risk is low. [ 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 ] (see Reason above) [ Other info ] I’ve split the fixes into easier to review individual patches for this upload, as git is “patches-applied” here, but I also verified the resulting trees are identical. While the test if the system is merged could possibly be removed, I decided to leave it in as it’s easier to backport this way. (When merging later, either the next upgrade or dpkg-reconfigure of mksh fixes up /etc/shells next, or the usrmerge utility does so.) diff -Nru mksh-59c/debian/changelog mksh-59c/debian/changelog --- mksh-59c/debian/changelog 2023-04-28 23:34:20.0 +0200 +++ mksh-59c/debian/changelog 2024-04-03 14:19:25.0 +0200 @@ -1,3 +1,15 @@ +mksh (59c-28+deb12u1) bookworm; urgency=low + + * d/p/typeset-p-fix.diff, d/p/dot-args-fix.diff, +d/p/crash-nest-bashism.diff: cherry-pick upstream bugfixes + * d/p/metadata-update.diff: cherry-pick relevant documentation +changes and adjust user-visible version to indicate the +above fixes were applied + * fix paths missing wildcards in lintian overrides, postinst, prerm + * cherry-pick usrmerge /etc/shells change (Closes: #1063905) + + -- Thorsten Glaser Wed, 03 Apr 2024 14:19:25 +0200 + mksh (59c-28) unstable; urgency=medium * Revert 59c-27 changes as mksh is, surprisingly, still a key diff -Nru mksh-59c/debian/mksh.lintian-overrides mksh-59c/debian/mksh.lintian-overrides --- mksh-59c/debian/mksh.lintian-overrides 2023-04-28 23:00:04.0 +0200 +++ mksh-59c/debian/mksh.lintian-overrides 2024-04-03 13:25:50.0 +0200 @@ -17,8 +17,8 @@ # correct placement mksh: executable-in-usr-lib [usr/lib/diet/bin/mksh] mksh: executable-in-usr-lib [usr/lib/klibc/bin/mksh] -mksh: executable-in-usr-lib [usr/lib/*-linux-musl/bin/mksh] +mksh: executable-in-usr-lib [usr/lib/*-linux-musl*/bin/mksh] # these are to clean old add-shell(8) damage, not actually dereferenced -mksh: bin-sbin-mismatch usr/bin/mksh -> bin/mksh [postinst] -mksh: bin-sbin-mismatch usr/bin/mksh -> bin/mksh [prerm] +mksh: bin-sbin-mismatch usr/bin/mksh* -> bin/mksh* [postinst] +mksh: bin-sbin-mismatch usr/bin/mksh* -> bin/mksh* [prerm] diff -Nru mksh-59c/debian/mksh.postinst mksh-59c/debian/mksh.postinst --- mksh-59c/debian/mksh.postinst 2023-04-28 23:00:04.0 +0200 +++ mksh-59c/debian/mksh.postinst 2024-04-03 13:27:52.0 +0200 @@ -151,14 +151,18 @@ test -e /usr/bin/ksh || test -h /usr/bin/ksh || \ ln -s /bin/ksh /usr/bin/ksh + # determine usrmerge status + um=+ + test /usr/bin/mksh -ef /bin/mksh || um=- + # add us to /etc/shells and clean up old add-shell-caused damage # shellcheck disable=SC2046 mogrifyshells + /bin/mksh /bin/mksh-static \ - - /usr/bin/mksh /usr/bin/mksh-static \ - $(for x in \ + $um /usr/bin/mksh /usr/bin/mksh-static \ + - $(for x in \ /usr/lib/klibc/bin \ /usr/lib/diet/bin \ - /usr/lib/*-linux-musl/bin \ + /usr/lib/*-linux-musl*/bin \ ; do echo "$x/mksh" "$x/mksh-static"; done)
Processed: bookworm-pu: package mksh/59c-28+deb12u1
Processing control commands: > affects -1 + src:mksh Bug #1068326 [release.debian.org] bookworm-pu: package mksh/59c-28+deb12u1 Added indication that 1068326 affects src:mksh -- 1068326: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068326 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1064810: Bug#1067055: openmpi: error: implicit declaration of function 'OPAL_THREAD_ADD_FETCH64'
On 02/04/2024 21:29, Sebastian Ramacher wrote: OpenMPI 5 drops 32-bit support, but otherwise does not change the API/ABI. So it is technically not a transition, but breaks 32-bit builds. Doesn't make it better. This is not the time to do that without tests builds and bugs filed. The solution is changing mpi-defaults to MPICH for 32-bit archs. MPICH builds on all archs, but testing all dependencies of the change has not been tested, and I don't know how you would do that - setting up eg ratt to rebuild all on 32-bit archs (as everything on 64-bit will not have changed.) Beside the easy part of chaning mpi-defaults, I count 30 something packages that have explicit build dependencies on libopenmpi-dev. None of those packages has bugs filed to change to mpich on 32 bit architectures. To be honest, I don't see these two changes (changing mpi-defaults to mpich on 32 bit; breaking 32 bit build of openmpi) to be ready. It'd be preferable to reinstate a 32-bit compatible pmix and fix openmpi on 32 bit until the time_t transition is done. Cheers I checked with "build-rdeps libopenmpi-dev" and checked the packages. They are mostly false-alarms. What is needed: * mpich not to use libpmix for 32-bit archs. I've a patch i'm testing. * armci-mpi builds on both mpich, openmpi. Needs work to only build on openmpi on 64-bit. #10683219 * code-saturne: Uses the default mpi version of hdf5. #1068318 * adios: fix just uploaded. * vtk9: Depends on libhdf5-openmpi-dev instead of libhdf5-mpi-dev. #1068321 * trilinos: deps on openmpi , but only available on 64-bit systems. No change needed * hdf5: Needs to depend on 64-bit archs for libopenmpi-dev. #1068320 * scalapack: Needs to dep on 64-bit archs only for libopenmpi-dev. #1068322 Regards Alastair -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie
