Bug#1109142: unblock: libsoup3/3.6.5-2

[Simon McVittie]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: libsoup3 at packages.debian.org, team at security.debian.org, spwhitton at spwhitton.name, andreas at fatal.se
Control: affects -1 + src:libsoup3
User: release.debian.org at packages.debian.org
Usertags: unblock

Please unblock package libsoup3

[ Reason ]

Fix a bunch of no-dsa CVEs that have not yet been fixed in any upstream 
release, in preparation for maybe backporting their fixes to bookworm 
later.

[ Impact ]

The most serious impact is that if not fixed, there are several denial 
of service issues which can crash applications that use libsoup3 as a 
http client (notably epiphany-browser, aka GNOME Web).
(CVE-2025-4476, CVE-2025-32914?, CVE-2025-4948?, CVE-2025-4969?, 
CVE-2025-4945?, and some memory leaks with no CVE associated.)

A secondary impact is that there are several more denial of service 
issues which can crash applications that use libsoup3 as a http 
*server* (CVE-2025-32908, plus all of the above except for 
CVE-2025-4476). A mitigation for these issues is that upstream does not 
recommend exposing SoupServer to untrusted networks (see #1109118) and 
if application developers and users have followed this advice, these 
issues would not be practically exploitable.

A sufficiently creative attacker might possibly be able to use 
out-of-bounds accesses to get a worse impact, but I am not aware of 
ways to make this happen.

I also included some changes to improve logging and reduce parallelism 
in the (flaky) test suite, in the hope that it will help to make the 
test suite more stable.

[ Tests ]

Manual tests:

- ran epiphany-browser (GNOME Web) and used it to browse debian.org;
- deleted ~/.cache/gnome-calculator and ran gnome-calculator, causing it
  to download currency conversion rate data (successfully)

Automated tests: build-time tests (sbuild+unshare in a qemu VM on my 
laptop) and autopkgtest (in a qemu VM on my laptop) were successful. I 
expect that they will need some retries on official Debian 
infrastructure because of pre-existing instability in the test suite.

Some of the CVE fixes include new automated test coverage, which passed. 
I have not attempted to test the CVE fixes manually.

[ Risks ]

libsoup3 is a key package in our default desktop environment,

I am not an expert on libsoup (and you will notice that my name 
intentionally does not appear in Uploaders), only a GNOME team member 
trying my best to keep our distro working. As a result I do not have a 
deep understanding of the finer points of http or the quirks of this 
particular codebase: I have done my best, but I might have made 
mistakes.

The patches to the production code in this update were all 
straightforward cherry-picks from upstream git master, with no conflict 
resolution required. I only took CVE fixes and obviously-valid memleak 
fixes, excluding upstream merge requests that have not yet been accepted 
(even if they are aiming to fix other similar CVEs).

Some of the upstream changes had known regressions, so I have tried to 
identify and include the relevant regression fixes as the very next 
thing in the patch series alongside the change that they are fixing. It 
is possible that there are unfixed regressions, or regression fixes that 
I didn't spot. If there are, applying regression fixes or reverting 
patches should be straightforward.

The non-upstream changes in this update only touch the test suite and 
documentation, and are straightforward/obvious changes. I can revert 
them if required.

Unfortunately the libsoup test suite is known to be flaky in several 
ways, so it might require some retries to herd it through the official 
Debian infrastructure. We still run it, because it's better than nothing 
and in particular is our only opportunity to detect RC regressions on 
platforms that have few users (especially big-endian or 32-bit), but we 
cannot expect it to go completely smoothly.

One root cause for test suite instability is that the scaffolding for 
testing against an Apache server sometimes fails startup for unknown 
reasons (see #1035983). As far as I can see, disabling the affected 
tests or ignoring their failures would result in a significant loss of 
test coverage, so we have been reluctant to do that. I've opened 
#1109107 and #1109108 for some more known failure modes that are 
orthogonal to that one and would benefit from being investigated 
separately. All of these are intermittent and individually rare, making 
them frustrating to debug, but there are enough test-cases that the 
cumulative effect of several rare failure modes adds up to a common 
failure for the test suite as a whole.

I am sorry that I do not have a solution for these issues, but this 
update shouldn't make them any worse, so it seems like a net positive 
for Debian 13 (and I know that isn't ideal but it's the best I have been 
able to do).

[ Checklist ]

  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]

In the debdiff, I excluded the content of d/patches/*.patch to avoid 
redundancy. All changes made by the patches are included in the debdiff 
as changes to the upstream source (the debdiff is between 
"patches-applied" trees).

Please see 
https://salsa.debian.org/gnome-team/libsoup3/-/tree/debian/3.6.5-2/debian/patches?ref_type=tags 
if you would prefer to examine the patches individually, with their 
upstream provenance and other DEP-3 metadata.

I've cc'd Debian LTS members who recently worked on libsoup2.4 (an older 
version of this same upstream codebase) in the hope that they might be 
able to take a look at this. My recommendation would be that we should 
get these changes into trixie first, and then into bookworm-pu, before 
backporting them into LTS suites.

unblock libsoup3/3.6.5-2