On Sat, 06 Aug 2022 19:09:05 +0100 "Adam D. Barratt" <a...@adam-barratt.org.uk> wrote: > + * Stop moving mv /etc/rabbitmq/rabbitmq.conf > /etc/rabbitmq/rabbitmq-env.conf. > > This could do with an explanation as to _why_ this move should not be > happening.
I believe this is https://bugs.debian.org/943699 > + if ! [ -e /var/lib/rabbitmq/.erlang.cookie ] ; then > + OLD_UMASK=$(umask) > + umask 077; openssl rand -base64 -out > /var/lib/rabbitmq/.erlang.cookie 42 > + umask ${OLD_UMASK} > + else > + # This matches an Erlang generated cookie file: 20 upper case > chars > + if grep -q -E '^[A-Z]{20}$' /var/lib/rabbitmq/.erlang.cookie > ; then > + OLD_UMASK=$(umask) > + umask 077; openssl rand -base64 -out > /var/lib/rabbitmq/.erlang.cookie 42 > + umask ${OLD_UMASK} > + if [ ""$(ps --no-headers -o comm 1) = "systemd" ] ; > then > + if systemctl is-active --quiet > rabbitmq-server.service ; then > + systemctl restart > rabbitmq-server.service > [...] > +Since 3.9.8-3, the rabbitmq-server node will use openssl to generate a > +cryptographically-secure cookie during first installation, mitigating > +this vulnerability. > + > +Servers which installed a prior version, and are upgrading to 3.9.8-3 > +or higher, ARE STILL VULNERABLE, as the package will not regenerate > +the secret if it exists already. This is because the secret is > +designed to be shared between nodes in a cluster, and thus > +regenerating it would break existing clusters. > > This seems to be inaccurate. The latter block quoted above specifically > *does* regenerate an existing secret if it deems it to be not "good > enough", so far as I can tell? The README.debian changes are out of date with the code, yes. The warnings in README.debian, I believe, date from when that documentation was a compromise solution, rather than fixing existing weak magic cookies. Since the code now does address those, the README should be updated accordingly. The changelog might also merit a warning that this may break clustered installs which share a weak magic cookie, similar to the note in the initial mail of https://bugs.debian.org/1004513 - Alex
