Hi,
On 30/05/2025 03:25, Samuel Henrique wrote:
On Wed, 28 May 2025 at 20:49, Sylvain Beucler <[email protected]> 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
