Hi Sylvain, First a disclaimer, this probably needs further discussion, reflects my current personal knowledge and view on the question, and further feedback is appreciated by at least one other persion in the Debian security team doing frequent CVE triage, I have in mind Moritz.
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. Regards, Salvatore
