Re: How much no-dsa is too much no-dsa?

[Sylvain Beucler <beuc@beuc.net>]

Hi,

On 30/05/2025 03:25, Samuel Henrique wrote:
> On Wed, 28 May 2025 at 20:49, Sylvain Beucler <beuc@beuc.net> wrote:
> > I wonder if the problem is a matter of package priority, rather than
> > no-dsa itself.
>
> That's what it looks to me, from the outside.
>
> I think all distributions out there are defaulting to not fixing lows and
> moderates for releases >5 years old, exception being when a user requests.

I mean priority at the package level, not at the per-CVE (severity) 
level; we have an internal priority list that currently takes into 
account the age of the package in the queue, and the amount of sponsoring.

My point is "no-dsa" (or CVE severity) may not be the right angle in 
Roberto's initial question, and our package priority would be better suited.


Note: for per-CVE severity, by comparison Ubuntu and other distros seem 
to fix a similar amount of what we tagged no-dsa/postponed, and from 
what I hear users tend to request a lot of such fixes for "corporate" 
reasons.
Note: about risks: we don't do fixes that are too risky compared to the 
CVE severity.

> > Fixing a single no-dsa for a single python update isn't fine, because we
> > don't want many DLAs and spam the sysadmins worlwide. This can be postponed.
>
> I don't think sysadmins ever get concerned about too many CVE fixes, they tend
> to actually reduce the spam they get from the scanning solutions, but I overall
> agree with your other points.

To clarify, I mean that updates often imply restarting services and/or 
servers, with potential downtime impact, overall they have non-zero cost 
for users, and hence are better grouped.


> > I've got the feeling that many contributors pick updates in
> > xla-needed.txt without checking their priority in ./find-work. All the
> > planned work to fine-tune package priority using CVE severities won't be
> > useful if contributors never check the package priorities.
>
> It would be sane; less risky and more clear to users, to state something like
> "ELTS will default to only fixing DSA-worthy vulnerabilities, users can
> request fixes". Other vulnerabilities can also be fixed, but the prioritization
> can come from somewhere else, e.g.: key package or user request.

I'm not sure, this policy would mean we don't catch up with stable point 
releases, and don't trim medium CVEs (in all dists) that tend to pile-up 
over time and IMHO are better fixed in the long run. I feel this doesn't 
reflect what users/sponsors actually ask, hence what we end up doing.

Cheers!
Sylvain