[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



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


Reply to: