Re: Cacti testing needed

[Sylvain Beucler]

Hi Bastien,

On 26/01/2025 18:27, Bastien Roucariès wrote:

I think I have fixed cacti but someone could test cacti/bookworm and and 
cacti/bullseye ?

https://salsa.debian.org/debian/cacti


I don't have a production Cacti instance, but I can make targetted 
testing as for my last DLA in 2024.


The last commits for https://salsa.debian.org/debian/cacti for bullseye 
and bookworm are 1-month-old (before Christmas), is everything up-to-date?


Cheers!
Sylvain

Debian LTS & ELTS -- January 2025

[Sean Whitton]

Hello,

December was my nineteenth month working on LTS and ELTS.  Thank you to
Freexian and Freexian's sponsors for making these projects possible:


LTS

- jinja2

  - Fixed CVE-2024-56201 and CVE-2024-56326 in Debian testing and Debian
unstable by uploading a new upstream release.  Doing this required
some other packaging updates due to other changes upstream.

I switched to other packages for LTS while waiting for ci.debian.net
testing results, and so I have not fixed stable or oldstable.  This
update to sid had to happen first, though, so I've unblocked the LTS
work, whether or not it's me who will eventually do it.

There isn't much crossover between updating to the new upstream
version and backporting the fixes, so this wasn't inefficient.

- git

  - Released DLA-4031-1 addressing CVE-2024-50349 and CVE-2024-52006.

- vim

  - Submitted a proposed update for Debian bookworm addressing
CVE-2023-2610, CVE-2023-4738, CVE-2023-4752, CVE-2023-4781,
CVE-2023-5344, CVE-2024-22667, CVE-2024-43802 and CVE-2024-47814.

  - Started preparing an update to address (deep breath)
CVE-2021-3872, CVE-2021-4019, CVE-2021-4173, CVE-2021-4187,
CVE-2022-0261, CVE-2022-0351, CVE-2022-0359, CVE-2022-0361,
CVE-2022-0392, CVE-2022-0417, CVE-2022-0572, CVE-2022-1616,
CVE-2022-1785, CVE-2022-1897, CVE-2022-1942, CVE-2022-2000,
CVE-2022-2129, CVE-2022-2304, CVE-2022-3099, CVE-2022-3134,
CVE-2022-3324, CVE-2022-4141, CVE-2023-0054, CVE-2023-1175,
CVE-2023-2610, CVE-2023-4738, CVE-2023-4752, CVE-2023-4781,
CVE-2023-5344, CVE-2024-22667, CVE-2024-43802 and CVE-2024-47814.

These are all problems due to the unsafe nature of the C programming
language.  I've backported upstream's fixes for the first 29 CVEs,
and am now working on getting the tests to pass.  Then I'll backport
fixes for the remaining four CVEs.

  - Determined that CVE-2023-2426 does not affect bullseye.

To be confident in this conclusion I had to both run the
proof-of-concept exploit provided by the pseudoanonymous individual
who discovered the vulnerability, and study the code.

- Correspondence.

ELTS

- git

  - Released ELA-1307-1 addressing CVE-2024-50349 and CVE-2024-52006.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Debian LTS and ELTS report: January 2025

[Arturo Borrero Gonzalez]

Hello,

This is my January 2025 monthly report for the Freexian LTS/ELTS [1] initiative.
Many thanks to Freexian and sponsors [2] for providing this opportunity!

LTS:


I worked on 1 LTS package this month: frr

Some highlights:
* worked with upstream developers to backport and test a fix for CVE-2024-3
* released DSA-4029-1 [3] for frr

Please note, that Debian Bookworm stable is also vulnerable to CVE-2024-3. A 
patch was generated (and tested) to fix it, and a debdiff was submitted to the 
security team, but they rejected it because they had other plans.


ELTS:


I worked on 2 ELTS packages this month: activemq and frr.

Some highlights:
* released ELA-1330-1 [4] for frr
* CVE-2023-46604/activemq -- patch backported, and round of reviews completed
* CVE-2018-11775/activemq -- patch backported, and round of reviews completed

I don’t plan to keep working on activemq in the next months. Other people should 
take care of the upload and create the ELA.


regards.

[1] https://www.freexian.com/lts/
[2] https://www.freexian.com/lts/debian/#sponsors
[3] https://lists.debian.org/debian-lts-announce/2025/01/msg00023.html
[4] https://www.freexian.com/lts/extended/updates/ela-1300-1-frr/

Re: Bug#1073508: Bug#1074338: Bug#1073508: Bug#1074338: src:libxml2: fails to migrate to testing for too long: unresolved RC issue

[Santiago Ruano Rincón]

Hi Aron,

Thanks a lot for your work on libxml2!

El 21/08/24 a las 19:32, Aron Xu escribió:
> On Mon, Aug 19, 2024 at 3:54 PM Emilio Pozuelo Monfort  
> wrote:
> >
> > On 17/08/2024 11:13, Paul Gevers wrote:
> > > Hi,
> > >
> > > [Disclaimer: I'm not the most experienced person on transitions in the 
> > > team, so
> > > I'd like for Graham, Emilio and/or Sebastian to check if they agree with 
> > > me.]
> > >
> > > Thanks for working on this.
> > >
> > > On 17-08-2024 05:58, Aron Xu wrote:
> > >> After some research, I prefer making a t64-like transition for libxml2
> > >> for the following reasons:
> > >
> > > I'm a bit curious in how far you think this looks like a t64-like 
> > > transition as
> > > apposed to a regular c-library transition. Is it because the libraries 
> > > will not
> > > be co-installable, you don't bump SONAME and just rename the binary 
> > > package
> > > name? Even with all the work that went into the t64 transition, we're 
> > > starting
> > > to see hidden bugs [0] (although I think this can happen with any 
> > > transition).
> > >
> > >>   - Upstream is not prepared to bump the SONAME to something like
> > >> libxml3. Given the long history of this function library, determining
> > >> which APIs should be public and which should be private is
> > >> challenging.
> > >
> > > That's why earlier I proposed a Debian specific SONAME, "in between" 2 
> > > and 3.
> > > Upstream (I think) even suggested that [1].
> > >
> > >>   - The potential for breaking locally built software is minimal.
> > >> Although abi-compliance-checker raises many issues, most of them are
> > >> not used in the real world.
> > >
> > > Isn't the fact that we *caught* an issue in Debian the proof that it's 
> > > not just
> > > academic?
> > >
> > >>   - This approach is significantly easier and safer.
> > >
> > > I'm hesitant because we have well established procedures to handle ABI 
> > > breakage
> > > with SONAME bumps and how to handle them in Debian. Can you elaborate on 
> > > the
> > > easier and safer parts? Because I mostly see risks to deviate from 
> > > established
> > > paths as the corner cases on them are less known.
> >
> > I feel like the proposed change by Aron is the best course of action. The
> > benefits are that we get everything rebuilt against the new package, 
> > effectively
> > avoiding any issues with the ABI breaks inside Debian. And by maintaining 
> > the
> > same SONAME as upstream, if a user installs a binary provided by a 
> > 3rd-party,
> > then it will just work (assuming it was built for the newer releases or is 
> > not
> > affected by the ABI breaks). The drawbacks are that the old and new packages
> > won't be co-installable due to the file conflicts, and so the transition 
> > will
> > have to happen in lockstep. It will also make it harder for apt to do the
> > dist-upgrades from bookworm to trixie, which adds up to the t64 and 
> > possibly the
> > usr-merge changes.
> >
> > Obviously there's an even better solution, which is for upstream to revert 
> > the
> > ABI break (if possible) or bump the SOVERSION, but unfortunately that seems 
> > to
> > be out of the picture.
> >
> 
> I've uploaded the debdiff to experimental, and the package should hit NEW 
> soon.
> 
> Thanks,
> Aron

May I ask you what are you plans for libxml2 > 2.9.x?

The transition freeze is approaching (2025-03-15), and I would guess
that packaging 2.13.x is too disruptive for trixie right now. Please,
correct me if I am wrong! I would just like to document what are the
expectations regarding the libxml2 version to be shipped with the new
release.


For a little bit of context, I am taking a look at the packages that
have some CVEs open in unstable, and/or for which there is a new
upstream version available, from an LTS perspective. This is with the
idea of making it easier to provide security support for them thorough
the full five years of the life cycle. If you want or need help, please
don't hesitate to speak up. Someone from the LTS team may step up to
help (CC'ing the LTS team).

Cheers,

 -- Santiago

P.S. The git repository is out-of-date. Would you mind importing and
pushing the latest changes?


signature.asc
Description: PGP signature