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