As a general rule I think we can say when incoming CVEs are triaged,
they are done only in context to at most the suites supported by the
main Debian security-tracker, that is, whatever falls out of currently
buster is not looked at. Usually it is worked on, looking at incoming
CVEs, assess them in context of source packages, which are
(potentially) affected in the supported suites (from top down looking,
and might be time-depentend on volunteer time), and then doing
assessments on if something needs a DSA or not.
Consider as well this email an initial reply, as I didn't want to have
your question be unaswered.
On Mon, Mar 20, 2023 at 10:23:57PM +0100, Sylvain Beucler wrote:
Hello Security Team,
There are a few packages that we intend to support in LTS, but whose triage
might be incomplete (missing CVEs).
We'd like to clarify the status of these packages in Debian and, if
additional triage is necessary, check how to best coordinate with you.
We're interested in particular in the following packages:
- python2.7: there are missing CVEs compared to python3.*;
python2.7 was referenced in security-support-limited (2020-11), and marked
obsolete in the bullseye release notes (2020-08), but there has been some
(partial) triage since then.
Example missing CVE: CVE-2022-45061
https://security-tracker.debian.org/tracker/source-package/python2.7
https://security-tracker.debian.org/tracker/source-package/python3.9
From Debian security team view on the supported suites as you noted in
bullseye python2.7 is only supported for building packages, basically
not for running them anymore, #975058. Noteworthy the buster release
notes already did contain:
https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#deprecated-components
When python CVEs drop in we usually check the source, and if confident
enough a
- python2.7 <removed>
might be added. But I can say we will not consistently do that, given
the amied deprecation of python2.7 in buster, and status from bullseye
on.
This means, as long LTS team has a suite maintained in the Debian
security-tracker itself shipping python2.7 in a semi-supported way,
buster, and there are python2.7 CVEs with non-negligible impact, they
might need to be looked at separately.
I from my side, will try to at least add - python2.7 <removed> entries
to facilitate your work specifically on that front.
- gnupg1: there is no new CVE since 2019, but there are very few CVEs
assigned to gnupg2 so maybe it's an oversight.
Example missing CVE: CVE-2022-34903
https://security-tracker.debian.org/tracker/source-package/gnupg1
https://security-tracker.debian.org/tracker/source-package/gnupg2
gnupg1 is by now even in buster mostly irrelevant for any security
sensitive workflows. gnupg1 is basically ignored. It might be the case
they are still relevant for stretch or jessie in ELTS, but if so this
might need to specifically be handled in the ELTS tracker with the
extensions mechanism.
See https://www.debian.org/releases/stretch/amd64/release-notes/ch-whats-new.en.html#modern-gnupg
in stretch already. I believe you should not really still support it,
in the ELTS suites, but it is defintively out of scope for the
security-tracker supported suites.
- sqlite (v2.8): there's only a single CVE from 2007. Lots of CVEs only
apply to a subset of sqlite3 though, explaining part of the huge difference
between sqlite and sqlite3.
Example missing CVE: CVE-2020-35525
Note: we also seem to miss a few "SQLite in Google Chrome" CVEs in both
sqlite and sqlite3, which were only linked to chromium, e.g. CVE-2019-13752.
https://security-tracker.debian.org/tracker/source-package/sqlite
https://security-tracker.debian.org/tracker/source-package/sqlite3
(- I had also noted discrepancies in lua5*, but it appears all missing CVEs
are not-affected and implicitly triaged through non-association.)
I believe sqlite (even though not explicitly declared as such in
release notes) falls in same class of deprecation as of sqlite3. Even
in buster, where it is still present. There is only really (IMHO!) a
point of looking src:sqlite in context of CVEs for sqlite3 if any of
the reverse dependencies are used in security sensitive context.
Looking at
cl-sql: cl-sql-sqlite
dbconfig-common: dbconfig-sqlite
golang-gosqlite-dev: golang-gosqlite-dev
kannel: kannel
kannel-dev
kannel-extras
kannel-sqlbox: kannel-sqlbox
libdbi-drivers: libdbd-sqlite
libopendbx: libopendbx1-sqlite
python-sqlite: python-sqlite
python-sqlite-dbg
qsf: qsf
qt4-x11: libqt4-sql-sqlite2
# Broken Build-Depends:
kannel: libsqlite0-dev
sqlite
libapp-info-perl: libsqlite0-dev
libdbi-drivers: libsqlite0-dev
libopendbx: libsqlite0-dev
python-sqlite: libsqlite0-dev (>= 2.5.6)
qsf: libsqlite0-dev
qt4-x11: libsqlite0-dev
there might be some doupts.
Secondly https://bugs.debian.org/976377 has as well some context.
Is Debian currently triaging (associating CVEs) for these packages?
(Or are they obsolete somehow?)
If they are not triaged and you do not wish to perform such triage, would
you mind if we do, and do you have recommendations so as to respect each
other's workflows?
I guess with the above now the discussion can begin. What I'm
personally against, if the security-trackr starts to get cluttered
with entries, which are not anymore relevant for any of the supported
suites in the security-tracker (that is including one LTS suite). What
is relevant for ELTS suites, should IMHO go into ELTS tracker (I know
this is not in all cases possible).
We try to triage CVEs and check the affected potential source
packages, but I can say the gnupg1 and sqlite cases are quite clear
that they won't be looked at. If after the above you still think it's
needed for LTS (and ELTS), then they need to be separately looked at
as well by LTS team members.
I hope I might go into more details if questions arises, as said, my
main goal here is to give you a reply and not leave the thread
unaswered. Input from Moritz would be very welcome from my side, as
one of the top triagers for incoming CVEs.