rabbitmq-server/release-notes/3.8.18.md

8.6 KiB

RabbitMQ 3.8.18

RabbitMQ 3.8.18 is a maintenance release that includes a security patch.

This release addresses an undisclosed vulnerability with CVSS 3.1 score of 3.1 (low): CVE-2021-32719

Our team would like to thank Fahimhusain Raydurg for responsibly disclosing the vulnerability and Patrik Ragnarsson from CloudAMQP for contributing a fix.

Obtaining Packages

RabbitMQ releases are distributed via GitHub, Cloudsmith, and PackageCloud.

Erlang/OTP Compatibility Notes

This release requires Erlang 23.2 and supports Erlang 24.

Provisioning Latest Erlang Releases explains what package repositories and tools can be used to provision modern Erlang versions.

Upgrade and Compatibility Notes

See the Upgrading guide for general documentation on upgrades and RabbitMQ change log for release notes of other releases.

If upgrading from a3.7.x release, see 3.8.0 release notes upgrade and compatibility notes first.

If upgrading from a 3.6.x or older release series, first upgrade to 3.7.27 and then to this version.

Getting Help

Any questions about this release, upgrades or RabbitMQ in general are welcome on the RabbitMQ mailing list and RabbitMQ community Slack.

Changes Worth Mentioning

Core Server

Enhancements

  • Peer discovery no longer uses randomized delays to avoid the inherent race condition during initial cluster formation. Instead it relies on an internal distributed locking mechanism available in modern Erlang releases.

    While randomized startup delay was reasonably effective at ensuring only one cluster was formed even during parallel node startup, it by definition assumes that with some low probability more than one node can still start as seed nodes, and be joined by different groups of cluster peers. The locking mechanism does not have this downside. Now that RabbitMQ requires Erlang 23.2, the internal locking library becomes an option for peer discovery. Note that etcd and Consul-based peer discovery still use those service's support for distributed locks.

    cluster_formation.randomized_startup_delay_range.min and cluster_formation.randomized_startup_delay_range.max configuration keys will no longer have any effect.

    GitHub issue: #3075

  • Node startup banner now includes Erlang version, runtime operation mode (JIT vs. emulator), and underlying crypto library version (e.g. OpenSSL 1.1.1k) it was built against.

    GitHub issue: #2777

  • Build system targets now use hostname(1) in a way that is compatible with Solaris.

    Contributed by Pavel @tropikhajma Heimlich.

    GitHub issue: #3117

Bug Fixes

  • Queue deletion could run into an exception in some rare cases.

    Contributed by @tomyouyou.

    GitHub issue: #3086

Prometheus Plugin

Bug Fixes

  • In certain double stack (IPv4 and IPv6) environments, the plugin would start a single listener but register two internally. That extra non-existent listener would make rabbitmq-diagnostics drain fail as it disables all registered listeners.

    GitHub issue: #3021

Management Plugin

Bug Fixes

  • In certain double stack (IPv4 and IPv6) environments, the plugin would start a single listener but register two internally. That extra non-existent listener would make rabbitmq-diagnostics drain fail as it disables all registered listeners.

    GitHub issue: #3021

Kubernetes Peer Discovery Plugin

Enhancements

  • Kubernetes peer discovery mechanism no longer uses randomized delays to avoid the inherent race condition during initial cluster formation. Instead it relies on an internal distributed locking mechanism available in modern Erlang releases.

    While randomized startup delay was reasonably effective at ensuring only one cluster was formed even during parallel node startup, it by definitely assumes that with some low probability more than one node can still start as seed nodes, and be joined by different groups of cluster peers. The locking mechanism does not have this downside. Now that RabbitMQ requires Erlang 23.2, the internal locking library becomes an option for peer discovery.

    cluster_formation.randomized_startup_delay_range.min and cluster_formation.randomized_startup_delay_range.max configuration keys will no longer have any effect.

    GitHub issue: #3075

AWS Peer Discovery Plugin

Enhancements

  • AWS peer discovery mechanism no longer uses randomized delays to avoid the inherent race condition during initial cluster formation. Instead it relies on an internal distributed locking mechanism available in modern Erlang releases.

    While randomized startup delay was reasonably effective at ensuring only one cluster was formed even during parallel node startup, it by definitely assumes that with some low probability more than one node can still start as seed nodes, and be joined by different groups of cluster peers. The locking mechanism does not have this downside. Now that RabbitMQ requires Erlang 23.2, the internal locking library becomes an option for peer discovery.

    cluster_formation.randomized_startup_delay_range.min and cluster_formation.randomized_startup_delay_range.max configuration keys will no longer have any effect.

    GitHub issue: #3075

Federation Plugin

Bug Fixes

  • Queue federation will now declare queues on the upstream side only if it does not already exist. This makes it possible to federate pre-declared queues of different types.

    Note that such setups should be considered edge cases. Queue federation was never meant to federated queues of different types under the same name in different clusters. Such setups could be useful in Blue/Green deployment upgrade scenarios but otherwise should be avoided.

    GitHub issue: #3107

AuthN/AuthZ Backend HTTP Plugin

Bug Fixes

  • auth_http.connection_timeout and auth_http.request_timeout are two new configuration parameters that control HTTP client connection and overall request timeouts. They both default to 15 seconds. The value can be increased for services that can occasionally slow down significantly.

    Contributed by Miłosz @SzumiecM Szumiec.

    GitHub issue: #3140

Dependency Upgrades

Source Code Archives

To obtain source code of the entire distribution, please download the archive named rabbitmq-server-3.8.18.tar.xz instead of the source tarball produced by GitHub.