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