Hi again One more thing. Should we have a statement about the fact that we do not judge whether to ignore a package based on the number of users? We only ignore in case it is not really feasible to backport without breaking things.
Do we have any limit on how difficult it is allowed to be to backport the correction? I mean say it takes 200 hours to fix a package with a fairly minor issue that rarely anyone uses. Should we ignore in such case? Yes I'm taking things to the extreme here, but just to highlight that there are greyzones. Cheers // Ola On Thu, 14 Mar 2024 at 23:39, Ola Lundqvist <o...@inguza.com> wrote: > Hi Roberto > > Thank you for the clarifications. I think we should add some more. > > See below. > > On Thu, 14 Mar 2024 at 21:37, Roberto C. Sánchez <robe...@debian.org> > wrote: > >> 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 >> >> > > -- > --- Inguza Technology AB --- MSc in Information Technology ---- > | o...@inguza.com o...@debian.org | > | http://inguza.com/ Mobile: +46 (0)70-332 1551 | > --------------------------------------------------------------- > > -- --- Inguza Technology AB --- MSc in Information Technology ---- | o...@inguza.com o...@debian.org | | http://inguza.com/ Mobile: +46 (0)70-332 1551 | ---------------------------------------------------------------
