On Sat, 2022-01-29 at 22:53 +0100, Thomas Goirand wrote: > On 1/29/22 20:31, Salvatore Bonaccorso wrote: > > Control: tags -1 + moreinfo > > > > Hi Thomas, > > > > On Sat, Jan 29, 2022 at 07:55:15PM +0100, Thomas Goirand wrote: > > > My appologies for opening a new bug. I didn't realize #1002956 > > > was still > > > pending my input. I merged both bugs. > > > > > > Please see, attached to this message, the new debdiff, adding the > > > fix for > > > CVE-2021-22116 as well. > > > > See my comment from > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002956#10 . > > Isn't > > the the debian/patches/series missing the listing of > > CVE-2021-32718_Escape_username_before_displaying_it.patch to > > actually > > apply the patch? > > > > Regards, > > Salvatore > > Correct, fixed, thanks and sorry for the mistake. >
+ * 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. + 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? Regards, Adam