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)
I think we should clarify what we mean with "Minor issue". Is it what is typically written as "(Minor issue)" after "<no-dsa>" statement or something else.
I'm asking since it seems to be a common view that we should fix all minor issues too. I do not agree to that, but others has expressed that opinion.
- 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
I think we should add that if LTS has an issue as no-dsa/postponed and (old-)stable has it fixed, then we should add/keep the package to dla-needed (or decide to ignore in case it is too invasive) to ensure LTS gets it fixed as well. At least that was the rule I concluded from the discussion and why I re-added a few packages back to dla-needed.
I also think we should add that in the typical case (all no-dsa/postponed/ignored/fixed and they are few) this means that the package should be removed from dla-needed.txt. I think it has a merit, just to keep things tidy.
In fact I think we should typically remove the package from dla-needed if it should not have been added, with exceptions described above.
Best regards
// Ola
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