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

Re: What do do with bullseye minor issues?


On 29/09/2022 09:09, Emilio Pozuelo Monfort wrote:
On 28/09/2022 23:54, Ola Lundqvist wrote:
Took me a month to get down here in the email backlog. I think your
reasoning makes sense.
I have added the following to the LTS/Development page.

"If a CVE has been fixed in Debian Stable it should, in general, be fixed
in LTS as well, or marked as ignored. It does not make sense to have such
CVEs marked as postponed or no-dsa since either the Debian Security team or
the maintainer have decided that it was worth fixing."
Please update that page if you think I was unclear or wrong.

Note: the documentation was moved away from the wiki.

I don't think that's correct. Say for example:

Package foo has two CVEs:

- CVE-2022-1234 of high severity, affecting stable
- CVE-2022-5678 of minor severity, affecting stable and oldstable

The sec-team fixes both.

Now, what do we do? According to your reasoning, we should either do a DLA to fix a single minor issue, or mark it as ignored. I think marking it as postponed is the correct course of action here.

That would be a rare corner case in the "Issues postponed for <oldstable>, but already fixed in <stable> via DSA or point releases (to be fixed or <ignored>)" report in lts-cve-triage.py, which I've never seen happen so far.

Ola is basically documenting that report in the documentation, maybe in a too coercive phrasing.

Such as CVE would keep being reported until fixed (we can live with that). But since we do not time-limit such a <postponed> issue there's a chance that the "minor" CVE remains unfixed forever, so maybe it's good to fix it right away nonetheless.

I can think of similar situations when a maintainer fixes a minor issue through a point release. It could be fixed or postponed, but there's no need to ignore it.
<ignored> would be for e.g. a minor issue with invasive, risky-to-backport patch. There's no need to ignore it indeed, but that's a possibility.

However, after a point-release, I believe leaving it <postponed> indefinitely doesn't make sense. We know whether we'll fix it like stable, or never will (ignored). Hence the report and Ola's recommendation.

Note that all this is usually not decided during the first-pass triaging, but later on, after a fix landed in stable.


Reply to: