Hello everyone, After the recent discussions regarding triage decisions and the criteria for keeping packages in dla-needed.txt, I wanted to provide some guidance to help make matters more clear.
First, as to the matter of triaging individual CVEs: - we prefer to see all CVEs fixed, absent good technical grounds to the contrary (e.g., minor issue, high risk of regression, too difficult to feasibly backport, etc) - if a CVE is 'fixed' in LTS but still 'no-dsa' in (old)stable, then we should do what we can to coordinate uploads to (old)stable so that the issue is fixed in a future point release - if a CVE is 'fixed' in LTS but 'ignored' in (old)stable, then the security team should be contacted to see if they would be willing to change to 'no-dsa' so that a point release fix can be made - note that 'fixed' in the above items specifically means "fixed by way of a DLA (or earlier DSA), rather than 'not-affected' (since 'not-affected' renders as 'fixed' in the package-level view)" Second, as to the matter of the criteria for keeping packages in dla-needed.txt: - if a package requires work by the LTS team, then it should remain in dla-needed.txt; this includes if a DLA has already been published and we are working to support an upload to (old)stable - if a package is assigned, it must not be removed without first coordinating with whomever has claimed it (this is to avoid confusion about what work is being done and the state of the package) - just because all CVEs for a package are 'no-dsa' (or even 'postponed') in LTS does not mean that the package must be removed from dla-needed.txt; it may be that there are multiple no-dsa or postponed CVEs and that they collectively merit an update Finally, as to the matter of Go and Rust packages (since golang-go.crypto was among the packages caught in the recent discussion on triaging), please note the following from the Debian release notes [0]: ---------------------------------------- 5.2.1.2. Go- and Rust-based packages The Debian infrastructure currently has problems with rebuilding packages of types that systematically use static linking. With the growth of the Go and Rust ecosystems it means that these packages will be covered by limited security support until the infrastructure is improved to deal with them maintainably. In most cases if updates are warranted for Go or Rust development libraries, they will only be released via regular point releases. ---------------------------------------- - in general, we want to be mindful of the fact that updating Go and Rust packages can produce a great deal of churn in the distribution (because the pervasive use of static linking can require rebuilding dozens or even more than a hundred packages) - this particular issue is the subject of ongoing work within Freexian (to try to develop tooling to address the limitations expressed by the secteam in the release notes) - for the time being, particularly serious vulnerabilities in Go and Rust packages are sufficient to potentially justify listing them in dla-needed.txt, but in general we would prefer to not list these packages in dla-needed.txt to avoid the mass number of rebuilds (note that if you are unsure if a CVE rises to the level I have described, you should bring it up for discussion on this list) - if you are specifically intersted in helping to improve the situation for statically linked language ecosystems, then there is an issue [1] in the public lts-extra-tasks project in Salsa Additional information about this particular issue of security updates for ecosystems that use static is available in a recent thread on this list [2]. [0] https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#limited-security-support [1] https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/60 [2] https://lists.debian.org/debian-lts/2023/12/msg00035.html Regards, -Roberto -- Roberto C. Sánchez