My activity as part of the Debian LTS team, on behalf of Freexian.
Debian LTS exists thanks to the generous donations of its sponsors. If your company relies on it, please consider funding the project. Thanks.
Uploaded python3.9/3.9.2-1+deb11u7 in Debian LTS, and issued DLA-4583-1,
fixing:
Additionally, I uploaded python3.11/3.11.2-6+deb12u8 in Debian oldstable,
cf. #1136382.
Uploaded 3.4.3-2+deb11u4 in Debian LTS, and issued DLA-4563-1, fixing:
Additionally, I uploaded the following:
Version 252.39-1~deb12u2 was uploaded to Debian oldstable, cf.
https://tracker.debian.org/news/1748276/accepted-systemd-25239-1deb12u2-source-into-oldstable-proposed-updates/
Uploaded 1.6.20~ds1-1+deb12u3 for Debian bookworm (oldstable). I proposed
this new version back in February, cf. #1127704.
Uploaded 247.3-7+deb11u8 and issued DLA-4533-1:
Uploaded 3.9.2-1+deb11u6 and issued DLA-4532-1:
Uploaded 3.11.2-6+deb12u7 for Debian bookworm (oldstable), in
order to catch up with Debian bullseye (LTS), cf. #1126814.
With Bastien Roucaries, we keep making progress on backporting latest versions of ca-certificates and ca-certificates-java in Debian LTS and older.
At this point, and after much research and testing, it seems obvious that GCJ-6 (in Debian ELTS buster) was never meant to work with ca-certificates-java. It's also becoming clear that GCJ-6 should be treated as unsupported, due to numerous issues. For example, its crypto support is severely outdated and hardly usable these days.
Focusing on the only Java runtime left to support (openjdk), we found more issues and we're still working on that.
I worked on the proposed upload for Python 3.11 in bookworm (#1126814), and proposed a new version, after feedback from Moritz and Sylvain. This upload addresses a batch of CVEs that were already fixed in LTS, but are not yet in oldstable.
I also worked on the latest batch of Python CVEs, the work is mostly done for Python 3.9, however the patches are not yet merged upstream, and not in Debian either. So for now this work is just sitting in Git, it will be released in LTS when the time is ripe.
I worked on CVE-2026-26007, the first step being to apply the fix provided by upstream to the package in Debian stable (trixie). However backporting the fix to older versions is more challenging: the code impacted has been rewritten from Python to Rust, and upsteam only fixes the more recent Rust version. So backporting will involve rewritting the patch in Python, which is do-able but requires the right person with the right skills.
Consequently, this CVE was marked as "postponed" for Debian LTS and older, as it doesn't seem any urgent anyway.
Uploaded 1.4.13~ds1-1~deb11u6 and issued DLA-4467-1:
I also reached out to the Debian Release team in order to upload those fixes in Debian oldstable (bookworm), I'm still waiting for feedback.
A number of low severity issues where found in glib. Andreas Henriksson took care of those for Debian stable, oldstable and LTS (bullseye). As part of my onboarding, I reached out to Andreas and asked if I could handle the ELTS uploads (buster, stretch), to which he agreed.
Backporting the patches was trivial, thus I published ELA-1652-1-glib2.0 and
uploaded 2.50.3-2+deb9u9 in Debian stretch and 2.58.3-2+deb10u10 in Debian
buster.
I tried to move forward the discussion regarding the runc package.
There is an ongoing discussion about how to address the latest batch of CVEs that were reported for runc, at #1120140. Backporting the patches doesn't seem to be a realistic option. More generally, the discussion is about how to provide support for this package in Debian stable and older releases.
The maintainer of the runc package did a first assessment and proposed different options for Debian. I tried one of the approaches: to build new versions of runc against older Debian releases. My conclusion is that if we go this way, we shouldn't try to use the Build-Depends from the Debian archive, but we should use the vendor tree from src:runc instead. That could go in a different source package, and this is the approach followed by Ubuntu.
Backporting ca-certificates to older Debian releases (ELTS) proved challenging, and also includes updates in other related packages: ca-certificates-java and gcc-6 (for stretch).
I worked with Bastien Roucaries on this topic, tested a bunch of scenarios, and uncovered new issues in the process. We're still working on that.