Add ability to specify maximum message size

[acogoluegnes]

No description provided.

[gdimitrov7]

The releases list and the commit history both show that the fix was backported to:
v5.17.1
v5.16.1
v5.14.3

@acogoluegnes Can you confirm?

I want confirmation because

• https://nvd.nist.gov/vuln/detail/CVE-2023-46120#vulnConfigurationsArea
• GHSA-mm8h-8587-p46h

show that the fix is only available in 5.18.0+ which is only one branch.

@michaelklishin Is it possible to update the security advisories with correct versions?
Thank you.

[michaelklishin]

@gdimitrov7 you can inspect the branches of those releases just like we can, here is 5.17.x-stable, for instance.

A GitHub security advisory only has one "affected versions" field IIRC. There are no reasons to to prefer 5.17 over the latest 5.x, this client ships minors often and usually without breaking changes of any kind.

[michaelklishin]

@gdimitrov7 we cannot retroactively update NIST database entries, therefore we won't update the advisory even if there was/is a way to list multiple affected versions.

[acogoluegnes]

@gdimitrov7 Yes, it's been backported to those patch releases. You should use 5.20.0 (the latest as of today) though, it's backward compatible.

[peterwvz]

we cannot retroactively update NIST database entries, therefore we won't update the advisory even if there was/is a way to list multiple affected versions.

@michaelklishin You can actually update NVD. Happens all the time. Reanalysis efforts are typically driven by external engagement such as emails to nvd@nist.gov or cpe_dictionary@nist.gov. You'd include the pertinent info (like this thread) showing the backports happened. I think that's the only way to get all the enterprise vulnerability scanners to acknowledge that 5.18.0 is not the only fix for this CVE.

[michaelklishin]

There are also no reasons for the 5.17 users not to upgrade to 5.18 or 5.20. As stated earlier, this client usually ships minor releases without any breaking changes.

Our small team has more important things to worry about than making sure a three minor behind patch release of this client has a backport accounted for in the NIST database.

We have fixed the issue and released a round of back ports. NIST is notified. If someone has the cycle to update the NIST database, they can do it by providing evidence from this public repository.

[peterwvz]

Understood. I am working with a third party vendor. They are on 5.14.3 and getting caught by an enterprise vuln. scanner flagging that versions as vulnerable - saying that they need to upgrade to 5.18.0.

this client usually ships minor releases without any breaking changes.

It's the "usually" in that sentence that is the problem. The vendor has other critical CVEs that need addressing. And upgrading any component involves rerunning all the regressions tests/acceptance test, etc. etc. Work they'd prefer to avoid and they know they can avoid since they actually do have the backported fix!! The only thing that doesn't understand that is the enterprise vuln. scanners....

[michaelklishin]

@peterwvz we have done our job: we have responded to a responsibly disclosed vulnerability, patched it, backported it N times and produced a round of releases, then disclosed it when we were able to do so according to VMware vulnerability disclosure requirements.

That problem you have with a vendor on 5.14? Sorry, that's not our job. We are not paid by that vendor. In fact, that vendor might as well use open source RabbitMQ without a support contact and thus might get everything, including updates, for free, year after year.

And now we have to worry about their upgrade routine and security vulnerability scanner? Wow, the standards are high for OSS maintainers these days.