Re: Triage status for a few old packages
Hi Sylvain,
On Sat, Apr 15, 2023 at 01:29:08PM +0200, Sylvain Beucler wrote:
> Hello Security Team,
>
> On Thu, Apr 13, 2023 at 05:33:15PM +0200, Moritz Muehlenhoff wrote:
> > On Wed, Apr 12, 2023 at 10:58:15PM +0200, Salvatore Bonaccorso wrote:
> > > > - 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?
> > >
> > > >From my side no objection on that. If you do not hear a NACK, go ahead
> > > with it.
> >
> > Yeah, that sounds fine.
>
> Initial CVE association and triage done for python2.7, comparing with
> python3.9 and python3.7, thanks.
> https://security-tracker.debian.org/tracker/source-package/python2.7
>
>
> > > > - For gnupg1, we'd like to reference it in
> > > > debian-security-support/security-support-limited (or
> > > > security-support-endedXX).
> > > > Would that be OK?
> > >
> > > Inclided to say to add it to security-support-limited. The reference
> > > to the release notes might suffice as explanation, or you can be more
> > > verbose and reference #982258. It lists reasons for still keeping
> > > src:gnupg1 to handle specific usecases.
>
> Merged in security-support-limited, thanks.
> https://salsa.debian.org/debian/debian-security-support/-/merge_requests/15
>
>
> > > - 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).
> >
> > Ok understand.
> >
> > > 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?
> >
> > The question is then probably: If kept supported, you would need to
> > check each of the sqlite affecting CVEs if they apply really to the
> > old code-base. In such a case, add
> >
> > - sqlite <removed>
> >
> > and triage it further for buster.
>
> So we can do the same as with python2.7, expect this time the LTS Team
> members are the only ones adding the '- sqlite <removed>' entries for
> new sqlite3 CVEs.
>
> I can proceed to add such entries for the past CVEs and prepare LTS
> procedures to ensure this is done, until the end of buster-lts next
> year.
>
> Are you OK with this?
I tend to say yes. But, take for example CVE-2022-46908, was the
src:sqlite then ever affected by this? It affected only more recent
sqlite3 versions. In this case we can probably say that almost sure up
to the latest version of sqlite ever present in unstable, 2.8.17-15,
was not affected, and a
- sqlite <not-affected> (Vulnerable code introduced later)
would then match more closely the status.
But from my point of view, you could go ahead with adding sqlite
entries as long buster als LTS suite is yet supported. Once moving to
ELTS, adding such entries can stop.
This is more a personal view: I do not see much benefit in keeping
sqlite supported. I see your dependency chain which might be relevant
as argument. The other argument, needing support for updating
databases from v2 formats to v3 formats, might fall more in the same
category as the gnupg1 support case why it is kept in the archive.
But then again i have not an authoritative voice here, it is just a
personal feeling on if time on evaluating sqlite CVEs is worth of.
So, unless no veto raised otherwise, for me feel free to go ahead with
- sqlite <removed> entries, or if there is certainity that the sqlite
codebase was in no version in unstable ever affected, with the
<not-affected> variant.
Regards,
Salvatore
Reply to: