Re: How much no-dsa is too much no-dsa?
Disclaimer: I'm not affiliated with Freexian and I don't know the specifics of
your user's demands. I'm replying based on my Debian experience.
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.
This reduces amount of work needed, but most importantly it also reduces risks,
since the fix for even the silliest vulnerability can cause major
regressions when things goes wrong. This risk is increased because the
complexity of the backport is higher as the releases gets older.
> 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.
> 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.
You might want to not limit to dsa/no-dsa even, instead stating a severity
level as the cut-over for ELTS. This brings the question of how severity
will be defined, but it might be the best path forward.
Regards,
--
Samuel Henrique <samueloph>
Reply to: