Re: following or getting ahead of Stable
On Wed, Dec 11, 2024 at 11:05:10AM +0100, Sylvain Beucler wrote:
> Hi,
>
> On 09/12/2024 18:55, Sylvain Beucler wrote:
> > On 07/12/2024 04:10, Roberto C. Sánchez wrote:
> > > The Security Team has supplied a list of packages/CVEs which were fixed
> > > by DLA (some in bullseye and some in buster) but which remain unfixed in
> > > bookworm (and which are tagged no-dsa, indicating that the Security Team
> > > has no immediate plans to address them).
> >
> > What is the general feeling/context over this situation?
> >
> > - Does LTS fix too many mid/low CVEs, hence should prevent this
> > situation e.g. by avoiding fixing ahead of Stable?
> >
> > - Or, does LTS fixes CVEs appropriately, hence is encouraged to fix more
> > CVEs, but always in all dists?
>
> For more context: at a point LTS got negative feedback from Debian about
> making too frequent DLAs for low-priority CVEs (resulting in more
> maintenance/restart work for sysadmins around the globe), and negative
> feedback from Freexian about making such releases instead of handling
> packages with more severity or age.
>
> Conversely, this thread is about fixing many low/mid-priority (no-dsa) CVEs,
> and not in LTS but in Stable.
>
> As a contributor, and as FD, I'm now unsure of what to include in DLAs.
>
> For instance, ruby*, which has 5-6 pending <no-dsa> CVEs about REXML:
> https://security-tracker.debian.org/tracker/source-package/ruby3.1
> https://security-tracker.debian.org/tracker/source-package/ruby2.7
>
> As FD I decided not to add it to dla-needed.txt, waiting for Stable action
> to follow, e.g. a point-update. The next FD made the opposite decision and
> added it for immediate action.
IMHO rotating FD among many people is a bad idea, but I know that
I sound like a broken record when saying again that a small FD team
of 2-3 people would be better.
> So is it welcome to fix those low-priority (DoS) CVEs or should we wait?
>...
"avoiding fixing ahead of Stable" or "should we wait" gives a wrong
impression of the options available.
Whether or not a no-dsa CVE ever gets fixed in stable depends mostly on
who the maintainer is.
Some (few) maintainers are providing fixes for no-dsa CVEs to stable-pu,
but most do not.
A strict "follow stable" approach would result in fixing CVEs where you
wonder whether it is even exploitable in completely fringe packages
where the maintainer happened to do a stable-pu upload, while not fixing
high popcon packages with many CVEs.
In your Ruby example, ruby3.1 in bookworm is already missing fixes for
two non-REXML CVEs that were DLA-fixed in bullseye.
If the 6th REXML CVE also gets tagged no-dsa, who do you think would fix
the 6 REXML CVEs in bookworm?
The realistic options are "LTS team" and "noone".
These are the options that are available,
"waiting for maintainer to fix bookworm" is not.
These CVEs will be maintainer-fixed in trixie through a new upstream
version. A pretty bad process would be if we spend 2 years waiting
for Godot, and then DLA-fix in bookworm and the ELTS releases when
bookworm becomes LTS.
The sane approach is that FD decides whether or not the CVEs
currently unfixed in bookworm warrant a DLA, and if yes the
DLA contributor also provides the stable-pu upload
(or DSA if the security team prefers that) for ruby.
If "too frequent DLAs for low-priority CVEs" is a problem,
the criteria FD uses when deciding which packages to add
to dla-needed should be adjusted.
> Cheers!
> Sylvain
cu
Adrian
Reply to: