Hi,
I add here a reminder to use './find-work' (as documented, including at
the top of dla-needed.txt) to look for work _sorted by priority_.
I triaged a few low, non-sponsored, harmonize-with-point-updates
packages this week, and I'm a bit surprised that some were claimed and
even uploaded already.
So, if a package has few users (and likely few/no sponsors) it will be
sorted as low-priority and worked on only when time is available :)
Cheers!
Sylvain
On 14/03/2024 23:53, Ola Lundqvist wrote:
> 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 <ola@inguza.com
> <mailto:ola@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 <roberto@debian.org
> <mailto:roberto@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 <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
> <https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/60>
> [2] https://lists.debian.org/debian-lts/2023/12/msg00035.html
> <https://lists.debian.org/debian-lts/2023/12/msg00035.html>
>
> Regards,
>
> -Roberto
>
> --
> Roberto C. Sánchez
>
>
>
> --
> --- Inguza Technology AB --- MSc in Information Technology ----
> | ola@inguza.com <mailto:ola@inguza.com>opal@debian.org
> <mailto:opal@debian.org> |
> | http://inguza.com/ <http://inguza.com/> Mobile: +46
> (0)70-332 1551 |
> ---------------------------------------------------------------
>
>
>
> --
> --- Inguza Technology AB --- MSc in Information Technology ----
> | ola@inguza.com <mailto:ola@inguza.com>opal@debian.org
> <mailto:opal@debian.org> |
> | http://inguza.com/ <http://inguza.com/> Mobile: +46
> (0)70-332 1551 |
> ---------------------------------------------------------------
>