| Re: [mosquitto-dev] How to address CVE-2023-28366 in older versions of mosquitto |
Am Dienstag, dem 10.10.2023 um 09:38 -0400 schrieb Greg Troxel: > I'm not Roger but I maintain other software that has problems from LTS > users and I maintain the mosquitto package in pkgsrc. Hi Greg, thanks for your reply. I wanted to clarify some points and answer some of your questions. I'll snip some of your initial text for readability. [...] > Wow, 1.5.7. [...] > > 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. 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. > > 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. Fair enough. > > 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 agree and that's what I am trying to do currently. Learning more about the software and exploring alternative paths by asking questions. > > 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 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. Fair enough. > > 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. > 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. Indeed backporting targeted fixes is our preferred way of handling security issues. > 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. > 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. > > Of course, you should listen to Roger not me! I hope he is less cranky :-) I'm quite optimistic. :-) > Greg Cheers, Markus
Attachment:
signature.asc
Description: This is a digitally signed message part