Re: Handling next linux upload to unstable
Hi Steve, On Sun, Sep 15, 2024 at 09:26:07PM +0100, Steve McIntyre wrote: > On Sun, Sep 15, 2024 at 12:31:12AM +0200, Cyril Brulebois wrote: > >Steve McIntyre (2024-09-14): > >> > >> That looks great for me, thanks. > > > >Then I think my work here is done: > > > >kibi@respighi:~$ dak ls debian-installer -s testing,unstable -a source > >debian-installer | 20240914 | testing| source > >debian-installer | 20240914 | unstable | source > > > >I'll let you give a final green light to kernel people. > > Cool. I've been a little delayed here (family medical emergency this > weekend), but I'm ready to start a build now. > > Kibi: just checking, are you happy for me to call this trixie d-i > alpha 1? Hope you and family are doing better already now. Just double-checking as well, given debian-installer moved to testing, is it now fine to do other src:linux uploads to unstable or are we yet waiting to move with other changes in? I'm happy to wait, but I think we would like to to at least another 6.10.y upload to unstable, 6.11-1~exp1 was earlier uploaded to experimental by Ben. Regards, Salvatore
Handling next linux upload to unstable (was: Re: Uploading linux (6.10.7-1))
Hi Cyril, Steve, On Wed, Sep 04, 2024 at 08:27:44AM +0200, Salvatore Bonaccorso wrote: > Hi Cyril, Steve, > > On Wed, Sep 04, 2024 at 07:51:40AM +0200, Cyril Brulebois wrote: > > Salvatore Bonaccorso (2024-09-03): > > > Right, this is sensible. We have currently the FTBFS for 6.10.7-1 for > > > riscv64 and arm64 which needs to be sorted. We either can have this > > > fixed isolated or do a 6.10.8-1 with the build failure fixes? Is this > > > near enough timewise? > > > > I don't have any preferences regarding a future wholesale 6.10.y or just > > a new revision of the current upstream release. It'd probably just make > > sense to avoid upgrading to 6.11.y since I'd guess we would get more > > things to look at. > > Yes, 6.11.y won't go to unstable anyway before 6.11 is released. So > that will take still some weeks. That means for unstable we will > continue following the 6.10.y series for now. > > In any case Aurelien worked on the FTBFS issue: > https://salsa.debian.org/kernel-team/linux/-/merge_requests/1185 > > So we would be able to have either 6.10.7-2 or 6.10.8-1 at your > preference. > > Aiming though to make 6.11.y and once ready 6.12.y go timely to > unstable as the later one is expected/likely the expected LTS version. > > > I'll let Steve comment on the preferred timings. > > Ack! So we are now there. linux/6.10.9-1 should now be able to migrate to testing, no major issues were reported so far, and I think you can let it go either with a hint or automatically to testing. In parallel I'm still working on importing other versions, 6.10.10 was released and is ready packaging wise. But now I would like to further coordinate with you. Would it be now a good time for planned d-i changes, sho should I hold back the 6.10.10-1 and later uploads? If so, could you give me (please CC me so i do not miss it) a ping when it is again fine to do an upload? Please let me know, and if there is something else I blocking you from my side. Once 6.11 would be released and we know it's stabilised in experimental we would like to move it to unstable and make the way free in experimental for 6.12-rcX, as the later is in particular important to make 6.12.y ready as this is expected to be the next LTS upstream stable version and so the one aimed for trixie. Regards, Salvatore
Bug#1081034: bookworm-pu: package ikiwiki-hosting/0.20220716-2+deb12u1
Hi Simon, Thanks for your reply, much appreciated! On Sat, Sep 07, 2024 at 07:20:14PM +0100, Simon McVittie wrote: > On Sat, 07 Sep 2024 at 12:13:20 +0200, Salvatore Bonaccorso wrote: > > We discussed this, if we should release the update for ikiwiki-hosting > > (real impact) and fcgiwrap (only autopkgtests) via a corresponding > > update or a proposed-update is enough. We prpoose the later, and let > > it go through the upcoming point release. > > Thanks for preparing this. The changes seem good to me, unless someone with > more git knowledge knows a better way to achieve this (see #1076750). At least this matches what we currently have in unstable, so I proceeded with the actual upload afer your above "looks good to me" (and pushed it as well to the git repo, but let me know if I did something you do not like that way in the repo). > > the proposed debdiff [...] still > > contains the debian/.gitignore removal > > I assume you're using debuild -I, which excludes various files including > .gitignore, resulting in a diff between the git tree on Salsa and the > source package in the archive (and therefore also the dgit view). > > I normally build source packages with just -I.git (plus some other > specific patterns like vim swapfiles, but not -I) to avoid having > debian/**/.gitignore disappear, so the 0.20220716-2 currently in bookworm > will have been built like that. But that isn't a functional change and > shouldn't have any effect on the built binaries. Yes the final upload done now was done via dpkg-buildpackage -S -d -nc -I.git now to have the .gitignore files still included as previously. (fcgiwrap has been uploaded as well, but that is for the other bug). That means I think we now could release the git update through security, knowning at least the fallouts for handle for the next point release. Thanks again a lot for your time! Regards, Salvatore
Bug#1081035: bookworm-pu: package fcgiwrap/1.1.0-14+deb12u1
Package: release.debian.org Severity: normal Tags: bookworm X-Debbugs-Cc: fcgiw...@packages.debian.org, t...@security.debian.org, Jonathan Nieder , Jordi Mallach , car...@debian.org Control: affects -1 + src:fcgiwrap User: release.debian@packages.debian.org Usertags: pu Hi We (security-team) plan to release an update of git fixing several CVEs, prepared by Jonathan Nieder and rebasing git version to 2.39.5 upstream, which uncovered regressions in both fcgiwrap (#1072394) and ikiwiki-hosting (cf. #1076751). They were triggered as well in autopkgtests with the prepared git/1:2.39.5-0+deb12u1 version. We discussed this, if we should release the update for ikiwiki-hosting (real impact) and fcgiwrap (only autopkgtests) via a corresponding update or a proposed-update is enough. We prpoose the later, and let it go through the upcoming point release. Attached ist the proposed debdiff for fcgiwrap. I have not yet uploaded the package, but CC'ing Jordi. Regards, Salvatore diff -Nru fcgiwrap-1.1.0/debian/changelog fcgiwrap-1.1.0/debian/changelog --- fcgiwrap-1.1.0/debian/changelog 2022-12-17 18:23:54.0 +0100 +++ fcgiwrap-1.1.0/debian/changelog 2024-09-07 11:31:30.0 +0200 @@ -1,3 +1,13 @@ +fcgiwrap (1.1.0-14+deb12u1) bookworm; urgency=medium + + [ Mitchell Dzurick ] + * d/t/git-http-backend: make www-data own $AUTOPKGTEST_TMP/test1/.git +git introduced more aggressive security checking, so the dep8 test needs +to explicitly change ownership of the new git directory. +(LP: #2067942, Closes: #1072394) + + -- Salvatore Bonaccorso Sat, 07 Sep 2024 11:31:30 +0200 + fcgiwrap (1.1.0-14) unstable; urgency=medium * Brown paper bag release. diff -Nru fcgiwrap-1.1.0/debian/tests/git-http-backend fcgiwrap-1.1.0/debian/tests/git-http-backend --- fcgiwrap-1.1.0/debian/tests/git-http-backend2022-11-21 18:05:05.0 +0100 +++ fcgiwrap-1.1.0/debian/tests/git-http-backend2024-09-07 11:30:46.0 +0200 @@ -12,6 +12,7 @@ git init test1 git -C test1 commit --allow-empty -m test +chown -R www-data:www-data "$AUTOPKGTEST_TMP"/test1/.git tee /etc/nginx/sites-available/default <
Bug#1081034: bookworm-pu: package ikiwiki-hosting/0.20220716-2+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: ikiwiki-host...@packages.debian.org, t...@security.debian.org,
Jonathan Nieder , Simon McVittie ,
car...@debian.org
Control: affects -1 + src:ikiwiki-hosting
User: release.debian@packages.debian.org
Usertags: pu
Hi
We (security-team) plan to release an update of git fixing several
CVEs, prepared by Jonathan Nieder and rebasing git version to 2.39.5
upstream, which uncovered regressions in both fcgiwrap (#1072394) and
ikiwiki-hosting (cf. #1076751).
They were triggered as well in autopkgtests with the prepared
git/1:2.39.5-0+deb12u1 version.
We discussed this, if we should release the update for ikiwiki-hosting
(real impact) and fcgiwrap (only autopkgtests) via a corresponding
update or a proposed-update is enough. We prpoose the later, and let
it go through the upcoming point release.
Attached ist the proposed debdiff for ikiwiki-hosting (note it still
contains the debian/.gitignore removal I would need to check why I
could not properly exclude it).
I have not yet uploaded the package, but CC'ing Simon.
Regards,
Salvatore
diff -Nru ikiwiki-hosting-0.20220716/debian/.gitignore
ikiwiki-hosting-0.20220716/debian/.gitignore
--- ikiwiki-hosting-0.20220716/debian/.gitignore2023-03-30
11:56:12.0 +0200
+++ ikiwiki-hosting-0.20220716/debian/.gitignore1970-01-01
01:00:00.0 +0100
@@ -1,8 +0,0 @@
-*.debhelper
-*.debhelper.log
-*.substvars
-/files
-/ikiwiki-hosting-common/
-/ikiwiki-hosting-dns/
-/ikiwiki-hosting-web/
-/tmp/
diff -Nru ikiwiki-hosting-0.20220716/debian/changelog
ikiwiki-hosting-0.20220716/debian/changelog
--- ikiwiki-hosting-0.20220716/debian/changelog 2023-03-30 11:56:12.0
+0200
+++ ikiwiki-hosting-0.20220716/debian/changelog 2024-09-07 11:38:42.0
+0200
@@ -1,3 +1,13 @@
+ikiwiki-hosting (0.20220716-2+deb12u1) bookworm; urgency=medium
+
+ [ Simon McVittie ]
+ * d/ikiwiki-hosting-web.{init,service}: Allow reading other users'
repositories.
+Each website's git repository is owned by its own uid, and the
+git-daemon running as ikiwiki-anon needs to be able to read them all.
+(Closes: #1076751)
+
+ -- Salvatore Bonaccorso Sat, 07 Sep 2024 11:38:42 +0200
+
ikiwiki-hosting (0.20220716-2) unstable; urgency=medium
* d/p/ikisite-backup-Create-the-bundle-as-the-site-s-user.patch:
diff -Nru ikiwiki-hosting-0.20220716/debian/ikiwiki-hosting-web.init
ikiwiki-hosting-0.20220716/debian/ikiwiki-hosting-web.init
--- ikiwiki-hosting-0.20220716/debian/ikiwiki-hosting-web.init 2023-03-30
11:56:12.0 +0200
+++ ikiwiki-hosting-0.20220716/debian/ikiwiki-hosting-web.init 2024-09-07
11:37:47.0 +0200
@@ -42,6 +42,10 @@
# 2 if daemon could not be started
start-stop-daemon --start --chuid $gitdaemonuser:$gitdaemonuser --quiet
--pidfile $PIDFILE --exec $DAEMON --test > /dev/null \
|| return 1
+
+ export GIT_CONFIG_COUNT=1
+ export GIT_CONFIG_KEY_0=safe.directory
+ export GIT_CONFIG_VALUE_0='*'
start-stop-daemon --start --chuid $gitdaemonuser:$gitdaemonuser --quiet
--make-pidfile --pidfile $PIDFILE --background --exec $DAEMON -- \
$DAEMON_ARGS \
|| return 2
diff -Nru ikiwiki-hosting-0.20220716/debian/ikiwiki-hosting-web.service
ikiwiki-hosting-0.20220716/debian/ikiwiki-hosting-web.service
--- ikiwiki-hosting-0.20220716/debian/ikiwiki-hosting-web.service
2023-03-30 11:56:12.0 +0200
+++ ikiwiki-hosting-0.20220716/debian/ikiwiki-hosting-web.service
2024-09-07 11:37:47.0 +0200
@@ -9,6 +9,11 @@
User=ikiwiki-anon
Group=ikiwiki-anon
Restart=on-failure
+# ikiwiki-anon needs to be willing to serve the git repositories of
+# websites owned by each site-specific uid
+Environment=GIT_CONFIG_COUNT=1
+Environment=GIT_CONFIG_KEY_0=safe.directory
+Environment=GIT_CONFIG_VALUE_0=*
[Install]
WantedBy=multi-user.target
Uploading linux (6.10.8-1)
Hi I would like to upload linux version 6.10.8-1 to unstable. This imports on top 6.10.8 only. It addresses additionally #1079167. There are changes to address the current FTBFS on arm64 and riscv64: [ Aurelien Jarno ] * [riscv64] udeb: Ship mtd in kernel-image, drop mtd-core-modules and add it to to Provides of kernel-image. [ Marcin Juszkiewicz ] * [udeb] introduce drm-core-modules to handle 'kernel-image' modules which require 'drm' module * [arm64] udeb: ship mtd in kernel-image, drop mtd-core-modules and add it to to provides of kernel-image. * [arm64] udeb: ship typec in kernel-image Cyril and Steve were asking for coordination/not blocking the upcoming debian-installer updates for trixie/unstable, so including explicitly both as recipients for their ack/nack on the timing, cf. https://lists.debian.org/debian-release/2024/09/msg00037.html Ideally we have with the fixes for the FTBFS no new RC level issues, so that this transition of linux to testing can happen. Regards, Salvatore signature.asc Description: PGP signature
Re: Uploading linux (6.10.7-1)
Hi Cyril, Steve, On Wed, Sep 04, 2024 at 07:51:40AM +0200, Cyril Brulebois wrote: > Salvatore Bonaccorso (2024-09-03): > > Right, this is sensible. We have currently the FTBFS for 6.10.7-1 for > > riscv64 and arm64 which needs to be sorted. We either can have this > > fixed isolated or do a 6.10.8-1 with the build failure fixes? Is this > > near enough timewise? > > I don't have any preferences regarding a future wholesale 6.10.y or just > a new revision of the current upstream release. It'd probably just make > sense to avoid upgrading to 6.11.y since I'd guess we would get more > things to look at. Yes, 6.11.y won't go to unstable anyway before 6.11 is released. So that will take still some weeks. That means for unstable we will continue following the 6.10.y series for now. In any case Aurelien worked on the FTBFS issue: https://salsa.debian.org/kernel-team/linux/-/merge_requests/1185 So we would be able to have either 6.10.7-2 or 6.10.8-1 at your preference. Aiming though to make 6.11.y and once ready 6.12.y go timely to unstable as the later one is expected/likely the expected LTS version. > I'll let Steve comment on the preferred timings. Ack! Regards, Salvatore
Re: Uploading linux (6.10.7-1)
Hi Cyril, On Tue, Sep 03, 2024 at 05:28:38PM +0200, Cyril Brulebois wrote: > Ciao Salvatore, > > [ftpmaster@ dropped.] > > Salvatore Bonaccorso (2024-08-31): > > I would like to upload linux version 6.10.7-1 to unstable. This is the > > import of the stable series up to 6.10.7. It addresses as well two for > > now known CVEs assigned for issues fixed with 6.10.7. > > > > No packaging changes are done in this update (apart a patch refresh > > for offsets). > > Once you reach a situation were linux is a candidate for migration and > reaches testing, please sync with Steve and me before further uploads. > > We'd like to try and get debian-installer into unstable and into > testing, to clear the path for SB-related things (as requested by > Steve). Right, this is sensible. We have currently the FTBFS for 6.10.7-1 for riscv64 and arm64 which needs to be sorted. We either can have this fixed isolated or do a 6.10.8-1 with the build failure fixes? Is this near enough timewise? Regards, Salvatore
Uploading linux (6.10.7-1)
Hi, I would like to upload linux version 6.10.7-1 to unstable. This is the import of the stable series up to 6.10.7. It addresses as well two for now known CVEs assigned for issues fixed with 6.10.7. o packaging changes are done in this update (apart a patch referesh for offsets). Regards, Salvatore signature.asc Description: PGP signature
Bug#1054915: bookworm-pu: package freerdp2/2.11.2+dfsg1-1~deb12u1
Hi Tobi, On Sat, Jun 22, 2024 at 08:46:39PM +0200, Salvatore Bonaccorso wrote: > Hi Tobi, > > On Wed, Feb 21, 2024 at 08:00:42AM +, Jonathan Wiltshire wrote: > > Control: tag -1 moreinfo > > > > Hi, > > > > On Sat, Oct 28, 2023 at 05:58:38PM +0200, Tobias Frost wrote: > > > Backporting the fixes is of course possible, but bears a significant > > > risk for regression, therefor I would prefer to use the new upstream > > > version, given also that upstream changes are only a few and fixing > > > also a few bugs that would be nice to be fixed. > > > > It's a balancing act, as always. I'm OK with new upstream releases if they > > are small enough to sensibly review (or an upstream with a good trusted > > history, which I don't yet have for freerdp2). If you think a new upstream > > is reasonable, let's see how it looks. > > > > Either way we need a source debdiff please. > > Did you saw the followup question from Jonathan? Friendly ping :). Note we are late for the 12.7 point release now, but it still should ideally make it for 12.8. Regards, Salvatore
Uploading linux (6.10.6-1)
Hi, I would like to upload linux version 6.10.6-1 to unstable. This is the import of the stable series up to 6.10.6. No packaging changes are done in this update. Regards, Salvatore signature.asc Description: PGP signature
Bug#1076504: bookworm-pu: package qemu/1:7.2+dfsg-7+deb12u7
Hi, On Sun, Aug 18, 2024 at 02:39:09PM +0200, Salvatore Bonaccorso wrote: > Hi, > > On Sat, Aug 17, 2024 at 05:34:45PM +0100, Adam D. Barratt wrote: > > Control: tags -1 + confirmed > > > > On Wed, 2024-07-17 at 15:15 +0300, Michael Tokarev wrote: > > > [ Reason ] > > > There were 2 qemu stable/bugfix releases (7.2.12 and 7.2.13) since > > > the previous debian release, fixing a number of various issues. > > > It would be nice to have these fixes in debian too, so debian users > > > will benefit from the qemu stable series. > > > > > > Among others, this release fixes an important security issue: > > > CVE-2024-4467, #1075824. > > > > > > Unfortunately, this release does not include fix for CVE-2024-6505 > > > (#1075919), since no information about this one is known at this > > > time. > > [...] > > > Maybe it's better to push this update through debian-security > > > instead of regular stable-proposed-updates. Cc'ing > > > team@security.d.o for this. Or maybe it's better to include > > > just the CVE-2024-4467 fix now in a security update, and revert > > > it for next s-p-u which includes whole upstream thing. > > > > It looks like nothing happened there? > > Sorry for not replying. > > Yes, please let it have fixed via the upcoming point release. Ah, actually I guess there was no CC at least cannot fine earlier question. But as said the no-dsa entry was already added earlier so at this point and given the point release is on 31th, a point release update including the fix would be welcome. Regards, Salvatore
Bug#1076504: bookworm-pu: package qemu/1:7.2+dfsg-7+deb12u7
Hi, On Sat, Aug 17, 2024 at 05:34:45PM +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Wed, 2024-07-17 at 15:15 +0300, Michael Tokarev wrote: > > [ Reason ] > > There were 2 qemu stable/bugfix releases (7.2.12 and 7.2.13) since > > the previous debian release, fixing a number of various issues. > > It would be nice to have these fixes in debian too, so debian users > > will benefit from the qemu stable series. > > > > Among others, this release fixes an important security issue: > > CVE-2024-4467, #1075824. > > > > Unfortunately, this release does not include fix for CVE-2024-6505 > > (#1075919), since no information about this one is known at this > > time. > [...] > > Maybe it's better to push this update through debian-security > > instead of regular stable-proposed-updates. Cc'ing > > team@security.d.o for this. Or maybe it's better to include > > just the CVE-2024-4467 fix now in a security update, and revert > > it for next s-p-u which includes whole upstream thing. > > It looks like nothing happened there? Sorry for not replying. Yes, please let it have fixed via the upcoming point release. Regards, Salvatore
Bug#1008164: RM: obfs4proxy/0.0.8-1
Hi, On Wed, Aug 14, 2024 at 08:54:51AM +0200, Clément Hermann wrote: > Hi, > > Sorry, the emails went to a strange filter. Pinging on IRC was a good move. > ;) :-) glad it was of help! > Le 12/08/2024 à 22:38, Adam D. Barratt a écrit : > > Re-ping, given that we're less than three weeks from the final bullseye > > point release. > > > > Regards, > > > > Adam > > > > > > On Mon, 2024-07-08 at 19:24 +0100, Jonathan Wiltshire wrote: > > > Hi, > > > > > > Ping on this? Adding the maintenance list as well. > > > > > > Thanks. > > > > > > On Sat, Aug 05, 2023 at 11:05:52PM +0200, Moritz Mühlenhoff wrote: > > > > Am Mon, Jul 31, 2023 at 08:05:29AM +0100 schrieb Jonathan > > > > Wiltshire: > > > > > Hi, > > > > > > > > > > On Mon, Jul 04, 2022 at 07:36:12PM +0100, Adam D. Barratt wrote: > > > > > > Control: retitle -1 RM: obfs4proxy -- RoM; security issues > > > > > > Control: tags -1 + moreinfo > > > > > > > > > > > > On Sat, 2022-03-26 at 21:21 +0100, Paul Gevers wrote: > > > > > > > Control: tag -1 bullseye > > > > > > > > > > > > > > Hi Ana, > > > > > > > > > > > > > > On 23-03-2022 13:13, Ana Custura wrote: > > > > > > > > Opening this bug after a recomendation from debian- > > > > > > > > security. > > > > > > > > Version 0.0.8 of obfs4proxy has a security bug, which has > > > > > > > > only been > > > > > > > > fixed in a later > > > > > > > > version (0.0.13, see bug number #1004374), and also suffers > > > > > > > > from > > > > > > > > incompatibilty issues > > > > > > > > with later versions of the package. Version 0.0.13 is > > > > > > > > already in > > > > > > > > bullseye-backports. > > > > > > > > > > > > > > So this want's removal from bullseye, setting the right tag > > > > > > > to have > > > > > > > it on the radar of the SRM. > > > > > > > > > > > > obfs4proxy has a reverse-dependency in bullseye: > > > > > > > > > > > > Checking reverse dependencies... > > > > > > # Broken Depends: > > > > > > onionshare: onionshare > > > > > > > > > > > > Dependency problem found. > > > > > > > > > > This remains unresolved - obfs4proxy cannot be removed while > > > > > onionshare > > > > > depends on it. Security team - is removal your recommendation? > > > > > How can the > > > > > dependency be resolved? > > > > > > > > Let's add the onionshare maintainer to CC. > > > > > > > > In #1004375 onionshare demoted the dependency on obfs4proxy to a > > > > Recommends, > > > > can we apply the same to onionshare 2.2 from Bullseye? > > In my opinion, it should work. I hope to be able to test later today and > will report then. Ack! Just a reminder: Just make sure we have the uploads in place before 25th of august, where the window for uploads closes for the last point release. Regards, Salvatore
Bug#1077584: bullseye-pu: package putty/0.74-1+deb11u2
Hi, On Sat, Aug 10, 2024 at 08:49:43PM +0100, Jonathan Wiltshire wrote: > Control: tag -1 confirmed > > Hi, > > On Tue, Jul 30, 2024 at 08:02:31AM +, Bastien Roucariès wrote: > > [ Reason ] > > Security fix CVE-2024-31497 > > If you're sure this shouldn't be a DSA, please go ahead. Just to confirm: yes it does not warrant a DSA and we marked it no-dsa in the security-tracker earlier. So for the last point release is fine. Regards, Salvatore
Uploading linux (6.10.4-1)
Hi I would like to upload linux version 6.10.4-1 to unstable. This is the import of one single stable version on top of the version now migrated to testing. No packaging changes are done. Regards, Salvatore signature.asc Description: PGP signature
Uploading linux (6.9.12-1)
Hi I would like to upload linux version 6.9.12-1. This is a small increment on top of 6.9.11 but notably it fixes CVE-2024-41090 and CVE-2024-41091, cf. https://www.openwall.com/lists/oss-security/2024/07/24/4 . No packaging changes are done. Regards, Salvatore signature.asc Description: PGP signature
Uploading linux (6.9.11-1)
Hi I would like to upload linux version 6.9.11-1 later today to unstable. It just imports one upstream stable version 6.9.11 on top of what now migrated to testing (6.9.10-1). No packaging changes are done. Regards, Salvatore signature.asc Description: PGP signature
Uploading linux (6.9.10-1)
Hi I would like to upload linux version 6.9.10-1 later today to unstable. It just imports one upstream stable version 6.9.10 on top of what now migrated to testing (6.9.9-1). No packaging changes are done. Regards, Salvatore signature.asc Description: PGP signature
Bug#1076460: bullseye-pu: package nfs-utils/1:1.3.4-6+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
X-Debbugs-Cc: nfs-ut...@packages.debian.org, Sven-Haegar Koch
, car...@debian.org
Control: affects -1 + src:nfs-utils
User: release.debian@packages.debian.org
Usertags: pu
Dear stable release managers,
[ Reason ]
The kernel update for bullseye, from 5.10.218-1 to 5.10.221-1
(released as DSA DSA-5730-1), had in the 5.10.220 upstream release a
major backport of the NFS tstack. As it turns out that broke with the
old version of nfs-utils we have in bullseye the NFS re-exports.
[ Impact ]
Users which had such configurations under bullseye, to re-exprot over
NFS NFS mounted shares are not able to do so anymore with the update
to 5.10.221-1 (and possibly later, since not likely that there will be
a revert of the breaking change).
NFS re-export documentation had as well the note:
You'll need nfs-utils at least 1.3.5 (specifically, 3f520e8f6f5
"exportfs: Make sure pass all valid export flags to nfsd"). Otherwise,
on recent kernels, attempts to re-export NFS will likely result in
"exportfs: does not support NFS export".
But until now 5.10.y had the old NFS stack where this did not cause
problems.
[ Tests ]
Sven-Haegar did explicitly test the nfs-utils package containing the
fix with such a configuration assessing that cherry-picking the
required upstream commit fixes the issue.
[ Risks ]
The commit is taken from the 1.3.5 nfs-utils series, where in bullseye
we have the 1.3.4 based one. The patch applies logically without
problems (with offsets). The commit makes sure that exportfs pass all
the flags to nfsd.
[ 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 above.
[ Other info ]
Technically one could argue this should go out via the
security-archive given the kernel did change in respect of the
breaking the old version of nfs-utils in bullseye. My argument is to
not have to force people not affected by this particular regression to
have updating the nfs-utils package, but rather batch the update in
the last bullseye point release (and depending if SRM see it fit, make
a SUA so affected users still could fetch the package earlier).
Let me know if you believe this should be handled differently.
Regards,
Salvatore
diff -Nru nfs-utils-1.3.4/debian/changelog nfs-utils-1.3.4/debian/changelog
--- nfs-utils-1.3.4/debian/changelog2021-06-28 09:15:06.0 +0200
+++ nfs-utils-1.3.4/debian/changelog2024-07-16 20:37:00.0 +0200
@@ -1,3 +1,9 @@
+nfs-utils (1:1.3.4-6+deb11u1) bullseye; urgency=medium
+
+ * exportfs: Make sure pass all valid export flags to nfsd (Closes: #1076448)
+
+ -- Salvatore Bonaccorso Tue, 16 Jul 2024 20:37:00 +0200
+
nfs-utils (1:1.3.4-6) unstable; urgency=medium
* mountstats: Remove a shebang
diff -Nru
nfs-utils-1.3.4/debian/patches/exportfs-Make-sure-pass-all-valid-export-flags-to-nf.patch
nfs-utils-1.3.4/debian/patches/exportfs-Make-sure-pass-all-valid-export-flags-to-nf.patch
---
nfs-utils-1.3.4/debian/patches/exportfs-Make-sure-pass-all-valid-export-flags-to-nf.patch
1970-01-01 01:00:00.0 +0100
+++
nfs-utils-1.3.4/debian/patches/exportfs-Make-sure-pass-all-valid-export-flags-to-nf.patch
2024-07-16 20:37:00.0 +0200
@@ -0,0 +1,60 @@
+From: Kinglong Mee
+Date: Wed, 4 Jan 2017 09:20:00 -0500
+Subject: exportfs: Make sure pass all valid export flags to nfsd
+Origin:
https://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=63f520e8f6f5f9b1182901b418f11dc531a5ffc8
+Bug-Debian: https://bugs.debian.org/1076448
+
+test_export pass a export flags only marks NFSEXP_FSID,
+nfsd may want other flags for export checking.
+This patch make sure exportfs pass all other flags to nfsd.
+
+Signed-off-by: Kinglong Mee
+Signed-off-by: Steve Dickson
+---
+ utils/exportfs/exportfs.c | 12 +++-
+ 1 file changed, 7 insertions(+), 5 deletions(-)
+
+diff --git a/utils/exportfs/exportfs.c b/utils/exportfs/exportfs.c
+index 15a15835a01f..bacf106180e1 100644
+--- a/utils/exportfs/exportfs.c
b/utils/exportfs/exportfs.c
+@@ -473,8 +473,10 @@ static int can_test(void)
+ return 1;
+ }
+
+-static int test_export(char *path, int with_fsid)
++static int test_export(nfs_export *exp, int with_fsid)
+ {
++ char *path = exp->m_export.e_path;
++ int flags = exp->m_export.e_flags | (with_fsid ? NFSEXP_FSID : 0);
+ /* beside max path, buf size should take protocol str into account */
+ char buf[NFS_MAXPATHLEN+1+64] = { 0 };
+ char *bp = buf;
+@@ -487,7 +489,7 @@ static int test_export(char *path, int with_fsid)
+ qword_add(&bp, &len, path);
+ if (len < 1)
+ return 0;
+- snprintf(bp, len, " 3 %d 65534 65534 0\n", with_fsid ? NFSEXP_FSID : 0);
++ snprintf(bp, len, " 3 %d 65534 65534 0
Bug#1076335: bookworm-pu: package libvirt/9.0.0-4
Hi Andrea, On Sun, Jul 14, 2024 at 05:15:58PM +0200, Andrea Bolognani wrote: [...] > The only thing that strikes me as a bit odd and we might need to > rectify is that CVE-2024-2496, while properly tracked in the Debian > security tracker, doesn't have a corresponding Debian bug. Should one > be filed? This is (but a SRM might correct me), is not strictly necessary as it can be verified as well from the security-tracker that the upper suites have the fix as well already. Regards, Salvatore
Bug#1076271: bookworm-pu: package dmitry
Hi, On Sat, Jul 13, 2024 at 02:37:32PM +0200, Petter Reinholdtsen wrote: > > Package: release.debian.org > Affects: dmitry > > The https://tracker.debian.org/pkg/dmitry > package in stable, > version 1.3a-1.2, got a few security issues that could be fixed. These > are CVE-2024-31837, CVE-2020-14931 and CVE-2017-7938. I would like to > update these in bookworm, and have prepared the change in the git > repository, in the debian/bookworm branch. Here is the complete > proposed patch, including an update of the maintainer to reflect that > the package is orphaned. > > diff --git a/debian/changelog b/debian/changelog > index 2ebd04d..5f23771 100644 > --- a/debian/changelog > +++ b/debian/changelog > @@ -1,3 +1,14 @@ > +dmitry (1.3a-1.2+deb12u1) UNRELEASED; urgency=medium > + > + * QA upload. > + > + * Fix format string bug (#3). > + * Fix handling externally-controlled format strings and buffer overflows > + * Do not let frmtdbuff overflow in nic_format_buff. > + * Switched maintainer to QA group, to reflect the packages orphaned state. Can you add as well the known CVE id references to the debian/changelog entries, which will facilitate the tracking of the fix? Regards, Salvatore
Uploading linux (6.9.9-1)
Hi I would like to upload linux version 6.9.9-1 later today to unstable. It just imports one upstream stable version 6.9.9 on top of what now migrated to testing and is in unstable. No packaging changes are done. Regards, Salvatore signature.asc Description: PGP signature
Uploading linux (6.9.8-1)
Hi
I would like to upload linux version 6.9.8-1 later today to unstable.
It just imports one upstream stable version 6.9.8 on top of what we
currently have in unstable.
Packaging changes include:
* [rt] Drop "pinctrl: renesas: rzg2l: Use
spin_{lock,unlock}_irq{save,restore}" (applied upstream)
* d/rules.real: Revert workaround to explicitly remove executable bits from
dtb files (implemented upstream)
Regards,
Salvatore
Bug#1074059: bookworm-pu: package nodejs/18.19.0+dfsg-6~deb12u2
Hi, On Wed, Jul 03, 2024 at 11:36:46PM +0200, Jérémy Lal wrote: > Le mer. 3 juil. 2024 à 23:04, Andres Salomon a écrit : > > > > > > > On 6/25/24 16:34, Jérémy Lal wrote: > > > > > > > > > Le mar. 25 juin 2024 à 22:22, Salvatore Bonaccorso > > <mailto:car...@debian.org>> a écrit : > > [...] > > > > > > Thanks a lot for your work Adrian. Please note that there is > > currently > > > a nodejs upload pending for releasing via a DSA, which will rebase > > > nodejs to 18.20.3+dfsg-1~deb12u1 so this might invalidate those > > > changes. > > > > > > Jérémy, Aron is that something you want to have included in your > > > prepared update? > > > > > > > > > Indeed, it's applied to 18.20.3+dfsg-1~deb12u1, along with other skipped > > > tests. > > > I'll resume work on this by the end of the week. > > > > > > > While we wait for this, is there any reason to keep the existing > > 18.20.3+dfsg-1~deb12u1 upload in the embargoed security queue? Security > > packages are actively building against it, which is a bit of a problem > > for reproducibility. Someone actually asked me about oddities in the > > chromium package that was originally built for bookworm-security, and > > now sits in the 12.6 point release. It turns out that it built against > > the embargoed nodejs, but since that nodejs package was never released, > > they can't use it to reproduce the chromium in 12.6. > > > > If there's a new nodejs bookworm-security package being uploaded at some > > point and the currently embargoed nodejs package will never be released, > > perhaps we should REJECT it now? > > > > Sorry, probably me being overbooked here. > I was supposed to check the regressions against it, and been on another job > since then. Aron is taking care of the DSA, so I do not want to interfer here with his planning, but sharing an idea: There will be an upcoming release for nodejs on Monday, 8th (actually was planned for today): https://nodejs.org/en/blog/vulnerability/july-2024-security-releases Do you think you will be less overbooked, can review the regression report and with Aron's help work on fixing the new CVEs for mondays release and we base the update upon that? Again, I do not mean to interfer here with Aron was thinking about releasing the packages. Regards, Salvatore
Uploading linux 6.9.6-1
Hi
I would like to upload linux version 6.9.6-1 later today to unstable,
which moves the 6.9.y series to unstable, replacing the already EOLed
6.8.y series.
Some packaging changes are included:
* [x86] Refresh "intel-iommu: Add option to exclude integrated GPU only"
* [x86] Refresh "intel-iommu: Add Kconfig option to exclude iGPU by default"
* [rt] Drop "drm/i915/gt: Queue and wait for the irq_work item."
* [arm64] Disable RELR.
Temporarily disable RELR relocation packing to workaround failing boots
on arm64 with recent binutils/2.42.50.20240618-1, cf. #1074111.
* lib/python/debian_linux: Fix two E201/E202 whitespace errors
* Drop "sched: Do not enable autogrouping by default" patch (Closes:
#1070083)
* [rt] init: Disable SCHED_AUTOGROUP on RT configurations
* [riscv64] crypto: enable CRYPTO_AES_RISCV64, CRYPTO_CHACHA_RISCV64,
CRYPTO_GHASH_RISCV64, CRYPTO_SHA256_RISCV64, CRYPTO_SHA512_RISCV64 as
modules.
* [riscv64] Improve Microchip Polarfire support: enable
POLARFIRE_SOC_AUTO_UPDATE and USB_MUSB_POLARFIRE_SOC as modules.
* [riscv64] Improve T-Head TH1520 support: enable MMC_SDHCI_OF_DWCMSHC as
module.
* [riscv64] Improve VisionFive 2 support: enable SND_DESIGNWARE_I2S,
SND_SIMPLE_CARD and SND_SOC_JH7110_PWMDAC as modules.
* [riscv64] Improve JH7110 support: enable STARFIVE_STARLINK_PMU as module.
* [amd64] drivers/tee: Enable TEE as module (Closes: #1063161)
* New target in debian/rules: "clean-generated" cleans up all auto-generated
files inside the ./debian directory
* [arm64,riscv64] drivers/leds/rgb: Enable LEDS_GROUP_MULTICOLOR as module
* [arm64] drivers/leds/rgb: Enable LEDS_PWM_MULTICOLOR as module
* [arm*,riscv64] drivers/pps/clients: Enable PPS_CLIENT_GPIO as module
* [rt] Update to 6.9-rt5
* [rt] pinctrl: renesas: rzg2l: use spin_{lock,unlock}_irq{save,restore}
* d/signing_templates/rules.real: Consistently define REAL_VERSION variable
* d/signing_templates: Define BUILD_DIR and STAMPS_DIR, and clean those dirs
* d/signing_templates/rules.real: Use an intermediate install directory
* Revert "Revert "Run dh_movetousr also in signed images."", as this now
works
* firmware_loader: Remove most Debian-specific logging changes
(Closes: #1040738):
- Revert "firmware_class: Refer to Debian wiki page when logging missing
firmware"
- Revert "firmware: Remove redundant log messages from drivers"
- Revert "firmware_class: Log every success and failure against given
device" (Closes: #857198, #966218)
- firmware_loader: Log direct loading failures as info for d-i
* d/rules.d/tools/tracing/rtla: Delete redundant sed command
* [arm64] Enable support for various MediaTek SoCs:
- Enable COMMON_CLK_MT8188 and related clocks, COMMON_CLK_MT8365 and
related clocks, and COMMON_CLK_MT8195_IPESYS as modules
- Enable pin controllers for MT2712, MT6765, MT6779, MT6795, MT6797,
MT7622, MT7981, MT7986, MT8167, MT8186, MT8188, MT8192, MT8365,
MT8516, MT6397
- Enable REGULATOR_MT6357, REGULATOR_MT6360 as modules
- Enable CHARGER_MT6360 and TYPEC_MT6360 as modules
- Enable REALTEK_PHY, DWMAC_MEDIATEK as modules
- Enable MTK_DEVAPC as a module
* [arm64] Enable more clock drivers for various MediaTek SoCs:
- Enable COMMON_CLK_MT2712, COMMON_CLK_MT6779, COMMON_CLK_MT6795,
COMMON_CLK_MT7622, COMMON_CLK_MT7986, COMMON_CLK_MT8167,
COMMON_CLK_MT8186, COMMON_CLK_MT8192, COMMON_CLK_MT8516,
and all their related clocks as modules
- Enable COMMON_CLK_MT6765, COMMON_CLK_MT6797, COMMON_CLK_MT7981 as
built-in (no module choice) and enable all their related clocks as
modules
* [x86] drivers/pinctrl/intel: Enable PINCTRL_METEORLAKE and
PINCTRL_METEORPOINT as modules (Closes: #1071551)
* [riscv64] Improve support for StarFive VisionFive 2:
- Enable SIFIVE_CCACHE
- Enable USB_CDNS_SUPPORT, USB_CDNS3, USB_CDNS3_STARFIVE as modules and
enable CDNS3_GADGET and CDNS3_HOST options
- Enable USB_GADGET as module
* linux-image: postrm: Remove modules.weakdep on purge.
Notably we do disable CONFIG_RELR on arm64, context ist in #1074111 for
binutils until that is fixed binutils upstream. Current discussion in
https://sourceware.org/bugzilla/show_bug.cgi?id=31924 .
Regards,
Salvatore
signature.asc
Description: PGP signature
Bug#1074059: bookworm-pu: package nodejs/18.19.0+dfsg-6~deb12u2
Hi all, On Sat, Jun 22, 2024 at 06:26:23PM +0300, Adrian Bunk wrote: > Package: release.debian.org > Severity: normal > Tags: bookworm > User: release.debian@packages.debian.org > Usertags: pu > X-Debbugs-Cc: secur...@debian.org, Debian Javascript Maintainers > , Jérémy Lal > > This upload aims at fixing the failing build of 18.19.0+dfsg-6~deb12u1 > on mips64el and mipsel. > > The changes are: > - copy mips/flaky_tests.patch with mips64el skip/flaky from 18.19.1+dfsg-6 > - add test-http2-forget-closed-streams to flaky on mips64el > - skip two failing tests on mipsel > > This is based on reading the output of the build failures last night > with some testing done on amd64. > > I am kinda optimistic that it will work and even in the worst case > it shouldn't make anything worse, but there is not enough time to > properly verify it on MIPS before the point release deadline. > > I've just uploaded it, feel free to accept or reject it. > diffstat for nodejs-18.19.0+dfsg nodejs-18.19.0+dfsg Thanks a lot for your work Adrian. Please note that there is currently a nodejs upload pending for releasing via a DSA, which will rebase nodejs to 18.20.3+dfsg-1~deb12u1 so this might invalidate those changes. Jérémy, Aron is that something you want to have included in your prepared update? Regards, Salvatore
Bug#1069891: bookworm-pu: package ansible/7.7.0+dfsg-3+deb12u1
Hi Lee,
On Sat, Jun 15, 2024 at 11:06:23PM +0100, Jonathan Wiltshire wrote:
> Control: tag -1 moreinfo
>
> On Fri, Apr 26, 2024 at 03:05:00PM +0200, Lee Garrett wrote:
> > I'm requesting to bump the version of the ansible package
> > ("ansible-community
> > collection") to the last minor semantic version of the v7 series in
> > bookworm.
> > This version has previously spent ~10 months in testing/unstable, so I'm
> > fairly
> > confident that any potential regressions would have been caught (so far
> > none).
>
> If upstream uses semver then 7.3 -> 7.7 implies new features. Along with a
> 10MiB diff this is usually a good indicator that it's inappropriate for
> stable.
>
> The trouble with a package's time spent in sid as an indicator of
> reliability isn't so much the package itself, but all the differences
> around it like library versions. We've been bitten by that assumption
> before now.
>
> Are there known issues for users which you can target with fixes rather
> than a wholesale backport?
>
> Otherwise maybe bookworm-backports is a better place for this, so users can
> choose to take slightly more risk for features, or stick with the released
> version and put up with known quantity bugs.
Did you saw Jonathan's comments above?
Regards,
Salvatore
Bug#1070739: bookworm-pu: package python-glance-store/4.1.0-4
On Sat, Jun 15, 2024 at 07:29:56PM +0100, Adam D. Barratt wrote: > Control: tags -1 -moreinfo +confirmed > > On Sat, 2024-06-15 at 16:21 +0100, Adam D. Barratt wrote: > > Control: tags -1 + moreinfo > > > > On Wed, 2024-05-08 at 17:59 +0200, Salvatore Bonaccorso wrote: > > > Hi, > > > > > > On Wed, May 08, 2024 at 09:52:01AM +0200, Thomas Goirand wrote: > > > > > [...] > > > > I would like to update python-glance-store/4.1.0-4 to > > > > python-glance-store/4.1.1-1+deb12u1 to address CVE-2024-1141 > > > > (aka: #1063795). > > > > > > Should that be 4.1.1-0+deb12u1 instead? (I do know that 4.1.1-1 was > > > never in the archive ,but that makes sure it sorts before 4.1.1-1). > > > > Yes, indeed. > > > > Both the Security Tracker and BTS suggest that this issue affects > > unstable and is not yet fixed there. What's the status? > > Apparently the metadata was outdated. Thanks for checking and updating > it, Salvatore. > > Please go ahead, using 4.1.1-0+deb12u1 as the version number. Thomas, did you saw this ack from Adam? Regards, Salvatore
Bug#1070193: bookworm-pu: package ansible-core/2.14.16-0+deb12u1
Hi lee, On Sat, Jun 15, 2024 at 11:25:26PM +0100, Jonathan Wiltshire wrote: > Control: tag -1 confirmed > > On Wed, May 01, 2024 at 05:05:05PM +0200, Lee Garrett wrote: > > [ Reason ] > > This is a bugfix-only update from ansible-core 2.14.3 to 2.14.16. This fixes > > three CVEs: > > - Address issue where ANSIBLE_NO_LOG was ignored (CVE-2024-0690) > > - Address issues where internal templating can cause unsafe variables to > > lose their unsafe designation (CVE-2023-5764) > > - Prevent roles from using symlinks to overwrite files outside of the > > installation directory (CVE-2023-5115) > > > > and various other bugfixes as seen here: > > https://salsa.debian.org/python-team/packages/ansible-core/-/blob/debian/bookworm-proposed/changelogs/CHANGELOG-v2.14.rst > > 1051 files changed, 8802 insertions(+), 159082 deletions(-) > > Normally I'd been looking for targetted fixes for the security issues but > upstream's descriptive changelog does look quite sensible. > > You might want to change your version number - if 2.14.16-1 was never in > sid you could use that. A +/~ revision to a version which never existed > feels odd, as do -0 Debian versions (-1 being the first Debian release of > this upstream version, -0 is... the zeroth?). did you saw the ack from Jonathan? Regards, Salvatore
Bug#1068888: bookworm-pu: package zookeeper/3.8.0-11+deb12u2
Hi Bastien, On Sun, Jun 16, 2024 at 12:50:59PM +0100, Adam D. Barratt wrote: > On Sun, 2024-06-16 at 11:12 +, Bastien Roucariès wrote: > > control: tag -1 - moreinfo > > Le samedi 15 juin 2024, 22:49:24 UTC Jonathan Wiltshire a écrit : > > > > > [...] > > > > zookeeper-3.8.0/debian/patches/0027-CVE-2024-23944-ZOOKEEPER- > > > > 4799-Refactor-ACL-check-in-.patch 1970-01-01 > > > > 00:00:00.0 + > > > > +++ zookeeper-3.8.0/debian/patches/0027-CVE-2024-23944-ZOOKEEPER- > > > > 4799-Refactor-ACL-check-in-.patch 2024-03-25 > > > > 08:30:56.0 + > > > > @@ -0,0 +1,1223 @@ > > > > > > > > > This patch confuses me. It seems to contain a whole series of > > > nested > > > patches? How do they get applied to the source package? > > > > ??? > > > > I do not understand, see patch 0027 joined it is a simple patch... > > Is the source of the confusion here potentially that the patch adds new > files, as well as changing existing ones? Any comments here? (I guess likely it will be now to late for 12.6, but maybe we can make it for 12.7?) Regards, Salvatore
Bug#1066965: bookworm-pu: package newlib/3.3.0-2
Hi Petter, On Sat, May 25, 2024 at 09:44:06PM +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Sat, 2024-03-16 at 09:09 +0100, Petter Reinholdtsen wrote: > > +newlib (3.3.0-2) bookworm; urgency=medium > > > > As Salvatore already noted, that's not a conventional version number > for a stable upload, but can be used iff no such version has ever been > used for a package uploaded to Debian (or included as a changelog > stanza in d/changelog for any package uploaded to Debian) in the past. > > > + > > + * QA upload. > > + * Orphan package to reflect status in Unstable. > > Although this is harmless, note that it's also mostly redundant, as > nothing actually looks at / acts on the maintainer fields of packages > in stable (or older). > > Please go ahead. Did you saw Adam's confirmation on this (with the comments about the version)? Regards, Salvatore
Bug#1055211: bookworm-pu: package gcc-12/12.2.0-14+deb12u1 (CVE-2023-4039)
Hi, On Thu, Nov 02, 2023 at 11:11:56AM +0100, Emanuele Rocca wrote: > Package: release.debian.org > Severity: normal > Tags: bookworm > User: release.debian@packages.debian.org > Usertags: pu > X-Debbugs-Cc: debian-...@lists.debian.org, j...@debian.org, d...@debian.org > Control: affects -1 + src:gcc-12 > > [ Reason ] > A failure in the -fstack-protector feature in GCC-based toolchains that target > AArch64 allows an attacker to exploit an existing buffer overflow in > dynamically-sized local variables without this being detected. > > The Security Team explicitly stated that they will not release a DSA for the > bug, see https://security-tracker.debian.org/tracker/CVE-2023-4039 > > This issue has been fixed in version 12.3.0-9 for sid and trixie. It would now > be good to address the problem in bookworm too. > > [ Impact ] > Without this change, arm64 users of gcc-12 in bookworm are not fully protected > by -fstack-protector as described in CVE-2023-4039. > > [ Tests ] > In terms of manual testing, I have verified that the stack smashing attack > published at > https://github.com/metaredteam/external-disclosures/security/advisories/GHSA-x7ch-h5rf-w2mf > is detected and stopped when the PoC is compiled with gcc 12.2.0-14+deb12u1, > while it results in a Bus error with 12.2.0-14: > > $ gcc-12 --version | head -1 > gcc-12 (Debian 12.2.0-14+deb12u1) 12.2.0 > $ gcc-12 -fstack-protector-all -O3 -static -Wall -Wextra -pedantic -o poc > poc.c > $ echo -n '' | ./poc 8 > *** stack smashing detected ***: terminated > Aborted > > $ gcc-12 --version | head -1 > gcc-12 (Debian 12.2.0-14) 12.2.0 > $ gcc-12 -fstack-protector-all -O3 -static -Wall -Wextra -pedantic -o poc > poc.c > $ echo -n '' | ./poc 8 > Bus error > > As an additional smoke test I have also successfully built a few packages, as > well as a kernel. > > In terms of automated testing, the upstream test suite is extensive. > Additionally, upstream added the following tests specifically for > CVE-2023-4039: > > testsuite/gcc.target/aarch64/stack-check-prologue-17.c > testsuite/gcc.target/aarch64/stack-check-prologue-18.c > testsuite/gcc.target/aarch64/stack-check-prologue-19.c > testsuite/gcc.target/aarch64/stack-check-prologue-20.c > testsuite/gcc.target/aarch64/stack-protector-8.c > testsuite/gcc.target/aarch64/stack-protector-9.c > > [ Risks ] > There are obviously potential risks of regressions associated with compiler > changes. However the specific changes proposed here have been part of gcc-12 > upstream since September, and by now have been tested quite a bit. One > regression has been found early on and fixed: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111411 > > All changes are arm64-specific and don't affect any other architecture. > > [ 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 ] > All changes merged upstream back in September 2023, see > https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/releases/gcc-12 > > - aarch64: Avoid a use of callee_offset > 12a8889de169f892d2e927584c00d20b8b7e456f > > - aarch64: Explicitly handle frames with no saved registers > 03d5e89e7f3be53fd7142556e8e0a2774c653dca > > - aarch64: Add bytes_below_saved_regs to frame info > 49c2eb7616756c323b7f6b18d8616ec945eb1263 > > - aarch64: Add bytes_below_hard_fp to frame info > 34081079ea4de0c98331843f574b5f6f94d7b234 > > - aarch64: Tweak aarch64_save/restore_callee_saves > 187861af7c51db9eddc6f954b589c121b210fc74 > > - aarch64: Only calculate chain_offset if there is a chain > 2b983f9064d808daf909bde1d4a13980934a7e6e > > - aarch64: Rename locals_offset to bytes_above_locals > 0a0a824808d1dec51004fb5805c1a0ae2a35433f > > - aarch64: Rename hard_fp_offset to bytes_above_hard_fp > 3fbf0789202b30a67b12e1fb785c7130f098d665 > > - aarch64: Tweak frame_size comment > aac8b31379ac3bbd14fc6427dce23f56e54e8485 > > - aarch64: Measure reg_offset from the bottom of the frame > 8d5506a8aeb8dd7e8b209a3663b07688478f76b9 > > - aarch64: Simplify top of frame allocation > b47766614df3b9df878262efb2ad73aaac108363 > > - aarch64: Minor initial adjustment tweak > 08f71b4bb28fb74d20e8d2927a557e8119ce9f4d > > - aarch64: Tweak stack clash boundary condition > f22315d5c19e8310e4dc880fd509678fd291fca8 > > - aarch64: Put LR save probe in first 16 bytes > 15e18831bf98fd25af098b970ebf0c9a6200a34b > > - aarch64: Simplify probe of final frame allocation > c4f0e121faa36342f1d21919e54a05ad841c4f86 > > - aarch64: Explicitly record probe registers in frame info > 6f0ab0a9f46a17b68349ff6035aa776bf65f0575 > > - aarch64: Remove below_hard_fp_saved_regs_size > 8254e1b9cd500e0c278465a3657543477e9d1250 > > - aarch64: Make stack smash canary protect save
Bug#1054915: bookworm-pu: package freerdp2/2.11.2+dfsg1-1~deb12u1
Hi Tobi, On Wed, Feb 21, 2024 at 08:00:42AM +, Jonathan Wiltshire wrote: > Control: tag -1 moreinfo > > Hi, > > On Sat, Oct 28, 2023 at 05:58:38PM +0200, Tobias Frost wrote: > > Backporting the fixes is of course possible, but bears a significant > > risk for regression, therefor I would prefer to use the new upstream > > version, given also that upstream changes are only a few and fixing > > also a few bugs that would be nice to be fixed. > > It's a balancing act, as always. I'm OK with new upstream releases if they > are small enough to sensibly review (or an upstream with a good trusted > history, which I don't yet have for freerdp2). If you think a new upstream > is reasonable, let's see how it looks. > > Either way we need a source debdiff please. Did you saw the followup question from Jonathan? Regards, Salvatore
Bug#1053832: bookworm-pu: package ceph/16.2.11+ds-2 (CVE-2023-43040)
On Sat, Apr 06, 2024 at 10:36:50PM +0100, Jonathan Wiltshire wrote: > Control: tag -1 confirmed > > On Thu, Oct 12, 2023 at 11:34:58AM +0200, Thomas Goirand wrote: > > [ Reason ] > > CVE-2023-43040 > > > > [ Impact ] > > security issue with RGW with improperly verified POST keys. > > Sorry for the delay; please go ahead. Thomas, friendly ping? Regards, Salvatore
Bug#1073234: bookworm-pu: package gdk-pixbuf/2.42.10+dfsg-1+deb12u1
Hi Jeremy, On Fri, Jun 21, 2024 at 04:31:18PM -0400, Jeremy Bícha wrote: > On Fri, Jun 21, 2024 at 3:52 PM Salvatore Bonaccorso > wrote: > > On Wed, Jun 19, 2024 at 07:11:11PM +0100, Adam D. Barratt wrote: > > > On Sat, 2024-06-15 at 08:28 +0200, Salvatore Bonaccorso wrote: > > > > Hi Jeremy, Simon, > > > > > > > > On Fri, Jun 14, 2024 at 06:22:13PM -0400, Jeremy Bícha wrote: > > > > > > > > [...] > > > > > Salvatore, I pushed commits a few days ago to the debian/bookworm > > > > > and > > > > > debian/bullseye branches of > > > > > https://salsa.debian.org/gnome-team/gdk-pixbuf based directly on > > > > > similar work that had been done by Ubuntu Security but I hadn't > > > > > made > > > > > time to do further testing and reach out to Debian Security. Do you > > > > > want to use those versions or the version you have prepared now? > > > > > > > > Ups, apologies I did no spot that you did as well already the work. > > > > > > > > If you prefer to have your version included for the point-release we > > > > can ask there SRM to reject my version and you can upload your one > > > > (notice to please change the target distribtuion to 'bookworm' for > > > > the point release update). > > > > > > > > As you have already done as well the bullseye one, can you fille a > > > > bullseye-pu request + upload for bullseye-pu as well? > > > > > > > > Just let here know if you want > > > > > > > > gdk-pixbuf | 2.42.10+dfsg-1+deb12u1 | stable-new | source > > > > > > > > rejected in favour of your version. > > > > > > Ping on this, as we're getting closer to the freeze windows. > > > > Friendly ping as the window is closing on sunday. > > > > Otherwise can we have the uploaded and pending in stable-new version > > accepted for the point release? > > > > Notabene, I did not managed yet to work on the bullseye version as > > well, which would be convinient to have as well included in the > > upcoming point release. > > Let's go with your existing 2.42.10+dfsg-1+deb12u1 upload for bookworm. > > I'll do an upload and file a separate bug later today (or early > tomorrow) with my bullseye version. Thanks a lot! Regards, Salvatore
Bug#1073234: bookworm-pu: package gdk-pixbuf/2.42.10+dfsg-1+deb12u1
Hi all, On Wed, Jun 19, 2024 at 07:11:11PM +0100, Adam D. Barratt wrote: > On Sat, 2024-06-15 at 08:28 +0200, Salvatore Bonaccorso wrote: > > Hi Jeremy, Simon, > > > > On Fri, Jun 14, 2024 at 06:22:13PM -0400, Jeremy Bícha wrote: > > > > [...] > > > Salvatore, I pushed commits a few days ago to the debian/bookworm > > > and > > > debian/bullseye branches of > > > https://salsa.debian.org/gnome-team/gdk-pixbuf based directly on > > > similar work that had been done by Ubuntu Security but I hadn't > > > made > > > time to do further testing and reach out to Debian Security. Do you > > > want to use those versions or the version you have prepared now? > > > > Ups, apologies I did no spot that you did as well already the work. > > > > If you prefer to have your version included for the point-release we > > can ask there SRM to reject my version and you can upload your one > > (notice to please change the target distribtuion to 'bookworm' for > > the point release update). > > > > As you have already done as well the bullseye one, can you fille a > > bullseye-pu request + upload for bullseye-pu as well? > > > > Just let here know if you want > > > > gdk-pixbuf | 2.42.10+dfsg-1+deb12u1 | stable-new | source > > > > rejected in favour of your version. > > Ping on this, as we're getting closer to the freeze windows. Friendly ping as the window is closing on sunday. Otherwise can we have the uploaded and pending in stable-new version accepted for the point release? Notabene, I did not managed yet to work on the bullseye version as well, which would be convinient to have as well included in the upcoming point release. Regards, Salvatore
Re: Planning for 12.7/11.11
Hi Jonathan, On Thu, Jun 20, 2024 at 10:35:35PM +0100, Jonathan Wiltshire wrote: > Hi, > > A finally-final point release is required for bullseye, and we're a bit > constrained on dates. The security team (CC) wish to cease security support > from Wednesday 14th August and hand over to LTS as soon as a wash-up release > can be organised. > > The weekend of 24th August is unworkable. That leaves two options: > > - Saturday 17th August: this would mean freezing on the 10th, before >security support ends, so the security team's cooperation in keeping >non-critical DSAs off the table during the freeze period would be >required Sure, you will have our full cooperation; this will be fine from our side and keeping non-critical DSAs off the table as needed. Rgards, Salvatore
Bug#1073234: bookworm-pu: package gdk-pixbuf/2.42.10+dfsg-1+deb12u1
Hi Jeremy, Simon, On Fri, Jun 14, 2024 at 06:22:13PM -0400, Jeremy Bícha wrote: > On Fri, Jun 14, 2024 at 5:18 PM Salvatore Bonaccorso > wrote: > > > > Package: release.debian.org > > Severity: normal > > Tags: bookworm > > X-Debbugs-Cc: gdk-pix...@packages.debian.org, Simon McVittie > > , car...@debian.org > > Control: affects -1 + src:gdk-pixbuf > > User: release.debian@packages.debian.org > > Usertags: pu > > > > Hi stable release managers, CC'ing Simon, > > > > [ Reason ] > > gdk-pixbuf is affected by CVE-2022-48622, a memory corruption via > > crafted .ani files, cf. #1071265. > > > > [ Impact ] > > At least denial of service but potentially as well arbitrary code > > execution. But we have classified in no-dsa and it does not warrant a > > DSA on its own. > > > > [ Tests ] > > Manual test against the poc in the upstream issue > > https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/202 . > > > > [ Risks ] > > Isolated changes, and the fix has been exposed in sid and 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 (old)stable > > [x] the issue is verified as fixed in unstable > > > > [ Changes ] > > Three commits cherry-picked from upstream: > > > > * ANI: Reject files with multiple anih chunks (CVE-2022-48622) > > (Closes: #1071265) > > * ANI: Reject files with multiple INAM or IART chunks > > * ANI: Validate anih chunk size > > > > The two other commits are not for CVE-2022-48622 but additional > > hardening and fixing changes related to the ANI code. > > > > Simon, ideally we should do as well the fixup in bullseye, but I have > > not looked at that version yet. > > Salvatore, I pushed commits a few days ago to the debian/bookworm and > debian/bullseye branches of > https://salsa.debian.org/gnome-team/gdk-pixbuf based directly on > similar work that had been done by Ubuntu Security but I hadn't made > time to do further testing and reach out to Debian Security. Do you > want to use those versions or the version you have prepared now? Ups, apologies I did no spot that you did as well already the work. If you prefer to have your version included for the point-release we can ask there SRM to reject my version and you can upload your one (notice to please change the target distribtuion to 'bookworm' for the point release update). As you have already done as well the bullseye one, can you fille a bullseye-pu request + upload for bullseye-pu as well? Just let here know if you want gdk-pixbuf | 2.42.10+dfsg-1+deb12u1 | stable-new | source rejected in favour of your version. Note the window for uploads for bookworm and bullseye point releases is closing next weekend. Thank you for all your work! Regards, Salvatore
Bug#1073234: bookworm-pu: package gdk-pixbuf/2.42.10+dfsg-1+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: gdk-pix...@packages.debian.org, Simon McVittie ,
car...@debian.org
Control: affects -1 + src:gdk-pixbuf
User: release.debian@packages.debian.org
Usertags: pu
Hi stable release managers, CC'ing Simon,
[ Reason ]
gdk-pixbuf is affected by CVE-2022-48622, a memory corruption via
crafted .ani files, cf. #1071265.
[ Impact ]
At least denial of service but potentially as well arbitrary code
execution. But we have classified in no-dsa and it does not warrant a
DSA on its own.
[ Tests ]
Manual test against the poc in the upstream issue
https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/202 .
[ Risks ]
Isolated changes, and the fix has been exposed in sid and 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 (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
Three commits cherry-picked from upstream:
* ANI: Reject files with multiple anih chunks (CVE-2022-48622)
(Closes: #1071265)
* ANI: Reject files with multiple INAM or IART chunks
* ANI: Validate anih chunk size
The two other commits are not for CVE-2022-48622 but additional
hardening and fixing changes related to the ANI code.
Simon, ideally we should do as well the fixup in bullseye, but I have
not looked at that version yet.
Regards,
Salvatore
diff -Nru gdk-pixbuf-2.42.10+dfsg/debian/changelog
gdk-pixbuf-2.42.10+dfsg/debian/changelog
--- gdk-pixbuf-2.42.10+dfsg/debian/changelog2022-11-18 20:13:50.0
+0100
+++ gdk-pixbuf-2.42.10+dfsg/debian/changelog2024-06-13 23:04:36.0
+0200
@@ -1,3 +1,12 @@
+gdk-pixbuf (2.42.10+dfsg-1+deb12u1) bookworm; urgency=medium
+
+ * ANI: Reject files with multiple anih chunks (CVE-2022-48622)
+(Closes: #1071265)
+ * ANI: Reject files with multiple INAM or IART chunks
+ * ANI: Validate anih chunk size
+
+ -- Salvatore Bonaccorso Thu, 13 Jun 2024 23:04:36 +0200
+
gdk-pixbuf (2.42.10+dfsg-1) unstable; urgency=medium
* Team upload
diff -Nru
gdk-pixbuf-2.42.10+dfsg/debian/patches/ANI-Reject-files-with-multiple-INAM-or-IART-chunks.patch
gdk-pixbuf-2.42.10+dfsg/debian/patches/ANI-Reject-files-with-multiple-INAM-or-IART-chunks.patch
---
gdk-pixbuf-2.42.10+dfsg/debian/patches/ANI-Reject-files-with-multiple-INAM-or-IART-chunks.patch
1970-01-01 01:00:00.0 +0100
+++
gdk-pixbuf-2.42.10+dfsg/debian/patches/ANI-Reject-files-with-multiple-INAM-or-IART-chunks.patch
2024-06-13 23:02:36.0 +0200
@@ -0,0 +1,36 @@
+From: Benjamin Gilbert
+Date: Tue, 30 Apr 2024 07:13:37 -0500
+Subject: ANI: Reject files with multiple INAM or IART chunks
+Origin:
https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/commit/d52134373594ff76614fb415125b0d1c723ddd56
+
+There should be at most one chunk each. These would cause memory leaks
+otherwise.
+---
+ gdk-pixbuf/io-ani.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/gdk-pixbuf/io-ani.c b/gdk-pixbuf/io-ani.c
+index a78ea7ace40b..8e8414117c3a 100644
+--- a/gdk-pixbuf/io-ani.c
b/gdk-pixbuf/io-ani.c
+@@ -445,7 +445,7 @@ ani_load_chunk (AniLoaderContext *context, GError **error)
+ }
+ else if (context->chunk_id == TAG_INAM)
+ {
+- if (!context->animation)
++ if (!context->animation || context->title)
+ {
+ g_set_error_literal (error,
+ GDK_PIXBUF_ERROR,
+@@ -472,7 +472,7 @@ ani_load_chunk (AniLoaderContext *context, GError **error)
+ }
+ else if (context->chunk_id == TAG_IART)
+ {
+- if (!context->animation)
++ if (!context->animation || context->author)
+ {
+ g_set_error_literal (error,
+ GDK_PIXBUF_ERROR,
+--
+2.45.1
+
diff -Nru
gdk-pixbuf-2.42.10+dfsg/debian/patches/ANI-Reject-files-with-multiple-anih-chunks.patch
gdk-pixbuf-2.42.10+dfsg/debian/patches/ANI-Reject-files-with-multiple-anih-chunks.patch
---
gdk-pixbuf-2.42.10+dfsg/debian/patches/ANI-Reject-files-with-multiple-anih-chunks.patch
1970-01-01 01:00:00.0 +0100
+++
gdk-pixbuf-2.42.10+dfsg/debian/patches/ANI-Reject-files-with-multiple-anih-chunks.patch
2024-06-13 22:59:39.0 +0200
@@ -0,0 +1,41 @@
+From: Benjamin Gilbert
+Date: Tue, 30 Apr 2024 07:26:54 -0500
+Subject: ANI: Reject files with multiple anih chunks
+Origin:
https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/commit/00c071dd11f723ca608608eef45cb1aa98da89cc
+Bug-Debian: https://bugs.debian.org/1071265
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2022-48622
+
+An anih chunk causes us to initialize a bunch of state, which we only
+expect to do once per file.
+
+Fixes: #202
+Fixes: CVE-2022-48622
+---
+ gdk-pixbuf/io-ani.c
Bug#1070702: bookworm-pu: package nano/7.2-1+deb12u1
Hi Jordi, On Tue, May 07, 2024 at 04:00:15PM +0200, Jordi Mallach wrote: > Package: release.debian.org > Severity: normal > Tags: bookworm > X-Debbugs-Cc: n...@packages.debian.org > Control: affects -1 + src:nano > User: release.debian@packages.debian.org > Usertags: pu > > As we did in previous Debian releases, this is an update > for Debian stable's nano package with selected patches from > the upstream maintainer. > > 3 of the patches minor security issues, and the other one > fixes a potential data-loss issue. > > Additionally there's a minor update to the default nanorc which > is a backport from 7.2-2, which was meant to be included in > Debian 12.0 but freeze came along. It just gets rid of some > control characters in some commented-out example bindings, > replacing them with the new style syntax. > > [ 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 > > This source update was prompted by Salvatore while discussing one of the > 3 security issues. FTR, https://git.savannah.gnu.org/cgit/nano.git/commit/?id=5e7a3c2e7e118c7f12d5dfda9f9140f638976aa2 has now as well a CVE assigned: CVE-2024-5742. But no need to redo an upload, but would be great to get it accepted for the next point release. Regards, Salvatore
Uploading linux (6.8.12-1)
Hi I would like to upload lnux version 6.8.12-1 to unstable, which is importing the last stable version for the 6.8.y series which is EOL with 6.8.12. After that a switch to 6.9.y will need to happen. No packaging changes are included. Regards, Salvatore signature.asc Description: PGP signature
Uploading linux (6.8.11-1)
Hi I would like to upload over the weekend linux verison 6.8.11-1 to unstable (importing two stable versions 6.8.10 and 6.8.11). No other changes are aimed to be included, but brings unstable just up to pair to upstream stable version for the 6.8.y series. Regards, Salvatore signature.asc Description: PGP signature
Bug#1070998: bookworm-pu: package fossil/2.24-5~deb11u1
Hi Bastien, On Sun, May 12, 2024 at 05:47:31PM +, Bastien Roucariès wrote: > Package: release.debian.org > Severity: normal > Tags: bookworm > X-Debbugs-Cc: fos...@packages.debian.org > Control: affects -1 + src:fossil > User: release.debian@packages.debian.org > Usertags: pu > > this bug was opened by previous arrangement with maintainer. > > [ Reason ] > fossil is affected by a regression due to a security update of apache > CVE-2024-24795. Backport was choosen > because upstream does not document all commit needed for fixing the > regression. Disclaimer, not SRM so this is not an authoritative answer. But that means that as well packaing changes beween 1:2.21-1 and the proposed one are included. Are all of those allowed to be done or should you individually revert some changes? E.g. there is * Bump policy * Build depend on pkgconfig instead of obsolete pkg-config and * Oops, typo: pkgconf which might indeed be fine. But should defintitively be checked. Regards, Salvatore
Bug#1069891: bookworm-pu: package ansible/7.7.0+dfsg-3+deb12u1
Hi Lee, (disclaimer, not a member of the release team) On Fri, May 10, 2024 at 12:15:56PM +0200, Lee Garrett wrote: > I have just pushed some meta-data updates, and also a change that fixes > CVE-2023-4237 in this package. See the commit logs here: > > https://salsa.debian.org/python-team/packages/ansible/-/commits/debian/bookworm-proposed/ My understanding is that SRM would like to have a debdiff posted to the list with the changes. I realize the previous one was 10M big, and so actually might have not made to the list, and so not on the radar of the SRM. Stuff might be as well filtered out if needed from the debdiff, and explained in the mail. As your proposed update covers as well a CVE fix, that would be great if it can make it to the next point release. Regards, Salvatore
Bug#1070739: bookworm-pu: package python-glance-store/4.1.0-4
Hi, On Wed, May 08, 2024 at 09:52:01AM +0200, Thomas Goirand wrote: > Package: release.debian.org > Severity: normal > Tags: bookworm > User: release.debian@packages.debian.org > Usertags: pu > X-Debbugs-Cc: python-glance-st...@packages.debian.org > Control: affects -1 + src:python-glance-store > > [ Reason ] > I would like to update python-glance-store/4.1.0-4 to > python-glance-store/4.1.1-1+deb12u1 to address CVE-2024-1141 > (aka: #1063795). Should that be 4.1.1-0+deb12u1 instead? (I do know that 4.1.1-1 was never in the archive ,but that makes sure it sorts before 4.1.1-1). Regards, Salvatore
Bug#1069690: bookworm-pu: package libkf5ksieve/4:22.12.3-1+deb12u1
Hi Patrick, On Mon, Apr 22, 2024 at 09:36:54PM +0200, Patrick Franz wrote: > Package: release.debian.org > Severity: normal > Tags: bookworm > X-Debbugs-Cc: delta...@debian.org > User: release.debian@packages.debian.org > Usertags: pu > > [ Reason ] > There is a bug in libkf5sieve where the password instead of the > username is sent when using managesieve and could therefore be > logged on a server as the login will fail. > > [ Impact ] > Potentially sensitive passwords are logged on a server. > > [ Tests ] > Affected user has successfully tested the patched version. > > [ Risks ] > The patch is trivial (1 line is changed) and it's quite obvious > that it was a bug in the first place. > > [ 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-line patch to fix the bug. > diffstat for libkf5ksieve-22.12.3 libkf5ksieve-22.12.3 As it is not yet uploaded for bookworm, you might add as well the CVE id reference in the changelog: CVE-2023-52723 . p.s.: I think you can take advantage of the improved workflow for this specific one, if you are sure the package will be accepted as it is from SRM, you can with the proposed update bug filling, along as well already do the upload. (but note, just commenting this with no authrotiy speaking, as not part of the release team) Regards, Salvatore
Uploading linux (6.7.12-1)
Hi I plan to upload 6.7.12-1 later to unstable. Note, this is a situation far from ideal and personally not very happy with. 6.7.12 was the last version in the 6.7.y release and upstream has long moved already to 6.8.y while EOL'ing 6.7.y. This upload will thus release with a couple of known unfixed regressions in the 6.7.y series, but is intented as intermediary upload only and as preparation for the next 6.8.y upload. Work in progress for that is already in https://salsa.debian.org/kernel-team/linux/-/merge_requests/1053 I was pondering to actually cherry-pick on top known fixes (like the workqueue regressions or the native BHI mitigations), but I concluded it will be safer and better to just move to a 6.8.y version after that. Please do raise your voice if you have concerns. Regards, Salvatore signature.asc Description: PGP signature
Bug#1065413: bookworm-pu: package openssl/3.0.13-1~deb12u1
Hi Sebastian, On Tue, Apr 09, 2024 at 06:18:13PM +0200, Sebastian Andrzej Siewior wrote: > On 2024-04-07 23:46:28 [+0200], To Adam D. Barratt wrote: > > On 2024-03-24 20:06:12 [+], Adam D. Barratt wrote: > > > > > > Sorry for not getting to this sooner. Is this still the case? > > > > So. This happened #1068045 (yapet broke with 1.0 format) due to the > > update. On the bright side it has been broken in unstable but unnoticed. > > Looking into it but also sleeping (but making progress). > > yapet is fixed in unstable. My understanding is that the maintainer will > take care of it. After exposure of the upload in unstable for two days, uploaded now as well to bookworm. Filled #1068836. Regards, Salvatore
Bug#1068836: bookworm-pu: package yapet/2.6-2~deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: ya...@packages.debian.org, car...@debian.org
Control: affects -1 + src:yapet
User: release.debian@packages.debian.org
Usertags: pu
Hi,
[ Reason ]
After the update of openssl/3.0.13-1~deb12u1 in bookworm-pu Sean found
that old 1.0 format databases. While most of people should have moved
some time ago to 2.0 format databases, they are still claimed to be
supported. The update of openssl uncovered though a bug in yapet (as
well present in unstable, and fixed as well).
Sebastian explained the situation in https://bugs.debian.org/1068045#94
[ Impact ]
Users using the old 1.0 format could not open anymore their store.
[ Tests ]
Done explicitly with an old 1.0 format database provided by sean,
running the testsuite, and manual checks with 2.0 format databases.
[ Risks ]
Patches provided by the openssl maintainer. While they are not yet
applied upstream, they tackle the bug in yapet as isolated by the
openssl maintainers.
[ 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 ]
The two patches drop EVP_CIPHER_CTX_set_key_length() invocation to
keep compatiblity with 1.0 databases and with openssl versions.
Quoting the commit:
|yapet did for blowfish:
|
|| EVP_CipherInit_ex(ctx, cipher, NULL, KEY, iv, mode);
|| EVP_CIPHER_CTX_set_key_length(ctx, KEY_LENGTH);
|| EVP_CipherUpdate(ctx, …);
|
|this worked in earlier OpenSSL versions and stopped working in
|openssl-3.0.13. The problem here is that the
|EVP_CIPHER_CTX_set_key_length() is ignored and the later OpenSSL version
|returns rightfully an error "Provider routines::no key set" here.
|
|Blowfish does support variable key lenghts but the key length has to be
|set first followed by the actual key. Otherwise the blocksize (16) will
|be used.
|The correct way to deal with this would be:
|| EVP_CipherInit_ex(ctx, cipher, NULL, NULL, NULL, mode);
|| EVP_CIPHER_CTX_set_key_length(ctx, KEY_LENGTH);
|| EVP_CipherInit_ex(ctx, NULL, NULL, KEY, IV, mode);
|| EVP_CipherUpdate(ctx, …);
|
|Using now the proper way will break earlier databases because in the
|blowfish case, always the default blocksize / 16 has been used.
|
|In order to keep compatibility with earlier versions of the database and
|openssl remove the EVP_CIPHER_CTX_set_key_length() invocation.
While at it Sebastian fixed as well the invocation present for the
crypt/aes code.
[ Other info ]
None.
Regards,
Salvatore
diff -Nru yapet-2.6/debian/changelog yapet-2.6/debian/changelog
--- yapet-2.6/debian/changelog 2022-03-14 14:19:11.0 +0100
+++ yapet-2.6/debian/changelog 2024-04-11 20:40:18.0 +0200
@@ -1,3 +1,16 @@
+yapet (2.6-2~deb12u1) bookworm; urgency=medium
+
+ * Rebuild for bookworm
+
+ -- Salvatore Bonaccorso Thu, 11 Apr 2024 20:40:18 +0200
+
+yapet (2.6-2) unstable; urgency=medium
+
+ * crypt/blowfish: Remove EVP_CIPHER_CTX_set_key_length() (Closes: #1064724)
+ * crypt/aes: Remove EVP_CIPHER_CTX_set_key_length()
+
+ -- Salvatore Bonaccorso Mon, 08 Apr 2024 21:32:50 +0200
+
yapet (2.6-1) unstable; urgency=medium
* New upstream version 2.6
diff -Nru
yapet-2.6/debian/patches/crypt-aes-Remove-EVP_CIPHER_CTX_set_key_length.patch
yapet-2.6/debian/patches/crypt-aes-Remove-EVP_CIPHER_CTX_set_key_length.patch
---
yapet-2.6/debian/patches/crypt-aes-Remove-EVP_CIPHER_CTX_set_key_length.patch
1970-01-01 01:00:00.0 +0100
+++
yapet-2.6/debian/patches/crypt-aes-Remove-EVP_CIPHER_CTX_set_key_length.patch
2024-04-11 20:40:18.0 +0200
@@ -0,0 +1,41 @@
+From aaa573b14bafcc9a6b46495bd4ffc15b90d35902 Mon Sep 17 00:00:00 2001
+From: Sebastian Andrzej Siewior
+Date: Mon, 8 Apr 2024 18:19:12 +0200
+Subject: [PATCH] crypt/aes: Remove EVP_CIPHER_CTX_set_key_length().
+
+The EVP_CIPHER_CTX_set_key_length() in the AES-256-CBC case is pointless
+because the key here is fixed EVP_CIPHER_CTX_set_key_length() and the
+function does not change the size.
+
+Remove the EVP_CIPHER_CTX_set_key_length() invocation.
+
+Signed-off-by: Sebastian Andrzej Siewior
+---
+ src/libs/crypt/aes256.cc | 11 ---
+ 1 file changed, 11 deletions(-)
+
+diff --git a/src/libs/crypt/aes256.cc b/src/libs/crypt/aes256.cc
+index 1041b9c57347..e105b1a5bedd 100644
+--- a/src/libs/crypt/aes256.cc
b/src/libs/crypt/aes256.cc
+@@ -113,17 +113,6 @@ EVP_CIPHER_CTX* Aes256::initializeOrThrow(const
SecureArray& ivec, MODE mode) {
+ throw CipherError{_("Error initializing cipher")};
+ }
+
+-success = EVP_CIPHER_CTX_set_key_length(context, getKey()->keySize());
+-if (success != SSL_SUCCESS) {
+-LOG_MESSAGE(std::string{__func__} + ": Error setting key length");
+-destroyContext(context);
+-char msg[YAPET::Consts::EXCEPTION_MESSAGE_BUFF
Bug#1068633: bookworm-pu: package cjson/1.7.15-1+deb12u1
Hi, Disclaimer, this is not an authoritative answer as I'm not part of the stable release managers. On Mon, Apr 08, 2024 at 12:27:50PM +0300, Maytham Alsudany wrote: > Package: release.debian.org > Severity: normal > Tags: bookworm > User: release.debian@packages.debian.org > Usertags: pu > X-Debbugs-Cc: cj...@packages.debian.org > Control: affects -1 + src:cjson > > [ Reason ] > CVE-2023-50472, CVE-2023-50471 > > [ Impact ] > Segmentation violation via the function cJSON_InsertItemInArray at cJSON.c > > [ Tests ] > Upstream's test continue to pass, and they have also added new tests to > cover this security issue. > > [ Risks ] > Minimal, no change to API. Only minimal changes were made to fix this > security issue. > > [ 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 ] > - Set myself as Maintainer (I am adopting the package, #1067510) > - Bump Standards-Version to 4.6.2 > - Add Build-Depends-Package to symbools > - Backport upstream's patch to 'add NULL checkings'. > Upstream adds a few more if statements to avoid the segmentation > fault, and thus resolve the security vulnerability. > > [ Other info ] > If you can spare the time, could you please upload this for me? (I need > a sponsor, #1068624.) I'm also still waiting for someone to give me > access to the Salsa repo. > > Thanks, > Maytham > diff -Nru cjson-1.7.15/debian/changelog cjson-1.7.15/debian/changelog > --- cjson-1.7.15/debian/changelog 2021-08-29 23:30:06.0 +0300 > +++ cjson-1.7.15/debian/changelog 2024-04-03 06:57:10.0 +0300 > @@ -1,3 +1,13 @@ > +cjson (1.7.15-1+deb12u1) bookworm-security; urgency=medium The target distribution should be simply bookworm. > + > + * Update Maintainer field > + * Bump Standards-Version to 4.6.2 (no changes) This is usually not allowed to do in a stable update. > + * Backport patch to add NULL checkings (CVE-2023-50472, CVE-2023-50471) > +(Closes: #1059287) > + * Add Build-Depends-Package to symbols While this might be sensible, I'm not sure if SRM will accept it. So you might want to adjust already the things above and seek for an ack from SRM. Regards, Salvatore
Bug#1066965: bookworm-pu: package newlib/3.3.0-2
Hi, On Tue, Apr 02, 2024 at 12:36:53PM +0200, Petter Reinholdtsen wrote: > > Btw, what is the timeline for approval or rejection for this security > upload proposal? Note that if you are confident that the upload is accepted as it, you *could* already upload according to the improved workflow. *But* given the uncertainity if SRM want you to have the version changed I would wait for their ack. Regards, Salvatore
Bug#1066965: bookworm-pu: package newlib/3.3.0-2
Hi [disclaimer, not an authoritative answer as not part of the stable release managers] On Sat, Mar 16, 2024 at 09:09:05AM +0100, Petter Reinholdtsen wrote: > > Package: release.debian.org > > The https://tracker.debian.org/pkg/newlib > package got an open > security problem with malloc and friends in stable and oldstable, see > https://bugs.debian.org/984446 > for the CVE issue. The package > is orphaned. > > I would like to fix the bug at least in stable, and propose the > following upload. The change is already in the git repo on salsa in the > debian/bookworm branch. The problem is already fixed in unstable and > testing with a new version of the upstream code. The fix to stable is > only the minimal patch to solve the issue. > > I propose to use the version number 3.3.0-2, but am open to better > proposals. The version in testing is 4.4.0.20231231-2. Usually you would choose for this update 3.3.0-1.3+deb12u1, but given 3.3.0-2 was never present in unstable and the version later moved on, this is in theory possible. > > Complete proposed patch is below: > > diff --git a/debian/changelog b/debian/changelog > index b3e3ef851..1c8ddc5cb 100644 > --- a/debian/changelog > +++ b/debian/changelog > @@ -1,3 +1,12 @@ > +newlib (3.3.0-2) bookworm; urgency=medium > + > + * QA upload. > + * Orphan package to reflect status in Unstable. > + * Added mallocr-CVE-2021-3420.patch to solve incorrect overflow > +check in malloc and friends. I would add as well the bug closer for #984446. Regards, Salvatore
Uploading linux (6.7.9-2)
Hi While I realize there are much of changes going on unstable, I still would like to upload linux version (6.7.9-2) (yes no new upstream version) mitigating the Register File Data Sampling (RFDS) vulnerability (CVE-2023-28746). This goes along with a intel-microcode update which already was uploaded to unstable: https://tracker.debian.org/news/1511674/accepted-intel-microcode-3202403121-source-into-unstable/ * [x86] Mitigate Register File Data Sampling (RFDS) vulnerability (CVE-2023-28746): - x86/mmio: Disable KVM mitigation when X86_FEATURE_CLEAR_CPU_BUF is set - Documentation/hw-vuln: Add documentation for RFDS - x86/rfds: Mitigate Register File Data Sampling (RFDS) - KVM/x86: Export RFDS_NO and RFDS_CLEAR to guests Regards, Salvatore signature.asc Description: PGP signature
Uploading linux (6.7.9-1)
Hi I would like to upload linux version 6.7.9-1 to unstable soon if possible. There is the import of 6.7.8 and 6.7.9 from the 6.7.y stable series. Note that src:linux is not binNMU safe buildable and thus this is (for the time beeing) disabled since https://salsa.debian.org/kernel-team/linux/-/commit/d7ea1ea90ff4901a89fec9065427ed522f2fa2d9 This means that the triggered rebuilds for the time_t transition did fail: https://buildd.debian.org/status/package.php?p=linux There is planned to include a bugfix as well on top: * [x86] platform/x86: p2sb: On Goldmont only cache P2SB and SPI devfn BAR (Closes: #1065320) Regards, Salvatore signature.asc Description: PGP signature
Uploading linux (6.7.7-1)
Hi I would like to upload linux version 6.7.7-1 to unstable over the weekend. The new upload would consist of a new upstream version switching to the 6.7.y series in unstable. Apart from switching from 6.6.y to 6.7.y series there are additional changes covering: * Enable CONFIG_MFD_RK8XX_SPI for RK3588 SoC - MFD_RK8XX_SPI as built-in, same behavior as MFD_RK8XX_I2C * [armhf] Enable DRM_PANEL_MIPI_DBI as a module for stm32mp157c-lxa-tac-gen2. * Backport a patch from v6.8-rc1 to be more verbose about pending deferred probes helping debugging of failed boot attempts. * [arm64] Make PINCTRL_ROCKCHIP builtin. * [x86] drivers/hwmon: Enable SENSORS_HP_WMI as module (Closes: #1064507) * [loong64] Build kernel image and udebs for loong64 (Closes: #1053650) The following were already included in earlier experimental uploads: * [riscv64] Add clock, MFD, PCIe PHYs, regulator and RTC drivers to kernel-image udeb. * [riscv64] Disable CRYPTO_DEV_JH7110, it is broken. * Make linux-libc-dev provide all cross packages. * Input: atkbd - skip ATKBD_CMD_SETLEDS when skipping ATKBD_CMD_GETID (Closes: #1061521) * [arm64] drivers/thermal/qcom: enable QCOM_SPMI_ADC_TM5 as module for thermal throttling on the Lenovo ThinkPad X13s. * drivers/hwmon: Enable SENSORS_IIO_HWMON as module (Closes: #1057272) * Enable bcachefs filesystem support - fs/bcachefs: Enable BCACHEFS_FS as module - fs/bcachefs: Enable BCACHEFS_QUOTA - fs/bcachefs: Enable BCACHEFS_POSIX_ACL * media: solo6x10: replace max(a, min(b, c)) by clamp(b, a, c) * [riscv64] Enable ARCH_SOPHGO and ARCH_THEAD. * [riscv64] Disable ARCH_R9A07G043 as it now depends on NONPORTABLE. * [riscv64] Enable PHY_STARFIVE_JH7110_DPHY_RX, PHY_STARFIVE_JH7110_PCIE and PHY_STARFIVE_JH7110_USB as modules. * [powerpc,ppc64,ppc64el] Drop ipddp from nic-modules. * [riscv64] Enable LEDS_PWM and LEDS_PWM_MULTICOLOR as modules. * [arm64, armhf] drivers/net/phy: Enable ADIN_PHY as module (Closes: #1043354) * [arm64] Enable CSI camera stack for i.MX8M SoCs (Closes: #1055442) * Enable configs for MT8195 Chromebooks: - COMMON_CLK_MT8195 as built-in - COMMON_CLK_MT8195_APUSYS, COMMON_CLK_MT8195_AUDSYS, COMMON_CLK_MT8195_IMP_IIC_WRAP, COMMON_CLK_MT8195_MFGCFG, COMMON_CLK_MT8195_MSDC, COMMON_CLK_MT8195_SCP_ADSP, COMMON_CLK_MT8195_VDOSYS, COMMON_CLK_MT8195_VPPSYS, COMMON_CLK_MT8195_CAMSYS, COMMON_CLK_MT8195_IMGSYS, COMMON_CLK_MT8195_WPESYS, COMMON_CLK_MT8195_VDECSYS, COMMON_CLK_MT8195_VENCSYS as modules - MFD_MT6360, REGULATOR_MT6315, REGULATOR_MT6359, REGULATOR_CROS_EC, MTK_LVTS_THERMAL as modules - MTK_ADSP_MBOX, MTK_ADSP_IPC, SND_SOC_SOF_OF, SND_SOC_MT8195, SND_SOC_MT8195_MT6359, SND_SOC_SOF_MT8195 as modules - SND_SOC_SOF_TOPLEVEL, SND_SOC_SOF_MTK_TOPLEVEL as built-in - DRM_MEDIATEK_DP, PHY_MTK_DP, PHY_MTK_PCIE, PHY_MTK_UFS as modules - PINCTRL_MT8195, PCIE_MEDIATEK_GEN3, SPMI_MTK_PMIF as built-in * [arm64] drivers/rtc: Enable RTC_DRV_RS5C372 as module * Revert "Run dh_movetousr also in signed images." * Fix config specified CFLAGS on kernel builds. Also drop old definitions that have not worked for a long time. * Disable ability to do binNMU. The Debian infrastructure is not ready to binNMU signed packages. But they instead just break the dependencies within this package. * Restructure and cleanup complete config: - Uses TOML instead of our home-grown INI based format. - Don't export a config dump anymore, it is not longer in use. * Generate and ship vmlinux.h in linux-headers package. * [arm64] Set QCOM_QSEECOM and QCOM_QSEECOM_UEFISECAPP to 'y' in order to add support for EFI variables on the Lenovo X13s. * [arm64] Support HDMI output on TI SK-AM62. Enable DRM_SII902X and DRM_TIDSS as modules. * [arm64] udeb: Include sun8i-drm-hdmi module in installer (Closes: #1050315) * Generate separate package tests for every flavour. * Fix stripping of vmlinux binaries. (closes: #1059713) * Ignore vmlinux for shlibs. (closes: #1059676) * Drop not working selftests. (closes: #1059765) * Always build with CROSS_COMPILE set. * Run dh_movetousr also in signed images. * Fix some remaining cross build problems. * Enable MODULE_DECOMPRESS * [ppc64] Build PowerNV PCIe hotplug driver as a module * [riscv64] udeb: Add efi-modules and xfs-modules. * [arm64] Add support for NXP i.MX8M PCIe - drivers/phy/freescale: Enable PHY_FSL_IMX8M_PCIE as module I hope it's not too much controversial to make this switch now to the 6.7.y series. Regards, Salvatore signature.asc Description: PGP signature
Bug#1061190: bullseye-pu: package gnutls28/3.7.1-5+deb11u5
Hi Andreas, On Thu, Feb 01, 2024 at 06:35:38AM +, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Sat, 2024-01-20 at 15:53 +0100, Andreas Metzler wrote: > > I would like to fix both CVE-2024-0567 and CVE-2024-0553 via a > > oldstable-updates since they do not require a DSA. > > Please go ahead. Andreas did you saw the ack from Adam? FTR, please keep the CVE references now as we have the incomplete fix in bullseye for CVE-2023-5981 with the 3.7.1-5+deb11u4 . Regards, Salvatore
Bug#1063675: bookworm-pu: package nvidia-graphics-drivers/525.147.05-6~deb12u1
Hi Andreas, On Mon, Feb 12, 2024 at 12:37:44AM +0100, Andreas Beckmann wrote: > On 11/02/2024 21.36, Salvatore Bonaccorso wrote: > > If I can add a comment: I (but note I'm not wearing a > > nvidia-graphics-drivers maintainer hat) would support that, as there > > are enough people affected by this. This is quite unfortunate and I'm > > open to hear ideas how we can try to avoid such fallouts. > > I was aware of the bug (#1062932) but not of the fact a point release was > upcoming. Even if I had been aware of the point release I'm not sure if I > had realized the impact of this bug to make me yell ;-) > Perhaps once point release dates have been choosen, this could be announced > to d-d-a@ as well. > I'm not following debian-release@ ... -ENOTIME > > > As you know we are strictly following upstream stable series (and > > trying our best to keep an eye on as well regression reports upstream, > > but OOT modules are not explicitly tested, so neither the nvidia ones) > > Are autopkgtests being run for proposed-updates? That should have shown the > issue. Yes there are in fact autopkgtests being run, so this should have been catched (and at least decided what to do, i.e. not release 6.1.76-1, nod ideal, or deal during the still allowed window with the nvidia drivers as well). But to be very honest: I did miss this regression report on the overview page. At least according to Paul on IRC the test should have been run. > It was unfortunate that this upstream backported change appeared in > proposed-updates first and in sid only a few days later. And the > metapackages from linux-signed-amd64 are still depending on the version > before this change was introduced ... so I only could reproduce the issue > (and verify fixes) manually. (The module build test done during the package > build did not use the regressing headers.) Right, 6.6.15 upload to unstable had a couple of issues, first failing to build the arch:all packages then the linux-signed-amd64 were waiting to be processed, and once that happened, we have now a FTBFS due to interaction with a new kmod upload (Filled #1063804). It is not that usual that otherwise we would have that change in bookworm (queued in proposed-updates) before we had a similar change in unstable (or experimental). > Then I had to spent quite some time verifying that the issue only happened > on amd64 and since the 460 series (despite of ppc64el having even more calls > to pfn_valid() dating back to the 418 series). I would like to thank you again for the time you invested here to deal with that issue! > Andreas > > PS: @Salvatore: Looking forward to see some linux 6.8 packages in > experimental s.t. I can throw them in my module build chroot to see what > breaks next :-) Or do you already have some early build available somewhere > while experimental is still preparing 6.7? We have to move 6.7.y next to unstable. But I'm not completely sure if we are there yet, need to ask Bastian Blank about the plan. After that experimental is freed we can go aehad with 6.8.y for experimental, but there are yet no packages to test with :( Regards, Salvatore
Bug#1063675: bookworm-pu: package nvidia-graphics-drivers/525.147.05-6~deb12u1
Hi Jonathan, On Sun, Feb 11, 2024 at 12:29:45AM +, Jonathan Wiltshire wrote: > Control: tag -1 confirmed > > On Sat, Feb 10, 2024 at 11:00:58PM +0100, Andreas Beckmann wrote: > > [ Reason ] > > 1) A backported (by upstream) change in Linux 6.1.76 (included in > > today's point release) broke compilation of the non-free nvidia kernel > > module. A patched version of the driver is available in sid. > > > > 2) In order to simplify future maintenance of the many Nvidia driver > > packages (also in stable and oldstable) I'm going to remove the > > distinction between "normal" and "Tesla" drivers (they were at the > > same version in stable anyway). The Tesla specific bits > > (src:nvidia-graphics-drivers-tesla) will be merged into > > src:nvidia-graphics-drivers (that mainly means addition of the ppc64el > > architecture to these packages, and building some binary packages from > > src:nvidia-graphics-drivers instead: nvidia-powerd, nvidia-cuda-mps). > > nvidia-detect has been updated, too, as it no longer needs to > > distinguish the Tesla variants. > > There will be one further update to src:nvidia-graphics-drivers-tesla > > in stable that turns these packages into transitional packages depending > > on their counterparts from src:nvidia-graphics-drivers. (Separate PU > > request upcoming.) > > There will also be a PU request for nvidia-settings, as we need to > > enable building that on ppc64el. (The src:nvidia-settings-tesla package > > will then become obsolete.) > > > > 3) In order to better integrate the nvidia driver with the system power > > management, a new package nvidia-suspend-common is being introduced > > which properly ships and enables some systemd units that were previously > > only being shipped as examples. These power management changes are an > > enhancement for the 525 series, but seem to be required in the 535 > > series. (We will have to switch to the 535 LTSB series in stable soon, > > as 525 has reached EoL. 535 will be supported till mid 2026, so that will > > be the last driver branch switch for bookworm.) > > nvidia-suspend-common was already prepared in the previous pu update, > > but not yet enabled on stable as it hadn't undergone enough testing. As > > no new issues have popped up on sid, I'm confident to enable this in > > stable now. > > Please go ahead. Is this something we should release early through > stable-updates, given the breakage is caused by a point release? If I can add a comment: I (but note I'm not wearing a nvidia-graphics-drivers maintainer hat) would support that, as there are enough people affected by this. This is quite unfortunate and I'm open to hear ideas how we can try to avoid such fallouts. As you know we are strictly following upstream stable series (and trying our best to keep an eye on as well regression reports upstream, but OOT modules are not explicitly tested, so neither the nvidia ones) Regards, Salvatore
Bug#1057107: bullseye-pu: package libssh2/1.9.0-2
Hi Nicolas, On Tue, Feb 06, 2024 at 01:46:04PM -0500, Nicolas Mora wrote: > Control: tag - moreinfo > > Thanks, > > Sorry, it seems that I'm not very well aware of the BTS process, according > to [1] this is how I should untag the bug. > > [1] https://www.debian.org/Bugs/server-control If you provide the moreinfo which was requested, then you can remove the tag as follows (or with an equivalent control command, e.g. using -1 for the bug if directly interacting with the bug). tags 1057107 - moreinfo Hope this helps, too bad we missed for this upload the 11.9. Regards, Salvatore
Re: Uploading linux (6.6.15-1)
Hi, On Sat, Feb 03, 2024 at 12:32:08AM +0100, Cyril Brulebois wrote: > Salvatore Bonaccorso (2024-02-02): > > One thing is still unresolved, thus additonally to the explicit CC to > > kibi, as well including debian-boot. We have the armel d-i situation > > not yet resolved, debian-boot folks, do you have any imput on the > > situation from the thread in > > https://lists.debian.org/debian-release/2024/01/msg00089.html ? > > My gut feeling from what was discussed is that nobody will ever use > > the d-i on armel. > > I'm not sure how much time armel will stick around (for existing > systems), but it looks to me that d-i/armel is no longer relevant. Thanks for your reply on d-i side of this. So i suggest we move ahead with transitioning 6.6.y to testing accordingly. Thanks a lot! Regards, Salvatore
Uploading linux (6.6.15-1)
Hi,
I would like to upload linux version 6.6.15-1 ideally over the weekend
to unstable. The new version imports two versions of the 6.6.y stable
series (which is upstream an LTS) up to 6.6.15. It contains a larger
amount of changes as it consisted of versions released after the merge
window upstream for 6.8. Some CVEs are addressed in this update:
CVE-2023-46838, CVE-2023-50431, CVE-2024-1085 and CVE-2024-1085.
As there is an upcoming pont release on weekend of 10th of february
and as the linux uploads for both bullseye 11.9 and bookworm 12.5
needs to be ready over the weekend, those should get priority in terms
of having the signed packages available (the rest is done). So maybe
6.6.15-1 should be accetepd to be build and then signed packages done
only after we have the linux-signed-{i386,amd64,arm64} for both
bullseye-pu and bookworm-pu.
One thing is still unresolved, thus additonally to the explicit CC to
kibi, as well including debian-boot. We have the armel d-i situation
not yet resolved, debian-boot folks, do you have any imput on the
situation from the thread in
https://lists.debian.org/debian-release/2024/01/msg00089.html ?
My gut feeling from what was discussed is that nobody will ever use
the d-i on armel.
There are no other packaging changes apart patches refresh (and
upstream applied patches) for the rt featureset due to the 6.6.14 and
6.1.15 imports.
Regards,
Salvatore
signature.asc
Description: PGP signature
Uploading linux (6.6.13-1)
I would like to upload linux version 6.6.13-1 later today to unstable. The new version imports two versions of 6.6.y stable series (though the only commit from 6.6.12 was already included in the last update). The new upstream stable version fixes CVE-2023-6610 and CVE-2023-6915. Note, that the armel situation is still unresolved from the https://lists.debian.org/debian-release/2024/01/msg00089.html thread. Still still will prevent us thus to go with the 6.6.y series to testing. Regards, Salvatore signature.asc Description: PGP signature
Bug#1061190: bullseye-pu: package gnutls28/3.7.1-5+deb11u5
Hi, On Sat, Jan 20, 2024 at 03:53:45PM +0100, Andreas Metzler wrote: > Package: release.debian.org > Severity: normal > Tags: bullseye > User: release.debian@packages.debian.org > Usertags: pu > X-Debbugs-Cc: gnutl...@packages.debian.org, t...@security.debian.org > Control: affects -1 + src:gnutls28 > > Hello, > > I would like to fix both CVE-2024-0567 and CVE-2024-0553 via a > oldstable-updates since they do not require a DSA. Only a small remark about the CVE tracking, no direct need to change anything: CVE-2024-0553 exists because of an incomplete fix of CVE-2024-0553, so technically weh ave that incomplete fix not yet in any official bullseye release (apart the bullseye-pu). For the security-tracker so I tend to consider CVE-2024-0553 not-affected for bullseye, but then CVE-2023-5981 only fixed in 3.7.1-5+deb11u5 rather than 3.7.1-5+deb11u4. For that I have done the following two commits: https://salsa.debian.org/security-tracker-team/security-tracker/-/commit/f30f93b036b864eb245daf7dec5f70a824a7fb5c https://salsa.debian.org/security-tracker-team/security-tracker/-/commit/0fd218ec683140739797aa973d354e00b8660e9b Let me know if you diagree and we should revert that to track all 3 CVEs for gnutls28 in bullseye. Regards, Salvatore
Bug#1061177: bullseye-pu: package tar/1.34+dfsg-1+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: t...@packages.debian.org, Janos Lenart ,
car...@debian.org
Control: affects -1 + src:tar
Dear Stable release managers,
[ Reason ]
tar in bullseye is affected by two issues with assigned CVEs,
CVE-2022-48303 and CVE-2023-39804 both which do not warrant a DSA and
have minor impact.
[ Impact ]
Remain vulnerable to the two CVEs, with DoS potential.
[ Tests ]
Verified the fixes against the PoCs available for both CVEs.
[ Risks ]
Should be minor, the fixes are targeted to address the respective
issues and taken from upstream git repository. Both fixes are
available in unstable and testing with no regression reporting to the
best of my knowledge.
[ 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 ]
The upstream changes fix the boundary checking in base-256 decoder for
CVE-2022-48303 and the handling of extended header prefixes for
CVE-2023-39804.
[ Other info ]
Nothing else.
Regards,
Salvatore
diff -Nru tar-1.34+dfsg/debian/changelog tar-1.34+dfsg/debian/changelog
--- tar-1.34+dfsg/debian/changelog 2021-02-17 10:55:26.0 +0100
+++ tar-1.34+dfsg/debian/changelog 2024-01-20 10:59:10.0 +0100
@@ -1,3 +1,12 @@
+tar (1.34+dfsg-1+deb11u1) bullseye; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix boundary checking in base-256 decoder (CVE-2022-48303)
+ * Fix handling of extended header prefixes (CVE-2023-39804)
+(Closes: #1058079)
+
+ -- Salvatore Bonaccorso Sat, 20 Jan 2024 10:59:10 +0100
+
tar (1.34+dfsg-1) unstable; urgency=medium
* New upstream version
diff -Nru
tar-1.34+dfsg/debian/patches/Fix-boundary-checking-in-base-256-decoder.patch
tar-1.34+dfsg/debian/patches/Fix-boundary-checking-in-base-256-decoder.patch
---
tar-1.34+dfsg/debian/patches/Fix-boundary-checking-in-base-256-decoder.patch
1970-01-01 01:00:00.0 +0100
+++
tar-1.34+dfsg/debian/patches/Fix-boundary-checking-in-base-256-decoder.patch
2024-01-20 10:59:10.0 +0100
@@ -0,0 +1,31 @@
+From: Sergey Poznyakoff
+Date: Sat, 11 Feb 2023 11:57:39 +0200
+Subject: Fix boundary checking in base-256 decoder
+Origin:
https://git.savannah.gnu.org/cgit/tar.git/commit/?id=3da78400eafcccb97e2f2fd4b227ea40d794ede8
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2022-48303
+
+* src/list.c (from_header): Base-256 encoding is at least 2 bytes
+long.
+---
+ src/list.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/src/list.c b/src/list.c
+index 9fafc425a824..86bcfdd1cc30 100644
+--- a/src/list.c
b/src/list.c
+@@ -881,8 +881,9 @@ from_header (char const *where0, size_t digs, char const
*type,
+ where++;
+ }
+ }
+- else if (*where == '\200' /* positive base-256 */
+- || *where == '\377' /* negative base-256 */)
++ else if (where <= lim - 2
++ && (*where == '\200' /* positive base-256 */
++ || *where == '\377' /* negative base-256 */))
+ {
+ /* Parse base-256 output. A nonnegative number N is
+represented as (256**DIGS)/2 + N; a negative number -N is
+--
+2.43.0
+
diff -Nru
tar-1.34+dfsg/debian/patches/Fix-handling-of-extended-header-prefixes.patch
tar-1.34+dfsg/debian/patches/Fix-handling-of-extended-header-prefixes.patch
--- tar-1.34+dfsg/debian/patches/Fix-handling-of-extended-header-prefixes.patch
1970-01-01 01:00:00.0 +0100
+++ tar-1.34+dfsg/debian/patches/Fix-handling-of-extended-header-prefixes.patch
2024-01-20 10:59:10.0 +0100
@@ -0,0 +1,62 @@
+From: Sergey Poznyakoff
+Date: Sat, 28 Aug 2021 16:02:12 +0300
+Subject: Fix handling of extended header prefixes
+Origin:
https://git.savannah.gnu.org/cgit/tar.git/commit/?id=a339f05cd269013fa133d2f148d73f6f7d4247e4
+Bug-Debian: https://bugs.debian.org/1058079
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2023-39804
+
+* src/xheader.c (locate_handler): Recognize prefix keywords only
+when followed by a dot.
+(xattr_decoder): Use xmalloc/xstrdup instead of alloc
+---
+ src/xheader.c | 17 +
+ 1 file changed, 9 insertions(+), 8 deletions(-)
+
+diff --git a/src/xheader.c b/src/xheader.c
+index 4f8b2b27cc62..3cd694d1b12a 100644
+--- a/src/xheader.c
b/src/xheader.c
+@@ -637,11 +637,11 @@ static struct xhdr_tab const *
+ locate_handler (char const *keyword)
+ {
+ struct xhdr_tab const *p;
+-
+ for (p = xhdr_tab; p->keyword; p++)
+ if (p->prefix)
+ {
+-if (strncmp (p->keyword, keyword, strlen(p->keyword)) == 0)
++ size_t kwlen = strlen (p->keyword);
++if (keyword[kwlen] == '.' && strncmp (p->keyword, keyword, kwlen) ==
0)
+
Bug#1061176: bookworm-pu: package tar/1.34+dfsg-1.2+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: t...@packages.debian.org, Janos Lenart ,
car...@debian.org
Control: affects -1 + src:tar
Dear Stable release managers,
[ Reason ]
tar in bookworm is affected by two issues with assigned CVEs,
CVE-2022-48303 and CVE-2023-39804 both which do not warrant a DSA and
have minor impact.
[ Impact ]
Remain vulnerable to the two CVEs, with DoS potential.
[ Tests ]
Verified the fixes against the PoCs available for both CVEs.
[ Risks ]
Should be minor, the fixes are targeted to address the respective
issues and taken from upstream git repository. Both fixes are
available in unstable and testing with no regression reporting to the
best of my knowledge.
[ 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 ]
The upstream changes fix the boundary checking in base-256 decoder for
CVE-2022-48303 and the handling of extended header prefixes for
CVE-2023-39804.
[ Other info ]
Nothing else.
Regards,
Salvatore
diff -Nru tar-1.34+dfsg/debian/changelog tar-1.34+dfsg/debian/changelog
--- tar-1.34+dfsg/debian/changelog 2023-04-06 16:25:47.0 +0200
+++ tar-1.34+dfsg/debian/changelog 2024-01-20 10:27:07.0 +0100
@@ -1,3 +1,12 @@
+tar (1.34+dfsg-1.2+deb12u1) bookworm; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix boundary checking in base-256 decoder (CVE-2022-48303)
+ * Fix handling of extended header prefixes (CVE-2023-39804)
+(Closes: #1058079)
+
+ -- Salvatore Bonaccorso Sat, 20 Jan 2024 10:27:07 +0100
+
tar (1.34+dfsg-1.2) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru
tar-1.34+dfsg/debian/patches/Fix-boundary-checking-in-base-256-decoder.patch
tar-1.34+dfsg/debian/patches/Fix-boundary-checking-in-base-256-decoder.patch
---
tar-1.34+dfsg/debian/patches/Fix-boundary-checking-in-base-256-decoder.patch
1970-01-01 01:00:00.0 +0100
+++
tar-1.34+dfsg/debian/patches/Fix-boundary-checking-in-base-256-decoder.patch
2024-01-20 10:27:07.0 +0100
@@ -0,0 +1,31 @@
+From: Sergey Poznyakoff
+Date: Sat, 11 Feb 2023 11:57:39 +0200
+Subject: Fix boundary checking in base-256 decoder
+Origin:
https://git.savannah.gnu.org/cgit/tar.git/commit/?id=3da78400eafcccb97e2f2fd4b227ea40d794ede8
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2022-48303
+
+* src/list.c (from_header): Base-256 encoding is at least 2 bytes
+long.
+---
+ src/list.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/src/list.c b/src/list.c
+index 9fafc425a824..86bcfdd1cc30 100644
+--- a/src/list.c
b/src/list.c
+@@ -881,8 +881,9 @@ from_header (char const *where0, size_t digs, char const
*type,
+ where++;
+ }
+ }
+- else if (*where == '\200' /* positive base-256 */
+- || *where == '\377' /* negative base-256 */)
++ else if (where <= lim - 2
++ && (*where == '\200' /* positive base-256 */
++ || *where == '\377' /* negative base-256 */))
+ {
+ /* Parse base-256 output. A nonnegative number N is
+represented as (256**DIGS)/2 + N; a negative number -N is
+--
+2.43.0
+
diff -Nru
tar-1.34+dfsg/debian/patches/Fix-handling-of-extended-header-prefixes.patch
tar-1.34+dfsg/debian/patches/Fix-handling-of-extended-header-prefixes.patch
--- tar-1.34+dfsg/debian/patches/Fix-handling-of-extended-header-prefixes.patch
1970-01-01 01:00:00.0 +0100
+++ tar-1.34+dfsg/debian/patches/Fix-handling-of-extended-header-prefixes.patch
2024-01-20 10:27:07.0 +0100
@@ -0,0 +1,62 @@
+From: Sergey Poznyakoff
+Date: Sat, 28 Aug 2021 16:02:12 +0300
+Subject: Fix handling of extended header prefixes
+Origin:
https://git.savannah.gnu.org/cgit/tar.git/commit/?id=a339f05cd269013fa133d2f148d73f6f7d4247e4
+Bug-Debian: https://bugs.debian.org/1058079
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2023-39804
+
+* src/xheader.c (locate_handler): Recognize prefix keywords only
+when followed by a dot.
+(xattr_decoder): Use xmalloc/xstrdup instead of alloc
+---
+ src/xheader.c | 17 +
+ 1 file changed, 9 insertions(+), 8 deletions(-)
+
+diff --git a/src/xheader.c b/src/xheader.c
+index 4f8b2b27cc62..3cd694d1b12a 100644
+--- a/src/xheader.c
b/src/xheader.c
+@@ -637,11 +637,11 @@ static struct xhdr_tab const *
+ locate_handler (char const *keyword)
+ {
+ struct xhdr_tab const *p;
+-
+ for (p = xhdr_tab; p->keyword; p++)
+ if (p->prefix)
+ {
+-if (strncmp (p->keyword, keyword, strlen(p->keyword)) == 0)
++ size_t kwlen = strlen (p->keyword);
++if (keyword[kwlen] == '.' && strncmp (p->keyword, keyword, kwlen) ==
0)
+
Re: Uploading linux (6.6.10-1)
Hi, On Sun, Jan 07, 2024 at 02:14:30PM +0100, Bastian Blank wrote: > On Sun, Jan 07, 2024 at 02:03:32PM +0100, Salvatore Bonaccorso wrote: > > I would like to upload linux version 6.6.10-1 later today to unstable. > > I would like to have 6.6.9 in testing first, but we can also ignore > that. No it's fine, I will wait for the 6.6.10-1 upload until 6.6.9-1 migrates. It should, but I'm unsure about the failing glibc autopkgtest on arm64 (OTOH you have filled #1060202, so if that's as well flacky then we could ignore those and let 6.6.9-1 migrate). Regards, Salvatore
Uploading linux (6.6.10-1)
Hi I would like to upload linux version 6.6.10-1 later today to unstable. The new version imports one more 6.6.y stable series version (6.6.10). The new upstream stable version fixes in particular CVE-2024-0193 (which is already addressed in bookworm-security and bullseye-security). There is one additional commit included (which is already queued for the next stable series) to address #1058887: * wifi: iwlwifi: pcie: don't synchronize IRQs from IRQ (Closes: #1058887) Regards, Salvatore signature.asc Description: PGP signature
Bug#1059291: bookworm-pu: package spip/4.1.9+dfsg-1+deb12u3
Hi, On Fri, Dec 22, 2023 at 01:28:00PM +0100, David Prévot wrote: > Package: release.debian.org > Severity: normal > Tags: bookworm > User: release.debian@packages.debian.org > Usertags: pu > X-Debbugs-Cc: s...@packages.debian.org, t...@security.debian.org > Control: affects -1 + src:spip > > Hi, > > This issue is similar to #1059289 for oldstable. > > Another upstream release fixed a security (XSS) issue. The last two > updates of this kind didn’t warrant a DSA, so I guess this one will not > warrant one either (security team X-D-CCed in case I’m wrong). To confirm, from security team perspective, this does not warrant a DSA and can be fixed in the upcoming point release. Regards, Salvatore
Bug#1059289: bullseye-pu: package spip/3.2.11-3+deb11u10
Hi, On Fri, Dec 22, 2023 at 01:21:56PM +0100, David Prévot wrote: > Package: release.debian.org > Severity: normal > Tags: bullseye > User: release.debian@packages.debian.org > Usertags: pu > X-Debbugs-Cc: s...@packages.debian.org, t...@security.debian.org > Control: affects -1 + src:spip > > Another upstream release fixed a security (XSS) issue. The last two > updates of this kind didn’t warrant a DSA, so I guess this one will not > warrant one either (security team X-D-CCed in case I’m wrong). To confirm, from security team perspective, this does not warrant a DSA and can be fixed in the upcoming point release. Regards, Salvatore
Bug#1059427: bullseye-pu: package haproxy/2.2.9-2+deb11u6
Hi, On Mon, Dec 25, 2023 at 10:35:16AM +0100, Tobias Frost wrote: > Package: release.debian.org > Severity: normal > Tags: bullseye > User: release.debian@packages.debian.org > Usertags: pu > X-Debbugs-Cc: hapr...@packages.debian.org, t...@security.debian.org > Control: affects -1 + src:haproxy > > Hi, > > For ELTS I was fixing haproxy's CVES CVE-2023-40225 and CVE-2023-45539, > and I also like to fix those for stable and oldstable. > > CC'ing the security team, in case they want to issue an DSA instead. > > The changes can also be found on the LTS repository: > https://salsa.debian.org/lts-team/packages/haproxy > > [ Tests ] > I've tested the fixes manually, using netcat to inject > problematic http requests and confirm that the patched > version rejects the malicous requests. (using nginx and > also netcat as http server.) > > (Being verbose here to document the tests for later reference ;-)) > > haproxy is listening on port 8080 > > e.g for CVE-2023-40225: > echo 'GET /index.nginx-debian.html# HTTP/1.0' | netcat localhost 8080 > must be rejected with 400 Bad Request > and without the "#" accepted. > > for CVE-2023-45539, nginx is stopped, and netcat listens on port 80: > echo 'GET / HTTP/.1.1 > host: whatever > content-length: > ' | netcat localhost 8080 > > If the request is accepted (and forwarded to the listening netcat), > haproxy is vulnerable. If a "400 Bad request" ist thrown, without > netcat receiving something, haproxy is not vulnerable. > > (haproxy is running on port 8080) > > [ Risks ] > Upstream patch, 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 > > Debdiff attached. > > I'v uploaded the package to o-s-p-u already. Thanks, but I have already worked on the haproxy update for bullseye and bookworm. SRM, can you please reject the packages from stable-new and olstable-new so once I release the DSA, that version won't clash versionwise? Regards, Salvatore
Bug#1059235: bookworm-pu: package fish/3.6.0-3.1+deb12u1
Hi, On Thu, Dec 21, 2023 at 03:16:22PM -0500, M. Zhou wrote: > Package: release.debian.org > Severity: normal > Tags: bookworm > User: release.debian@packages.debian.org > Usertags: pu > X-Debbugs-Cc: f...@packages.debian.org > Control: affects -1 + src:fish > > > [ Reason ] > > Cherry-pick upstream fix to CVE-2023-49284 > > [ Impact ] > > This is a low severity security issue that affects basically > all historical releases of fish. The upstream created new > releases (i.e. 3.6.2) solely for fixing this bug. > https://github.com/fish-shell/fish-shell/commits/Integration_3.6.2/ > So it would be good if we can integrate the fix into stable. > > > [ Tests ] > > The fix is already included in fish/3.6.4-1 (sid). > The rebased patch passed my local sbuild test. > I installed the package in a chroot and tested it. > > [ Risks ] > > 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 ] > > Only one change. Please refer to the patch header for explanation. > > [ Other info ] > > diff -Nru fish-3.6.0/debian/changelog fish-3.6.0/debian/changelog > --- fish-3.6.0/debian/changelog 2023-05-01 13:01:01.0 -0400 > +++ fish-3.6.0/debian/changelog 2023-12-21 14:47:56.0 -0500 > @@ -1,3 +1,9 @@ > +fish (3.6.0-3.1+deb12u1) bookworm; urgency=medium > + > + * Cherry-pick upstream fix for CVE-2023-49284. Can you as well add a bug closer for #1057455? Regards, Salvatore
Bug#1057179: Acknowledgement (bookworm-pu: package mariadb-10.6 1:10.11.6-0+deb12u1)
Hi Otto, On Sat, Dec 09, 2023 at 10:58:09PM +0800, Otto Kekäläinen wrote: > Hi Debian security team! > > MariaDB 1:10.11.6-1 entered Trixie only today after being stuck in > pending migration since Nov 28th from unstable. This > 1:10.11.6-0+deb12u1 missed the point update window. > > Are you OK if we proceed with this as a security upload? I do not think we really need that. There is only scarce informtaion on the only CVE fixed, CVE-2023-22084, and the official description seem to require a high privileged attacker. But maybe you could reach out to MariaDB upstream so we can have a better idea on the fixed issue? I would suggest you just upload what you prepared to the proposed-updates queues so it can exposed by further testing of the release team tooling, and it will be included in the 12.4 point release. That is not even a problem if there will be a later incremental update on it. Regards, Salvatore
Re: Bug#1057843: linux: ext4 data corruption in 6.1.64-1
Hi, On Sat, Dec 09, 2023 at 03:07:37PM +0100, Salvatore Bonaccorso wrote: > Source: linux > Version: 6.1.64-1 > Severity: grave > Tags: upstream > Justification: causes non-serious data loss > X-Debbugs-Cc: debian-release@lists.debian.org, car...@debian.org, > a...@debian.org > > Hi > > I'm filling this for visibility. > > There might be a ext4 data corruption issue with the kernel released > in the 12.3 bookworm point release (which is addressed in 6.1.66 > upstream already). > > The report about the regression and some details: > > https://lore.kernel.org/stable/20231205122122.dfhhoaswsfscuhc3@quack3/ 6.1.66 upstream fixes the issue: # uname -a Linux bookworm-amd64 6.1.0-15-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.66-1 (2023-12-06) x86_64 GNU/Linux # LTP_SINGLE_FS_TYPE=ext4 LTP_DEV_FS_TYPE=ext4 ./preadv03_64 tst_device.c:96: TINFO: Found free device 0 '/dev/loop0' tst_test.c:1690: TINFO: LTP version: 20230929-194-g5c096b2cf tst_test.c:1574: TINFO: Timeout per run is 0h 00m 30s tst_supported_fs_types.c:149: TINFO: WARNING: testing only ext4 tst_supported_fs_types.c:90: TINFO: Kernel supports ext4 tst_supported_fs_types.c:55: TINFO: mkfs.ext4 does exist tst_test.c:1650: TINFO: === Testing on ext4 === tst_test.c:1105: TINFO: Formatting /dev/loop0 with ext4 opts='' extra opts='' mke2fs 1.47.0 (5-Feb-2023) tst_test.c:1119: TINFO: Mounting /dev/loop0 to /tmp/LTP_preGGYjTj/mntpoint fstyp=ext4 flags=0 preadv03.c:102: TINFO: Using block size 512 preadv03.c:87: TPASS: preadv(O_DIRECT) read 512 bytes successfully with content 'a' expectedly preadv03.c:87: TPASS: preadv(O_DIRECT) read 512 bytes successfully with content 'a' expectedly preadv03.c:87: TPASS: preadv(O_DIRECT) read 512 bytes successfully with content 'b' expectedly Summary: passed 3 failed 0 broken 0 skipped 0 warnings 0 Regards, Salvatore
Bug#1057843: linux: ext4 data corruption in 6.1.64-1
Source: linux Version: 6.1.64-1 Severity: grave Tags: upstream Justification: causes non-serious data loss X-Debbugs-Cc: debian-release@lists.debian.org, car...@debian.org, a...@debian.org Hi I'm filling this for visibility. There might be a ext4 data corruption issue with the kernel released in the 12.3 bookworm point release (which is addressed in 6.1.66 upstream already). The report about the regression and some details: https://lore.kernel.org/stable/20231205122122.dfhhoaswsfscuhc3@quack3/ Regards, Salvatore
Re: maintainer built binary package in stable release, still (Re: Bug#1054401: bookworm-pu: package nagios-plugins-contrib/42.20230308+deb12u1)
Hi Adam, On Thu, Dec 07, 2023 at 01:56:34PM +, Adam D. Barratt wrote: > On Thu, 2023-12-07 at 12:40 +0100, Paul Gevers wrote: > > Hi, > > > > On 07-12-2023 12:20, Adrian Bunk wrote: > > > On Thu, Dec 07, 2023 at 11:18:42AM +0100, Paul Gevers wrote: > > > > I hope that in several hours, > > > > https://release.debian.org/britney/excuses_s-p-u.html will have > > > > the answer. > > > > > > it should find packages like jtreg6 that are scheduled for the next > > > point release, but it won't find packages like gmp that went into > > > bullseye 2 years ago. > > > > Ack. Indeed it spots: > > cacti, fastdds, freetype, grub-efi-amd64-signed, grub-efi-arm64- > > signed, > > grub-efi-ia32-signed, jtreg6, llvm-toolchain-16, node-babel7, > > node-browserify-sign and slurm-wlm. A bunch of them have arch:all > > binaries. > > Heh at cacti being in the list. :-) > > fwiw the grub-efi-*-signed packages were built on buildds, in the > security archive. They got rejected when they were copied over to ftp- > master, due to the grub2 versus grub-efi-* naming issue that's been > mentioned on debian-release before. In order to get them into stable- > new, I resigned the changes files and re-uploaded them. The packages > themselves are identical to those released via security.d.o (they're > the same files). > > Similarly, the two fastdds uploads were rejected between the security > archive and ftp-master as the buildd keys had expired in the meantime, > so I simply re-signed and re-uploaded them. > > Relatedly, if a binary upload was performed to the security archive > then any binNMUs should likely happen there and then be synced across > to stable, otherwise we're only resolving part of the issue. Hmm technically likely right, but in security we cannot very well handle the binNMUs (only if the source is already present there, otherwise ftp-masters need to inject the sources first). This is related to https://wiki.debian.org/DebianSecurity/AdvisoryCreation/SecFull?highlight=%28gen-DSA%29#BinNMUs and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823820 (well more broadly to have source available). Regards, Salvatore
Re: Bug in linux 6.1.64-1 (source) into proposed-updates
Hi,
On Tue, Dec 05, 2023 at 06:14:43PM +0100, djw6g6b5...@temp.mailbox.org wrote:
> There' s a bug in linux-image-amd64 version 6.1.64-1 for bookworm.
> The updates breaks wlan on a Lenovo T490s. Current versions used to work
> fine. I' m unable to submit a bug report. ('Message with no Package: tag
> cannot be processed! (linux-image-amd64 (version 6.1.64-1 breaks Wlan
> functionality))
> ')
>
> Can you please pass this Info to the maintainers? If any more info is needed
> please let me know.
Please do fill a bug, ideally with reportbug so additional system
information is already attached with the initial report. Please do
attach to that bug report as well kernel logs.
If you cannot use reportbug, the above seems to indicate that, then
make sure to add the pseudo-headers as well as described in
https://www.debian.org/Bugs/Reporting .
Hope this helps already,
Regards,
Salvatore
Bug#1057274: bookworm-pu: package gimp/2.10.34-1+deb12u2
Hi Adrian, On Sat, Dec 02, 2023 at 04:46:22PM +0200, Adrian Bunk wrote: > Package: release.debian.org > Severity: normal > Tags: bookworm > User: release.debian@packages.debian.org > Usertags: pu > X-Debbugs-Cc: Salvatore Bonaccorso > > * Add Conflicts+Replaces: gimp-dds to remove old versions of this > plugin shipped by gimp itself since 2.10.10. (Closes: #1057149) > > gimp-dds is an older version of a plugin already included > in gimp in bookworm, it also has CVE-2023-1 (DSA-5564-1) > unfixed. > > Removal of gimp-dds from bookworm has already been requested > in #1056710, this update additionally removes stale versions > a user might still have installed. Thanks for taking care of it. Regards, Salvatore
Bug#1054421: bookworm-pu: package weborf/0.19
Hi Salvo, On Wed, Nov 29, 2023 at 11:39:40PM +0100, Salvo Tomaselli wrote: > Hello, > > Go ahead with what? > > Do a new debdiff with the fixed version in the changelog? I understand Adam as "please just adjust the version as discussed to 0.19-2.1+deb12u1 and then feel free to upload the package for bookworm". Regards, Salvatore
Uploading linux (6.5.13-1)
Hi, I would like to upload linux version 6.5.13-1 today to unstable. The new version imports new stable series up to 6.5.13. A (manual) ABI bump is included. With the upload CVE-2023-6111 is addressed as well. The RT patchset remains disabled and is pending to be enabled with the 6.6.y versions to experimental. After at least one upload of the 6.6.y series to experimental, we *might* move it to unstable, but Bastian has a better overview if we will be already able to do it. There are no other packaging changes this time apart the ABI bump. Regards, Salvatore signature.asc Description: PGP signature
Bug#1007884: bullseye-pu: package glewlwyd/2.5.2-2+deb11u2
Hi Nicolas, On Mon, Nov 27, 2023 at 08:00:39AM -0500, Nicolas Mora wrote: > Hello, > > Here is a new debdiff for the glewlwyd/2.5.2-2+deb11u2 package, which now > also includes the fix for CVE-2023-49208. > diff -Nru glewlwyd-2.5.2/debian/changelog glewlwyd-2.5.2/debian/changelog > --- glewlwyd-2.5.2/debian/changelog 2021-12-17 07:51:46.0 -0500 > +++ glewlwyd-2.5.2/debian/changelog 2023-11-24 08:14:30.0 -0500 > @@ -1,3 +1,18 @@ > +glewlwyd (2.5.2-2+deb11u2.1) bullseye; urgency=medium Small remark, the version ideally is set to 2.5.2-2+deb11u3. Regards, Salvatore
Bug#1056711: RM: gimp-dds/3.0.1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm X-Debbugs-Cc: t...@security.debian.org, Adrian Bunk , car...@debian.org Dear stable release managers, Please remove src:gimp-dds in the next bullseye point release. It has since gimp 2.10.10 upstream been integrated upstream. Removal is possible: carnil@coccia:~$ dak rm --suite=bullseye -n -R gimp-dds Will remove the following packages from bullseye: gimp-dds |3.0.1-1 | source gimp-dds | 3.0.1-1+b1 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x Maintainer: Debian Games Team --- Reason --- -- Checking reverse dependencies... No dependency problem found. carnil@coccia:~$ For unstable it has been removed this year with #1043520. Additionally a gimp point release update might add a Breaks so the package get as well deinstalled. Regards, Salvatore
Bug#1056710: RM: gimp-dds/3.0.1-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm X-Debbugs-Cc: t...@security.debian.org, b...@debian.org, car...@debian.org Dear stable release managers, Please remove src:gimp-dds in the next bookworm point release. It has since gimp 2.10.10 upstream been integrated upstream. Removal is possible: carnil@coccia:~$ dak rm --suite=bookworm -n -R gimp-dds Will remove the following packages from bookworm: gimp-dds |3.0.1-3 | source, amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x Maintainer: Debian QA Group --- Reason --- -- Checking reverse dependencies... No dependency problem found. carnil@coccia:~$ For unstable it has been removed this year with #1043520. Additionally a gimp point release update might add a Breaks so the package get as well deinstalled. Regards, Salvatore
Bug#1055965: bookworm-pu: package network-manager-openconnect/1.2.8-3+deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: network-manager-openconn...@packages.debian.org, Florian Echtler , Luca Boccassi , car...@debian.org Control: affects -1 + src:network-manager-openconnect Hi Stable release managers, [ Reason ] In recent cases where institutions updated their Cisco AnyConnect server, connecting with openconnect requires to pass an appropriate UserAgent. Cf. for instance https://gitlab.com/openconnect/openconnect/-/issues/544 . network-manager-openconnect plugin for NetworkManager had no possibilty to configure this. As result after such updates users using the NetworkManager plugin cannot connect to the VPN servers. [ Impact ] Impossibility to use the NetworkManager plugin for openconnect in situations where the Cisco AnyConnect server has been updated. [ Tests ] I manually tested the plugin in one affected configuration. After the update the GUI field for configuring the UserAgent can be configured for the specific configuration. [ Risks ] Patches have been taken from upstream and apply with minor context tewak to the older version. Luca has reviewed and acked the MR in https://salsa.debian.org/debian/network-manager-openconnect/-/merge_requests/6 [ Checklist ] [x] *all* changes are documented in the d/changelog (the salsa pipleline one is not, but has not a user impact) [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 ] Adds support for the mentioned UserAgent field and setting. [ Other info ] Nothing. Regards, Salvatore diff -Nru network-manager-openconnect-1.2.8/debian/changelog network-manager-openconnect-1.2.8/debian/changelog --- network-manager-openconnect-1.2.8/debian/changelog 2022-05-21 15:35:15.0 +0200 +++ network-manager-openconnect-1.2.8/debian/changelog 2023-11-14 15:15:44.0 +0100 @@ -1,3 +1,14 @@ +network-manager-openconnect (1.2.8-3+deb12u1) bookworm; urgency=medium + + [ Salvatore Bonaccorso ] + * Add User Agent to Openconnect VPN for NetworkManager (Closes: +#1053467) + * Use openconnect_set_useragent() where available + * Add support for GTK4 in user-agent calls + * Add Build-Depends on libgtk-4-bin for gtk4-builder-tool + + -- Luca Boccassi Tue, 14 Nov 2023 14:15:44 + + network-manager-openconnect (1.2.8-3) unstable; urgency=medium * Bump Standards-Version to 4.6.1, no changes diff -Nru network-manager-openconnect-1.2.8/debian/control network-manager-openconnect-1.2.8/debian/control --- network-manager-openconnect-1.2.8/debian/control2022-05-21 15:35:15.0 +0200 +++ network-manager-openconnect-1.2.8/debian/control2023-11-14 15:15:44.0 +0100 @@ -8,6 +8,7 @@ libgcr-3-dev, libglib2.0-dev, libgtk-3-dev, + libgtk-4-bin, libgtk-4-dev, libnm-dev, libnma-dev, diff -Nru network-manager-openconnect-1.2.8/debian/gbp.conf network-manager-openconnect-1.2.8/debian/gbp.conf --- network-manager-openconnect-1.2.8/debian/gbp.conf 2022-03-14 00:08:09.0 +0100 +++ network-manager-openconnect-1.2.8/debian/gbp.conf 2023-11-14 15:15:44.0 +0100 @@ -1,5 +1,6 @@ [DEFAULT] pristine-tar = True +debian-branch = debian/bookworm [import-orig] upstream-vcs-tag = %(version)s diff -Nru network-manager-openconnect-1.2.8/debian/patches/0002-Add-User-Agent-to-Openconnect-VPN-for-NetworkManager.patch network-manager-openconnect-1.2.8/debian/patches/0002-Add-User-Agent-to-Openconnect-VPN-for-NetworkManager.patch --- network-manager-openconnect-1.2.8/debian/patches/0002-Add-User-Agent-to-Openconnect-VPN-for-NetworkManager.patch 1970-01-01 01:00:00.0 +0100 +++ network-manager-openconnect-1.2.8/debian/patches/0002-Add-User-Agent-to-Openconnect-VPN-for-NetworkManager.patch 2023-11-14 15:15:44.0 +0100 @@ -0,0 +1,302 @@ +From: Debasish Patra +Date: Sat, 29 Aug 2020 17:58:16 -0400 +Subject: Add User Agent to Openconnect VPN for NetworkManager +Origin: https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/-/commit/b5e154c06fd9013a925f85c2aa38d88e4ee53db0 +Bug-Debian: https://bugs.debian.org/1053467 + +--- + auth-dialog/main.c| 3 +- + properties/nm-openconnect-dialog.ui | 73 +-- + properties/nm-openconnect-editor-plugin.c | 5 ++ + properties/nm-openconnect-editor.c| 15 + + shared/nm-service-defines.h | 1 + + 5 files changed, 79 insertions(+), 18 deletions(-) + +diff --git a/auth-dialog/main.c b/auth-dialog/main.c +index 99cab7cd921f..305b568650ba 100644 +--- a/auth-dialog/main.c b/auth-dialog/main.c +@@ -1853,6 +1853,7 @@ static void build_main_dialog(auth_ui_data *ui_data) + + static auth_ui_data *init_ui_data (char *vpn_name, GHashTable *options, GHashTable *secrets
Bug#1054455: bullseye-pu: package weborf/0.17-3
Hi Salvo, On Tue, Oct 24, 2023 at 09:58:30AM +0200, Salvo Tomaselli wrote: > > This version was already used: > > https://snapshot.debian.org/package/weborf/0.17-4/ > > Sorry! > > Attaching a new debdiff file with the correct version Now there is a off-by-one in the distro version :) I believe it should be 0.17-3+deb11u1. Regards, Salvatore
Bug#1055155: bookworm-pu: package exim4/4.96-15+deb12u3 (2nd try for new bug)
Hi Andreas,
On Wed, Nov 01, 2023 at 12:03:37PM +0100, Andreas Metzler wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bookworm
> User: release.debian@packages.debian.org
> Usertags: pu
> Control: affects -1 + src:exim4
>
> Hello,
>
> I would like to push another round of cherry-picked upstream fixes to
> bookworm, including the update to 4.96.2 to fix two non-DSA minor
> security issues.
>
> The changes are included in the new upstream (4.97 rc) uploads to sid which=
> are present in sid and testing.
>
>
> * Multiple bugfixes from upstream GIT master:
> + 75_74-Cancel-early-pipe-on-an-observed-advertising-change.patch
> + 75_76-Expansions-disallow-UTF-16-surrogates-from-utf8clean.patch
> (Upstream bug 2998)
> + 75_77-GnuTLS-fix-crash-with-tls_dhparam-none.patch
> + 75_79-Fix-recipients-expansion-when-used-within-run.-.-Bug.patch
> (Upstream bug 3013)
> > ${run expansion breakage, similar to #1025420.
> + 75_82-GnuTLS-fix-autogen-cert-expiry-date.-Bug-3014.patch: Fix on-demand
> TLS cert expiry date. Closes: #1043233
> (Upstream bug 3014)
> > This is major hickup, bordering on RC.
>
> + 75_83-Re-fix-live-variable-value-free.-The-inital-fix-resu.patch
> > Another patch for ${run} expansion breakage.
> + 76-10-Fix-tr.-and-empty-strings.-Bug-3023.patch ((Upstream bug 3023)
> + 76-12-DNS-more-hardening-against-crafted-responses.patch
> * tests/basic: Add isolation-container restriction (needs a running
> exim daemon).
> * Add ${run } expansion test to tests/basic.
> * Update code to 4.96.2, fixing issues with the proxy protocol
> (CVE-2023-42117) and the `dnsdb` lookup subsystem (CVE-2023-42219). It
> also includes additional hardening for spf lookups, however CVE-2023-42218
The mentioned CVEs have a typo. I believe this should be
CVE-2023-42117 and CVE-2023-42119 (and for completeness about the
libspf2 mentioning CVE-2023-42118).
Regards,
Salvatore
Uploading linux (6.5.10-1)
Hi I would like to upload linux version 6.5.10-1 tomorrow to unstable. The new upload rebases unstable importing the new stable series versions up to 6.5.10. An ABI bump is included. CVE-2023-46813, CVE-2023-5717 and CVE-2023-46862 are fixed with the new stable import series. The RT patchset remains fo far disabled (it is enabled again for the 6.6 based upload to experimental). There are some other packaging packages apart of the stable imports pending with this upload: * Disable DEBUG_PREEMPT as it introduces slowdowns up to 20% on certain workloads. Modifed to actually not set DEBUG_PREEMPT, as it is not enabled by deault since .3-rc1: * Do not explicitly unset DEBUG_PREEMPT (not enabled by default since 6.3-rc1) Regards, Salvatore signature.asc Description: PGP signature
Bug#1054446: bookworm-pu: package wolfssl/5.5.4-2+deb12u1
On Mon, Oct 23, 2023 at 10:12:27PM +0200, Bastian Germann wrote: > Am 23.10.23 um 22:02 schrieb Salvatore Bonaccorso: > > > diff -Nru wolfssl-5.5.4/debian/changelog wolfssl-5.5.4/debian/changelog > > > --- wolfssl-5.5.4/debian/changelog2023-02-06 14:41:53.0 > > > + > > > +++ wolfssl-5.5.4/debian/changelog2023-10-23 17:46:16.0 > > > + > > > @@ -1,3 +1,10 @@ > > > +wolfssl (5.5.4-2+deb12u1) bookworm; urgency=medium > > > + > > > + * Stable update to address the following vulnerabilities: > > > +- Fix CVE-2023-3724. > > > > Should the changelog entry close as well #1041699? > > I do not mind adding the bug reference but usually, the Security Team's bugs > say that one should not close them but rather edit their fixed values. > And the bug is already closed. I am including the debdiff with the bug > reference and let you choose. I do not read that :), and you can close a bug with multiple versions in the Debian BTS. But anyway, both versions are ok, and I have anyway not a authoritative guidance on the bookworm-pu bug, as not member of the release team. Regards, Salvatore
Bug#1054446: bookworm-pu: package wolfssl/5.5.4-2+deb12u1
Hi Bastian, On Mon, Oct 23, 2023 at 09:48:45PM +0200, Bastian Germann wrote: > Package: release.debian.org > Severity: normal > Tags: bookworm > User: release.debian@packages.debian.org > Usertags: pu > X-Debbugs-CC: sirkilam...@msn.com > > Hi, > > I am including a fix for wolfssl's CVE-2023-3724. > The vulnerability is tracked by the Security Team in #1041699 and is fixed in > unstable. > Aside from the changelog, this is exactly the same debdiff as provided by > 5.5.4-2.1. > The new patch is taken from upstream as suggested by Jacob Barthelmeh. > > Thanks, > Bastian > diff -Nru wolfssl-5.5.4/debian/changelog wolfssl-5.5.4/debian/changelog > --- wolfssl-5.5.4/debian/changelog2023-02-06 14:41:53.0 + > +++ wolfssl-5.5.4/debian/changelog2023-10-23 17:46:16.0 + > @@ -1,3 +1,10 @@ > +wolfssl (5.5.4-2+deb12u1) bookworm; urgency=medium > + > + * Stable update to address the following vulnerabilities: > +- Fix CVE-2023-3724. Should the changelog entry close as well #1041699? Regards, Salvatore
Bug#1054421: bookworm-pu: package weborf/0.19
Hi, On Mon, Oct 23, 2023 at 07:07:44PM +0200, Salvo "LtWorf" Tomaselli wrote: > Package: release.debian.org > Severity: normal > Tags: bookworm > User: release.debian@packages.debian.org > Usertags: pu > X-Debbugs-Cc: web...@packages.debian.org, tipos...@tiscali.it > Control: affects -1 + src:weborf > > I have found a denial of service in all versions of weborf. > > It is tracked in #1054417 and solved in 1.0 upstream. > https://github.com/ltworf/weborf/pull/88 > > The issue is fixed in unstable but remains in stable and oldstable. > > [ Reason ] > The bug has been there undetected for years. The fix is minimal. > > [ Impact ] > The denial of service and extremely unlikely but theoretically possible > remote execution issue will remain. > > The issue exists only if the process has CGI enabled (not the default). > > [ Tests ] > > There are no automated tests covering the issue. > > [ Risks ] > > The patch is just 3 lines. > > [ Checklist ] > [*] *all* changes are documented in the d/changelog > [*] I reviewed all changes and I approve them > [*] attach debdiff against the package in (old)stable > [*] the issue is verified as fixed in unstable > > [ Changes ] > > A patch to remove a memory allocation and copy, where I forgot a +1 in the > copy. > > The resulting code just reuses the same buffer instead of copying, which was > not > needed to begin with. > > [ Other info ] > > Tracked in CVE-2023-46586 > diff -Nru weborf-0.19/debian/changelog weborf-0.19/debian/changelog > --- weborf-0.19/debian/changelog 2022-10-15 12:57:06.0 +0200 > +++ weborf-0.19/debian/changelog 2023-10-23 18:38:21.0 +0200 > @@ -1,3 +1,9 @@ > +weborf (0.19-3) bookworm; urgency=medium > + > + * Backport patch from upstream to fix denial of service (Closes: 1054417) > + > + -- Salvo 'LtWorf' Tomaselli Mon, 23 Oct 2023 > 18:38:21 +0200 The version works because 0.19-3 was never landing in the archive. Normally you would use a +debXuY suffix, in the above case +deb12u1. But I assume SRM will still ack the fix as it is (other package do as well not follow this as strict rule, e.g. src:linux but because its following the stable series). Regards, Salvatore
Uploading linux (6.5.8-1)
Hi I would like to upload linux version 6.5.8-1 later today to unstable. The new upload would constist of importing new stable series version up to 6.5.8. An ABI bump is included. Notably the RT patchset is still disabled as mentioned in the 6.5.6-1 upload announcement. CVE-2023-34324 is fixed with the new stable import series. There are some other packaging packages apart of the stable imports pending with this upload: * Bump ABI to 3 * [x86] KVM: SVM: always update the x2avic msr interception (CVE-2023-5090) * nvmet-tcp: Fix a possible UAF in queue intialization setup (CVE-2023-5178) * Bluetooth: hci_ldisc: check HCI_UART_PROTO_READY flag in HCIUARTGETPROTO (CVE-2023-31083) Regards, Salvatore signature.asc Description: PGP signature
Uploading linux (6.5.6-1)
Hi I would like to upload linux version 6.5.6-1 later today to unstable. The new upload would consist of importing new stable series version up to 6.5.6. An ABI bump is included. Notably given RT patchset is not updated anymore for 6.5.y series upstream, this update disables it temporarily. It might be re-enabled for 6.6.y. With the upload a couple of (known and CVEied) security fixes are addressed: CVE-2023-4921, CVE-2023-5197, CVE-2023-5345, CVE-2023-42754 and CVE-2023-42756. Via upstream changes, #1037142, #1052584 and #1052063 are addressed. There are some other packaging packages apart of the stable imports pending with this upload: * Bump ABI to 2 * [rt] Disable RT featureset as not supported in 6.5.y series * [x86] drivers/watchdog: Enable ADVANTECH_EC_WDT as module (Closes: #1051449) * [x86] drivers/platform/x86: Enable SYSTEM76_ACPI as module (Closes: #1050996) * [arm64] Add qrtr to kernel-image udeb, needed by Lenovo Thinkpad X13s. Regards, Salvatore signature.asc Description: PGP signature
Re: Bug#983912: grub2: consider renaming signed source packages to grub2-signed-*
Hi, On Sun, Nov 20, 2022 at 09:11:09PM +0100, Salvatore Bonaccorso wrote: > Hi, > > On Wed, Mar 03, 2021 at 10:52:39AM +0100, Ansgar wrote: > > Source: grub2 > > Version: 2.04-16 > > Severity: normal > > X-Debbugs-Cc: ftpmas...@debian.org, debian-release@lists.debian.org > > > > grub2 currently uses grub-efi-signed-* as source package names for the > > Secure Boot signed packages. While releasing the last security update > > we found a small issue with these names: > > > > dak processes source packages in lexiographic order, so it would > > process grub-efi-signed-* before grub2 when accepting all packages at > > once from the "embargoed" policy queue. But the grub-efi-signed-* > > binary packages have Built-Using: grub2; as grub2 is not accepted from > > embargoed at this point in time, the /binary/ uploads will be rejected > > in this case. (This problem exists in principle with all Built-Using > > relations.) > > > > We could avoid this particular problem if the source package names of > > the signed packages sort after grub2, i.e., if they were named > > grub2-signed-* or grub2-efi-signed-*. With linux this is already the > > case (src:linux and src:linux-signed-*). > > > > (As a minor thing, I think the changelog entry in the signed packages > > should also use the grub maintainer's name, not ftpmaster@ similar to > > what src:linux-signed-* has, but that is just cosmetics.) > > > > I've Cc'ed debian-release@ as it is already past soft freeze, but I > > think just renaming the source packages would be unlikely to break > > anything. > > As we were hit by this issue in the last DSA (DSA 5280-1) again, > should we attempt to have this changed at least for bookworm? For DSA 5519-1 I fortunately remembered this bug and did install the packages in two steps, first dak new-security-install grub2*.changes, then the grub-efi*.changes. I still think would be great if we can do the above mentioned renames, to avoid this problem (or ist maybe realistic that we could tackle the problem itself at dak level?). Regards, Salvatore
Re: Releasing linux/6.1.52-1 bookworm-security update without armel build, Image size problems
Hi Adrian,
Sorry for not replying early, busy with preparing the updates.
On Fri, Sep 29, 2023 at 03:41:15AM +0300, Adrian Bunk wrote:
> On Sat, Sep 09, 2023 at 10:15:59AM +0200, Salvatore Bonaccorso wrote:
> >...
> > Note that the last time the problem arised already earlier in
> > experimental and Ben workarounded it there with
> > https://salsa.debian.org/kernel-team/linux/-/commit/9dfe6d33a4fd220394228b30cbbfdb3b444d36ec
> > We probably can do that as well here. 60443c88f3a8 ("kallsyms: Improve
> > the performance of kallsyms_lookup_name()") was in fact backported to
> > 6.1.42. So this is next I would try and disable MPTCP and
> > FUNCTION_TRACER.
> >...
>
> Yes, that looks reasonable.
Great thanks, this landed now for the point release udpates and in
fact we have the armel builds back.
> Additionally, one generic cause of bloat is:
> debian/changelog: * Enable UNICODE. (closes: #985689)
> debian/config/config:CONFIG_UNICODE=y
>
> That's 74 kB uncompressed, and there doesn't seem to be any
> justification for not making it modular. It's not urgent since
> Bens change handles the immediate problem, but worth changing
> in unstable.
Could you fill a bug against src:linux for it, so this might be
further addressed in unstable for armel?
Regards,
Salvatore
Bug#1053240: bullseye-pu: package ghostscript/9.53.3~dfsg-7+deb11u6
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: ghostscr...@packages.debian.org, car...@debian.org
Control: affects -1 + src:ghostscript
Hi stable release managers,
[ Reason ]
Fix two CVEs which we did mark no-dsa (though one might after more
thinking be a candiate). Fix CVE-2023-38559 and CVE-2023-43115.
[ Impact ]
CVE-2023-38559 and CVE-2023-43115 would remain open so far.
[ Tests ]
Performed manual test for CVE-2023-43115.
[ Risks ]
Should be low, following the upstream commits to resolve the issues
which are very targeted.
[ 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 ]
Apply upstream fixes to address the CVEs. Adjust checks on input and
for the second issue, prevent PostScript programs switching to the IJS
device after SAFER has been activated (and prevent changes to the
IjsServer parameter after SAFER has been activated).
[ Other info ]
None.
Regards,
Salvatore
diff -Nru ghostscript-9.53.3~dfsg/debian/changelog
ghostscript-9.53.3~dfsg/debian/changelog
--- ghostscript-9.53.3~dfsg/debian/changelog2023-07-02 11:54:08.0
+0200
+++ ghostscript-9.53.3~dfsg/debian/changelog2023-09-29 14:24:57.0
+0200
@@ -1,3 +1,12 @@
+ghostscript (9.53.3~dfsg-7+deb11u6) bullseye; urgency=medium
+
+ * Non-maintainer upload.
+ * Copy pcx buffer overrun fix from devices/gdevpcx.c (CVE-2023-38559)
+(Closes: #1043033)
+ * IJS device - try and secure the IJS server startup (CVE-2023-43115)
+
+ -- Salvatore Bonaccorso Fri, 29 Sep 2023 14:24:57 +0200
+
ghostscript (9.53.3~dfsg-7+deb11u5) bullseye-security; urgency=high
* Non-maintainer upload by the Security Team.
diff -Nru ghostscript-9.53.3~dfsg/debian/patches/020230717~d81b82c.patch
ghostscript-9.53.3~dfsg/debian/patches/020230717~d81b82c.patch
--- ghostscript-9.53.3~dfsg/debian/patches/020230717~d81b82c.patch
1970-01-01 01:00:00.0 +0100
+++ ghostscript-9.53.3~dfsg/debian/patches/020230717~d81b82c.patch
2023-09-29 14:24:57.0 +0200
@@ -0,0 +1,28 @@
+From: Chris Liddell
+Date: Mon, 17 Jul 2023 14:06:37 +0100
+Subject: Bug 706897: Copy pcx buffer overrun fix from devices/gdevpcx.c
+Origin:
https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=d81b82c70bc1fb9991bb95f1201abb5dea55f57f
+Bug-Debian: https://bugs.debian.org/1043033
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2023-38559
+
+Bounds check the buffer, before dereferencing the pointer.
+---
+ base/gdevdevn.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/base/gdevdevn.c b/base/gdevdevn.c
+index 7b14d9c712b4..6351fb77ac75 100644
+--- a/base/gdevdevn.c
b/base/gdevdevn.c
+@@ -1983,7 +1983,7 @@ devn_pcx_write_rle(const byte * from, const byte * end,
int step, gp_file * file
+ byte data = *from;
+
+ from += step;
+-if (data != *from || from == end) {
++if (from >= end || data != *from) {
+ if (data >= 0xc0)
+ gp_fputc(0xc1, file);
+ } else {
+--
+2.40.1
+
diff -Nru ghostscript-9.53.3~dfsg/debian/patches/020230824~8b0f200.patch
ghostscript-9.53.3~dfsg/debian/patches/020230824~8b0f200.patch
--- ghostscript-9.53.3~dfsg/debian/patches/020230824~8b0f200.patch
1970-01-01 01:00:00.0 +0100
+++ ghostscript-9.53.3~dfsg/debian/patches/020230824~8b0f200.patch
2023-09-29 14:24:57.0 +0200
@@ -0,0 +1,53 @@
+From: Ken Sharp
+Date: Thu, 24 Aug 2023 15:24:35 +0100
+Subject: IJS device - try and secure the IJS server startup
+Origin:
https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=8b0f20002536867bd73ff4552408a72597190cbe
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2023-43115
+
+Bug #707051 ""ijs" device can execute arbitrary commands"
+
+The problem is that the 'IJS' device needs to start the IJS server, and
+that is indeed an arbitrary command line. There is (apparently) no way
+to validate it. Indeed, this is covered quite clearly in the comments
+at the start of the source:
+
+ * WARNING: The ijs server can be selected on the gs command line
+ * which is a security risk, since any program can be run.
+
+Previously this used the awful LockSafetyParams hackery, which we
+abandoned some time ago because it simply couldn't be made secure (it
+was implemented in PostScript and was therefore vulnerable to PostScript
+programs).
+
+This commit prevents PostScript programs switching to the IJS device
+after SAFER has been activated, and prevents changes to the IjsServer
+parameter after SAFER has been activated.
+
+SAFER is activated, unless explicitly disabled, before any user
+PostScript is executed which means that the device and the server
+invocation can only be configured
Bug#1053239: bookworm-pu: package ghostscript/10.0.0~dfsg-11+deb12u2
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: ghostscr...@packages.debian.org, car...@debian.org
Control: affects -1 + src:ghostscript
Hi stable release managers,
[ Reason ]
Fix two CVEs which we did mark no-dsa (though one might after more
thinking be a candiate). Fix CVE-2023-38559 and CVE-2023-43115.
[ Impact ]
CVE-2023-38559 and CVE-2023-43115 would remain open so far.
[ Tests ]
Performed manual test for CVE-2023-43115.
[ Risks ]
Should be low, following the upstream commits to resolve the issues
which are very targeted.
[ 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 ]
Apply upstream fixes to address the CVEs. Adjust checks on input and
for the second issue, prevent PostScript programs switching to the IJS
device after SAFER has been activated (and prevent changes to the
IjsServer parameter after SAFER has been activated).
[ Other info ]
None.
Regards,
Salvatore
diff -Nru ghostscript-10.0.0~dfsg/debian/changelog
ghostscript-10.0.0~dfsg/debian/changelog
--- ghostscript-10.0.0~dfsg/debian/changelog2023-07-02 10:50:27.0
+0200
+++ ghostscript-10.0.0~dfsg/debian/changelog2023-09-29 14:33:30.0
+0200
@@ -1,3 +1,12 @@
+ghostscript (10.0.0~dfsg-11+deb12u2) bookworm; urgency=medium
+
+ * Non-maintainer upload.
+ * Copy pcx buffer overrun fix from devices/gdevpcx.c (CVE-2023-38559)
+(Closes: #1043033)
+ * IJS device - try and secure the IJS server startup (CVE-2023-43115)
+
+ -- Salvatore Bonaccorso Fri, 29 Sep 2023 14:33:30 +0200
+
ghostscript (10.0.0~dfsg-11+deb12u1) bookworm-security; urgency=high
* Non-maintainer upload by the Security Team.
diff -Nru
ghostscript-10.0.0~dfsg/debian/patches/0005-Bug-706897-Copy-pcx-buffer-overrun-fix-from-devices-.patch
ghostscript-10.0.0~dfsg/debian/patches/0005-Bug-706897-Copy-pcx-buffer-overrun-fix-from-devices-.patch
---
ghostscript-10.0.0~dfsg/debian/patches/0005-Bug-706897-Copy-pcx-buffer-overrun-fix-from-devices-.patch
1970-01-01 01:00:00.0 +0100
+++
ghostscript-10.0.0~dfsg/debian/patches/0005-Bug-706897-Copy-pcx-buffer-overrun-fix-from-devices-.patch
2023-09-29 14:17:17.0 +0200
@@ -0,0 +1,28 @@
+From: Chris Liddell
+Date: Mon, 17 Jul 2023 14:06:37 +0100
+Subject: Bug 706897: Copy pcx buffer overrun fix from devices/gdevpcx.c
+Origin:
https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=d81b82c70bc1fb9991bb95f1201abb5dea55f57f
+Bug-Debian: https://bugs.debian.org/1043033
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2023-38559
+
+Bounds check the buffer, before dereferencing the pointer.
+---
+ base/gdevdevn.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/base/gdevdevn.c b/base/gdevdevn.c
+index 7b14d9c712b4..6351fb77ac75 100644
+--- a/base/gdevdevn.c
b/base/gdevdevn.c
+@@ -1983,7 +1983,7 @@ devn_pcx_write_rle(const byte * from, const byte * end,
int step, gp_file * file
+ byte data = *from;
+
+ from += step;
+-if (data != *from || from == end) {
++if (from >= end || data != *from) {
+ if (data >= 0xc0)
+ gp_fputc(0xc1, file);
+ } else {
+--
+2.40.1
+
diff -Nru
ghostscript-10.0.0~dfsg/debian/patches/0006-IJS-device-try-and-secure-the-IJS-server-startup.patch
ghostscript-10.0.0~dfsg/debian/patches/0006-IJS-device-try-and-secure-the-IJS-server-startup.patch
---
ghostscript-10.0.0~dfsg/debian/patches/0006-IJS-device-try-and-secure-the-IJS-server-startup.patch
1970-01-01 01:00:00.0 +0100
+++
ghostscript-10.0.0~dfsg/debian/patches/0006-IJS-device-try-and-secure-the-IJS-server-startup.patch
2023-09-29 14:22:09.0 +0200
@@ -0,0 +1,58 @@
+From: Ken Sharp
+Date: Thu, 24 Aug 2023 15:24:35 +0100
+Subject: IJS device - try and secure the IJS server startup
+Origin:
https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=8b0f20002536867bd73ff4552408a72597190cbe
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2023-43115
+
+Bug #707051 ""ijs" device can execute arbitrary commands"
+
+The problem is that the 'IJS' device needs to start the IJS server, and
+that is indeed an arbitrary command line. There is (apparently) no way
+to validate it. Indeed, this is covered quite clearly in the comments
+at the start of the source:
+
+ * WARNING: The ijs server can be selected on the gs command line
+ * which is a security risk, since any program can be run.
+
+Previously this used the awful LockSafetyParams hackery, which we
+abandoned some time ago because it simply couldn't be made secure (it
+was implemented in PostScript and was therefore vulnerable to PostScript
+programs).
+
+This commit prevents PostScript programs swi
Bug#1053219: bookworm-pu: package lemonldap-ng/2.16.1+ds-deb12u2
Hi Yadd, On Fri, Sep 29, 2023 at 05:37:25PM +0400, Yadd wrote: > Package: release.debian.org > Severity: normal > Tags: bookworm > User: release.debian@packages.debian.org > Usertags: pu > X-Debbugs-Cc: lemonldap...@packages.debian.org, y...@debian.org > Control: affects -1 + src:lemonldap-ng > > [ Reason ] > Two new vulnerabilities have been dicovered and fixed in lemonldap-ng: > - an open redirection only when configuration is edited by hand and >doesn't follow OIDC specifications > - a server-side-request-forgery (CVE-2023-44469) in OIDC protocol: >A little-know feature of OIDC allows the OpenID Provider to fetch the >Authorization request parameters itself by indicating a request_uri >parameter. This feature is now restricted to a white list using this >patch > > [ Impact ] > One low and one medium security issue. > > [ Tests ] > Patches includes test updates > > [ Risks ] > Outside of test changes, patches are not so big and the test coverage > provided by upstream is good, so risk is moderate. > > [ 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 ] > - open redirection patch: just rejects requests with `redirect_uri` if > relying party configuration has no declared redirect URIs. > - SSRF patch: > * add new configuration parameter to list authorized "request_uris" > * change the algorithm that manage request_uri parameter > > Cheers, > Xavier > diff --git a/debian/NEWS b/debian/NEWS > index b8955920b..5295a3cbb 100644 > --- a/debian/NEWS > +++ b/debian/NEWS > @@ -1,3 +1,13 @@ > +lemonldap-ng (2.16.1+ds-deb12u2) bullseye; urgency=medium bookworm? (but that said I guess that can be considered minor if time is tight to get the upload in, but as well disclaimer, not part of the release team) Regards, Salvatore
Bug#1051466: bookworm-pu: package ovn/23.03.1-1~deb12u1
Hi (not a SRM here, but below some comments) On Fri, Sep 08, 2023 at 01:32:05PM +0200, Frode Nordahl wrote: > Package: release.debian.org > Severity: normal > Tags: bookworm > User: release.debian@packages.debian.org > Usertags: pu > X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org > > Dear Release Team, > > We would like to upload the latest stable point release of ovn 23.03 > to bookworm-p-u. Stable release branches are maintained upstream with > the intention of providing bug fixes only and no compatibility > breakages, and with automated non-trivial CI jobs that also cover > Debian and Ubuntu. > > Debdiff attached. Packaging updated with gbp/salsa config for new > bookworm stable branch and in-flight patches to fix an issue with > unnecessary logging breaking one of the tests introduced in the point > release. Your debdiff did not make it to the list I think because of the size. Two obervations: Can you please close #1043598 in the debian/changelog as well as the update addresses CVE-2023-3153. You would need first to make sure the fixes land in unstable unless you plan to diverge and go to a new upstream version for another branch. But make sure CVE-2023-3153 / #1043598 fix is included in usntable as well. Hope this helps, Regards, Salvatore
Bug#1052021: bookworm-pu: package nftables/1.0.6-2+deb12u2
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: nftab...@packages.debian.org, Timo Sigurdsson
, Arturo Borrero Gonzalez ,
car...@debian.org
Control: affects -1 + src:nftables
Dear stable release managers,
[ Reason ]
Timo Sigurdsson reported, after I released DSA 5492-1 for linux, that
in his case nftables rules won't be loaded anymore:
https://bugs.debian.org/1051592
This was tracked down with a Linux change, 0ebc1064e487 ("netfilter:
nf_tables: disallow rule addition to bound chain via
NFTA_RULE_CHAIN_ID"), which is to address CVE-2023-4147, but uncovered
an issue with nftables releases before v1.0.7 upstream. nftables is
generating incorrect bytecode, which is hit with this new kernel check
that rejects adding rules to bound chains.
Following https://lore.kernel.org/stable/ZP+bUpxJiFcmTWhy@calendula/
and further discussion on the Linux kernel mailinglists it looks this
has to be addressed in netfilter itself (arguably the change should
not break userspace, but see Florian Westphal in the thread).
[ Impact ]
Users which have such rules, running unpatched nftables but updated
the linux kernel due to address security fixes (and later to be
included in the point release as well) are left without loaded
nftables rules.
[ Tests ]
Explicit tests with the rules provided by Timo to verify they
correctly get loaded with updated nftables userland and the updated
kernel.
[ Risks ]
Pablo Neira Ayuso provided the series of commits required to address
the issue. They apply cleanly for the bookworm version.
[ 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 above.
[ Other info ]
Unfortunately this will be needed as well for bullseye, but the
version of nftables there is substantial older, I have not yet
verified how the patches apply, but will need to be asked anyway in a
separate bullseye-pu update request.
Regards,
Salvatore
diff -Nru nftables-1.0.6/debian/changelog nftables-1.0.6/debian/changelog
--- nftables-1.0.6/debian/changelog 2023-06-20 16:55:52.0 +0200
+++ nftables-1.0.6/debian/changelog 2023-09-16 07:47:15.0 +0200
@@ -1,3 +1,13 @@
+nftables (1.0.6-2+deb12u2) bookworm; urgency=medium
+
+ * [136245a] Fix incorrect bytecode generation hit with new kernel check that
+rejects adding rules to bound chains (Closes: #1051592)
+- rule: add helper function to expand chain rules intoi commands
+- rule: expand standalone chain that contains rules
+- src: expand table command before evaluation
+
+ -- Salvatore Bonaccorso Sat, 16 Sep 2023 07:47:15 +0200
+
nftables (1.0.6-2+deb12u1) bookworm; urgency=medium
* [7edf72e] d/patches: add 0001-debian-bug-1038724.patch (Closes: #1038724)
diff -Nru
nftables-1.0.6/debian/patches/rule-add-helper-function-to-expand-chain-rules-into-.patch
nftables-1.0.6/debian/patches/rule-add-helper-function-to-expand-chain-rules-into-.patch
---
nftables-1.0.6/debian/patches/rule-add-helper-function-to-expand-chain-rules-into-.patch
1970-01-01 01:00:00.0 +0100
+++
nftables-1.0.6/debian/patches/rule-add-helper-function-to-expand-chain-rules-into-.patch
2023-09-16 07:47:15.0 +0200
@@ -0,0 +1,82 @@
+From 4e5b0a64227dde250f94bec45b3fb127d78b7fd2 Mon Sep 17 00:00:00 2001
+From: Pablo Neira Ayuso
+Date: Mon, 6 Feb 2023 15:28:40 +0100
+Subject: [PATCH 1/3,nft] rule: add helper function to expand chain rules intoi
+ commands
+
+[ upstream commit 784597a4ed63b9decb10d74fdb49a1b021e22728 ]
+
+This patch adds a helper function to expand chain rules into commands.
+This comes in preparation for the follow up patch.
+
+Signed-off-by: Pablo Neira Ayuso
+---
+ src/rule.c | 39 ++-
+ 1 file changed, 22 insertions(+), 17 deletions(-)
+
+diff --git a/src/rule.c b/src/rule.c
+index 1402210acd8d..43c6520517ce 100644
+--- a/src/rule.c
b/src/rule.c
+@@ -1310,13 +1310,31 @@ void cmd_add_loc(struct cmd *cmd, uint16_t offset,
const struct location *loc)
+ cmd->num_attrs++;
+ }
+
++static void nft_cmd_expand_chain(struct chain *chain, struct list_head
*new_cmds)
++{
++ struct rule *rule;
++ struct handle h;
++ struct cmd *new;
++
++ list_for_each_entry(rule, &chain->rules, list) {
++ memset(&h, 0, sizeof(h));
++ handle_merge(&h, &rule->handle);
++ if (chain->flags & CHAIN_F_BINDING) {
++ rule->handle.chain_id = chain->handle.chain_id;
++ rule->handle.chain.location = chain->location;
++ }
++ new = cmd_alloc(CMD_ADD, CMD_OBJ_RULE, &h,
++ &rule->location, rule_get(rule));
++ list_
Bug#1051937: bullseye-pu: package cairosvg/oldstable-new
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: cairo...@packages.debian.org, Joe Burmeister
, car...@debian.org
Control: affects -1 + src:cairosvg
Dear SRM,
[ Reason ]
Triggered by a offlist-report from Joe Burmeister, cairosvg suffers
from a regression from the original fix upstream for CVE-2023-27586,
where embedded images using data URIs no longer work without the
unsafe flag. To fix the issue it would only be necessary to dissalow
loading of external files, but data URIs would be expected to still
work.
See:
- https://bugs.debian.org/1050643
- https://github.com/Kozea/CairoSVG/issues/383
[ Impact ]
Without using the unsafe flag, it is not possible to embed images
using data URIs.
[ Tests ]
Joe tested the updated package with a (non public) testcase.
[ Risks ]
Syncs up with upstream fixes after the original fix for
CVE-2023-27586.
[ 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 ]
Allow to handle data-URLs in safe mode as well, using a introduced
safe_fetch which fetches the content of a passed url if it's a data
URL and return an empty SVG otherwise.
[ Other info ]
None
Regards,
Salvatore
diff -Nru cairosvg-2.5.0/debian/changelog cairosvg-2.5.0/debian/changelog
--- cairosvg-2.5.0/debian/changelog 2023-03-23 20:51:51.0 +0100
+++ cairosvg-2.5.0/debian/changelog 2023-09-06 21:24:37.0 +0200
@@ -1,3 +1,10 @@
+cairosvg (2.5.0-1.1+deb11u2) bullseye; urgency=medium
+
+ * Non-maintainer upload.
+ * Handle data-URLs in safe mode (Closes: #1050643)
+
+ -- Salvatore Bonaccorso Wed, 06 Sep 2023 21:24:37 +0200
+
cairosvg (2.5.0-1.1+deb11u1) bullseye-security; urgency=high
* Non-maintainer upload by the Security Team.
diff -Nru cairosvg-2.5.0/debian/patches/Handle-data-URLs-in-safe-mode.patch
cairosvg-2.5.0/debian/patches/Handle-data-URLs-in-safe-mode.patch
--- cairosvg-2.5.0/debian/patches/Handle-data-URLs-in-safe-mode.patch
1970-01-01 01:00:00.0 +0100
+++ cairosvg-2.5.0/debian/patches/Handle-data-URLs-in-safe-mode.patch
2023-09-06 21:24:37.0 +0200
@@ -0,0 +1,61 @@
+From: Guillaume Ayoub
+Date: Tue, 18 Apr 2023 14:51:13 +0200
+Subject: Handle data-URLs in safe mode.
+Origin:
https://github.com/Kozea/CairoSVG/commit/2cbe3066e604af67c31d6651aa3acafe4ae0749d
+Bug: https://github.com/Kozea/CairoSVG/issues/383
+Bug-Debian: https://bugs.debian.org/1050643
+
+Fix #383.
+---
+ cairosvg/parser.py | 5 ++---
+ cairosvg/url.py| 11 +++
+ 2 files changed, 13 insertions(+), 3 deletions(-)
+
+diff --git a/cairosvg/parser.py b/cairosvg/parser.py
+index 61275f0a1073..06a65db5c0e2 100644
+--- a/cairosvg/parser.py
b/cairosvg/parser.py
+@@ -14,7 +14,7 @@ from defusedxml import ElementTree
+ from . import css
+ from .features import match_features
+ from .helpers import flatten, pop_rotation, rotations
+-from .url import fetch, parse_url, read_url
++from .url import fetch, parse_url, read_url, safe_fetch
+
+ # 'display' is actually inherited but handled differently because some markers
+ # are part of a none-displaying group (see test painting-marker-07-f.svg)
+@@ -393,8 +393,7 @@ class Tree(Node):
+
+ # Don’t allow fetching external files unless explicitly asked for
+ if 'url_fetcher' not in kwargs and not unsafe:
+-self.url_fetcher = (
+-lambda *args, **kwargs: b'')
++self.url_fetcher = safe_fetch
+
+ self.xml_tree = tree
+ root = cssselect2.ElementWrapper.from_xml_root(tree)
+diff --git a/cairosvg/url.py b/cairosvg/url.py
+index b4a78eaf6645..7b184e6e74d9 100644
+--- a/cairosvg/url.py
b/cairosvg/url.py
+@@ -84,6 +84,17 @@ def fetch(url, resource_type):
+ return urlopen(Request(url, headers=HTTP_HEADERS)).read()
+
+
++def safe_fetch(url, resource_type):
++"""Fetch the content of ``url`` only if it’s a data-URL.
++
++Otherwise, return an empty SVG.
++
++"""
++if url and url.startswith('data:'):
++return fetch(url, resource_type)
++return b''
++
++
+ def parse_url(url, base=None):
+ """Parse an URL.
+
+--
+2.40.1
+
diff -Nru cairosvg-2.5.0/debian/patches/series
cairosvg-2.5.0/debian/patches/series
--- cairosvg-2.5.0/debian/patches/series2023-03-23 20:51:07.0
+0100
+++ cairosvg-2.5.0/debian/patches/series2023-09-06 21:23:58.0
+0200
@@ -1,3 +1,4 @@
0001-Remove-pytest-options-for-plugins-not-packaged-for-D.patch
0002-Don-t-use-overlapping-groups-for-regular-expressions.patch
Don-t-allow-fetching-external-files-unless-explicitl.patch
+Handle-data-URLs-in-safe-mode.patch
