Re: [mosquitto-dev] How to address CVE-2023-28366 in older versions of m

[Greg Troxel <gdt@xxxxxxxxxx>]

Markus Koschany via mosquitto-dev <mosquitto-dev@xxxxxxxxxxx> writes:

> @Roger

I'm not Roger but I maintain other software that has problems from LTS
users and I maintain the mosquitto package in pkgsrc.

> Thanks for your help and for pointing out the fixing commits for the recent
> CVE. I believe I have addressed them in Debian stable and oldstable already.
> Now I am looking to fix Debian Buster as well which ships mosquitto 1.5.7.

Wow, 1.5.7.  On 2019-07-20 I added mosquitto 1.6.3 to pkgsrc.  The date
I find in git history for 1.5.7 is
  Wed Feb 13 23:51:46 2019 +0000
The last 1.5.x was 1.5.11 tagged as of
  Thu Mar 11 20:01:22 2021 +0000
So this is from 4 years and 8 months ago, more recent if you count
1.5.11 -- but 1.5.7 to 1.5.11 is just highish-severity bugfixes.  More
importantly, assuming 1.6 wasn't suitable for packaging, 1.6.1's date is
  Fri Apr 26 17:07:21 2019 +0100
which is 4 years and 5.5 months ago.

Presumably you know all this, but it's helpful context for others to
understand just how long it's been since 1.5 was maintained.

My impression is that the mosquitto project maintains the latest
release, and when there's an issue ships a new micro that fixes it.
Plus at times, the previous branch might get serious fixes, which 1.5.x
appeared to do for about 2 years after 1.6.

> Apparently 1.5.7 is affected by CVE-2023-28366 but the code base is quite
> different. Is there a less intrusive way to address this problem? Is there a
> sensible workaround available or should I just ignore the issue? Another
> possible idea is to backport 2.0.11 from Debian oldstable. What would you
> recommend as the maintainer of mosquitto in Debian?

As someone who maintains other software, my answer would be:

  It seems to me that people who simultaneously want old software and
  new software are just not ever going to be happy.  I pesonally do not
  use LTS and recommend against it.

  If you're going to to choose to run old software, that upstream has
  chosen not to maintain, then it's on you to spend the software
  engineering resources to figure things like this out and deal.

  I don't understand why you haven't updated to 1.5.11.

  I don't know if 1.5.7 is or isn't affected by this, and I am not
  inclined to spend the time to find out, because the project no longer
  maintains it.

  Bringing 2.0.x to an environment that expects 1.5.x is going to cause
  behavior changes that are inconsistent with LTS doctrine.  That leaves
  ignoring and backporting/re-implementing fixes.  There are no good
  answers -- one seems dangerous and the other is a lot of work -- and I
  decline to make a recommendation.  I don't want to spend time helping
  with backporting; that's what upstream no longer supporting ancient
  versions means.

  I do wonder what normal Debian doctrine is about dealing with this
  kind of situation, as I expect most software versions in really old
  Debian are no longer maintained by their upstreams.  I had the
  impression that only stable and oldstable were maintained, and thst
  oldstable became iffy after stable had been around a while.

You're here from Debian, which is community Free Software, so I wouldn't
say the following to you (but I would if you were from Red Hat):

  If you're charging customers for supporting old versions of Free
  software, it's really not ok to ask upstreams to help do that work for
  you even a little, unless you are paying them their normal full
  commercial work consulting rates.

I know this sounds cranky but the world as I see it is that LTS
distributions distribute old verisons that upstream is no longer
maintaining and between bug reports showing up in the tracker and
security issues it imposes a fair bit of effort on upstreams.  (I have
actually had the experience of end users asking for support for ancient
versions because they are included in some LTS, and had to spend effort
documenting that bug reports are only allowed if against the most recent
release or the tip of git).

Of course, you should listen to Roger not me!  I hope he is less cranky :-)

Greg