Skip to content

Update documentation on fixing CVEs outside of LTS, in unstable and stable

Following today's meeting, we want to update bits of our documentation.

Here are some points based what was discussed:

  • "Can I also provide security updates for non-LTS releases?"

    • precise the shift of priority, where LTS now aims at aligning CVE fixes in all dists, and possibly fix CVEs proactively (ahead of / along with Stable)
    • document the intent:
      • of aligning fixed CVEs in all dists (DD feedback [1], clarity for end users, sample issues caused by CVE regressions on upgrade)
      • of fixing many mid-low/severity CVEs in all dists (e.g. shift in regulations, shift in users&customers behavior faced with stricter security audits)
      • present these as QA work from the LTS Team, respecting the current Debian procedures (contacting security+release teams & maintainers, delayed NMUs)
    • precise the process priority when CVEs are not yet fixed anywhere: e.g. fixing no-dsa/postponed CVEs not yet handled in stable vs. leaving them and working on another pending package; CVE priorities; packing fixes with other higher-priority CVEs, short of having lts-proposed-updates; handling XSS/UBSAN/...; not handling <ignored>; etc.
    • precise the process priority when CVEs have been fixed in LTS already: e.g. working on aligning all dists vs. working on another pending package
    • good feedback so far from individual uploads following this logic
    • I'd suggest documenting most of this (goal, rationale) to Development, which is public, rather than the current private page; typically leaving LTS contributors/collaborators specific time self-assignments rules on the private page, and moving the rest to to Development. Development already covers some of the work priority questions in the Triage sections (a b) which we may want to adjust.

  • Document who to contact and in which order, cf. santiago's e-mail "Contributions to stable(-proposed-updates)" on 2024-12-05 / deblts-team@freexian.com , which forwards feedback from the Security Team. This can be a "Process" subsection.

  • If appropriate, write to debian-devel@l.d.o or similar to present our plan and proactively get feedback from the Debian community at large; hence ensuring we're working well in synergy with Freexian/customer goals and Debian goals.

[1] https://wiki.debian.org/DebianEvents/gb/2023/MiniDebConfCambridge/Sanchez 48:48 question from Sledge