[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Triage status for a few old packages

Hello Security Team,

On 01/04/2023 21:31, Salvatore Bonaccorso wrote:
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.

Waiting for other security team members' input, I can clarify a couple points and propose a plan for action.

First I confirm that this is intended for LTS only; for ELTS we can just triage in the ELTS security tracker almost without interference.

- For python2.7, AFAIU you would be inclined to associate CVEs to that package more often, for the duration of buster-lts, which would help a lot. On the LTS side we'd like to associate all the past python3.x CVEs to python2.7 (13 CVEs) and triage them accordingly (so we can easily compare python2 and python3 status).
Would that be OK?

- For gnupg1, we'd like to reference it in debian-security-support/security-support-limited (or security-support-endedXX).
Would that be OK?

- For sqlite, I believe LTS supports it as a dependency of yum<python-sqlite<libsqlite0. There are also direct use cases of the 'sqlite' CLI: for accessing v2 databases, and migrate v2 databases to v3 (AFAICS). So I'm more inclined to keep it supported for the duration of buster-lts (package was removed in later dists).
What do you think?

Sylvain Beucler
Debian LTS Team

On 01/04/2023 21:31, Salvatore Bonaccorso wrote:
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

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

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

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.

(- 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-sqlbox: kannel-sqlbox
libdbi-drivers: libdbd-sqlite
libopendbx: libopendbx1-sqlite
python-sqlite: python-sqlite
qsf: qsf
qt4-x11: libqt4-sql-sqlite2

# Broken Build-Depends:
kannel: libsqlite0-dev
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.

Reply to: