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:

> Yup, I'm aware of how old this version is. :-) Please note I'm not the
> maintainer of mosquitto (Roger is, which I only learned recently) but a member
> of Debian's security and LTS team.

It seemed you were from Debian, so I got that right.

>>   I don't understand why you haven't updated to 1.5.11.
>
> 1.5.7 is the official version in Debian 10 "Buster" and once released it never
> changes for a specific distribution of Debian. There was never a need to
> upgrade to 1.5.11 or a later version because security problems could be fixed
> via targeted patches or it was not affected because the vulnerable code was
> introduced in later versions.

I see, so "stable" means "not even micro updates, which are generally
bug fixes only".

>>   Bringing 2.0.x to an environment that expects 1.5.x is going to cause
>>   behavior changes that are inconsistent with LTS doctrine.
>
> Actually backporting newer upstream releases is allowed. For instance we
> regularly backport newer versions of Firefox/Chromium because the changes are
> often far too complex but in general this is the exception and not the rule
> because of the risks involved. It really depends on the software in question.
> Regarding mosquitto: it seems there are really only two other packages that
> depend on it, namely collectd and baresip-core. The ABI of mosquitto didn't
> change in the past five years (at least that is what I deduce from the library
> name of mosquitto in Debian). Assuming tests with a newer version were
> successful, a new upstream release could be a way to address the problem.

The ABI is more than the soname.  I am pretty sure there have been
config file behavior changes with 2.0.  But I deal with them long ago
and have since reused those memory cells for other things :-)   So
people running a broker may not get the behavior they expect after an
update.  Maybe that's ok.

>>   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.
>
> Debian maintainers are expected to support their packages in stable releases
> and risk that their package will not be included in future releases if those
> are regularly affected by open/unhandled security problems. The security team
> can  only spend a limited time on fixing them. In the past security support
> ended after three years when oldstable reached its end-of-life. The LTS project
> made it possible to extend the life span of stable releases to five years.  

Well, it defines that it should be supported, but it's still hard!
Thanks; I am only a very casual debian user - mostly NetBSD.

>> 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 maintain many Debian packages myself and I find it ok when people ask basic
> questions and it doesn't really matter to me if they get paid for it or not. If
> people repeatedly ask the same question, it is more of an incentive to improve
> the documentation somewhere. I can understand the feeling of "being exploited"
> though. I hope that's not the case here. 
>
>> 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).
>
> I believe most Debian users know how Debian works but yeah there are always
> some people who have the wrong expectations or who simply don't read the docs.
> Most upstream developers support only the latest version, which I find pretty
> reasonable, some also support "stable" releases with security support for a
> limited number of years and in rare cases upstream goes to considerable length
> to merge security fixes into ancient major releases (Wordpress comes to mind
> here) because they know they have a large user base who prefers and still uses
> them.
>
> I don't think LTS distributions are the problem because in most cases we can
> find a reasonable solution for security issues. But in order to find them we
> need to gather information, so here I am.

And I really did mean to say "If you weren't from Debian".  Of all the
LTS queries, hearing from clueful people that are part of true community
Free Software projects is the absolute best case, and if that was all it
was, there would be no issue.

The real questtion will be digging through the patches and figuring out
the old code.  I can't imagine that's going to be less than a few days
of effort for someone (who is capable in C and network code).