-
Notifications
You must be signed in to change notification settings - Fork 575
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ability to specify maximum message size #1062
Comments
To avoid OOM with a very large message. The default value is 64 MiB. Fixes #1062
The releases list and the commit history both show that the fix was backported to: @acogoluegnes Can you confirm? I want confirmation because 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? |
@gdimitrov7 you can inspect the branches of those releases just like we can, here is 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. |
@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. |
@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. |
@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. |
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. |
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....
|
@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. |
No description provided.
The text was updated successfully, but these errors were encountered: