Control: tag -1 moreinfo Hi,
On Tue, Nov 29, 2022 at 10:12:20PM -0500, Alex Vandiver wrote: > 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 That probably needs doing then, and a revised debdiff proposing. I get the impression this bug is languishing because everybody is waiting for each other... Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
