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

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



Hi,

I wonder if the problem is a matter of package priority, rather than no-dsa itself.

Fixing many no-dsa/postponed for grub2, qemu or python* is fine, because there's demand/sponsoring for it, and we're grouping fixes.

Fixing a couple no-dsa following the latest point release isn't urgent, and shouldn't be done when there are higher-priority/long-standing packages. Those can be nice for newcomers though.

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'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.

Cheers!
Sylvain

On 27/05/2025 22:08, Roberto C. Sánchez wrote:
During the monthly LTS meeting Emilio mentioned that we should
reconsider our approach to <no-dsa>.

The specific statement was: "I feel like we're giving ourselves too much
work by tackling no-dsa issues on LTS, then forcing ourselves to fix
them in stable. maybe we need to revisit our no-dsa policy"

We have generally made an effort to try to fix <no-dsa> CVEs, or to
re-triage them as either <postponed> or <ignored> when those other
designations are appropriate. For the purposes of this discussion it
seems safe to include <postponed> along with <no-dsa> as they both
essentially mean "fix later".

As has been observed (not only by Emilio in the meeting, but by others
at various different times), if we elect to fix a <no-dsa> issue in LTS,
then we generally need to fix that same issue in stable. If the CVE is
not fixed in stable then there is a possibility that a user may
experience an upgrade regression. This happens when a CVE is fixed in an
older release and then when the upgrade to a newer release is performed
that CVE is suddenly no longer fixed in the new system. This is an
undesirable situation that we want to try to avoid.

With all of that in mind, I am interested in the thoughts of everyone on
the team, both for an aggressive posture towards fixing <no-dsa> issues,
and for a more relaxed posture where we allow more <no-dsa> issues to
remain unfixed (presumably those which are of lower importance). I am
also interested to know whether people think that our more clearly
defined "(un)stable-first" approach to package updates might make this
less of a pressing issue going forward (because we would be landing
fixes in stable before* landing them in LTS).

* Which may actually mean "landing fixes in the PU queue before landing
   them in LTS").

At this point I don't know that we are ready to make any major changes,
but I am genuinely intersted to see where this discussion goes and what
points are raised.

Regards,

-Roberto



Reply to: