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

Debian LTS and ELTS -- March 2024



Hello,

This was my ninth month working on LTS and ELTS.  Thank you to Freexian
and Freexian's sponsors for making these projects possible:
    <https://www.freexian.com/lts/debian/#sponsors>

LTS

- pillow

  - Released DLA-3768-1 fixing CVE-2021-23437 and CVE-2023-44271.

  - My DLA-3768-1 also included a follow-up fix for CVE-2022-22817.
    A fix for this CVE had been announced in DSA-5053-1, but I realised
    that we hadn't included a follow-up fix that upstream had made,
    covering some additional cases.

    I also discovered that our backport of the automated test for the
    vulnerability having been closed delivered false positives.  I had
    to learn a bit more about Python's evaluation model in order to be
    sure that my revised backport of the test really worked.
    Thanks to Chris Lamb, one of the most experienced Python developers
    on the LTS team, for review here.

  - Some of these CVEs are unfixed in bullseye and bookworm, which will
    eventually become LTS distributions.
    I have offered my help to the Security Team to finish preparing the
    fixes for including in point releases.

- bind9

  - Started work on backporting upstream fixes for four CVEs from 2023.

- Correspondence, catching up on meeting logs, etc..  We had a number of
  valuable process improvements this month, one discussed below.

ELTS

- pillow

  - Released ELA-1059-1 fixing CVE-2021-23437, CVE-2022-22817,
    CVE-2023-44271 & CVE-2023-50447.

  - Updated tracker information for CVE-2019-16865 & CVE-2022-45198.

    CVE-2019-16865 was marked as ignored for the same reason that
    several other CVEs were marked as ignored.  But I realised that the
    vulnerable code is not actually present in stretch and buster.

    I fixed similar incomplete tracking regarding CVE-2022-45198, across
    the LTS and ELTS suites.

- This month, I also carefully reviewed some team discussions regarding
  these different states which are other than plain "vulnerable" and
  "fixed".  We discovered that different team members were thinking of
  the tags slightly differently.  Although it's not likely that these
  differences of opinion have led to any serious vulnerabilities going
  unfixed, they are likely to caused us to work less efficiently at
  various points.

  One of the things that has always most interested me about Debian,
  from the very beginning of my involvement as a volunteer, is how we
  can design processes and tooling that suit intermittent contributor
  availability and communication, and handing over work efficiently.
  As a result, I found these clarificatory discussions particularly
  interesting.

-- 
Sean Whitton


Reply to: