Please switch to Package Cloud apt repository; rabbitmq.com's one becomes read-only in a few months

[michaelklishin]

This module currently uses Package Cloud for RHEL-based distributions and rabbitmq.com apt repo for Debian-based ones.

Team RabbitMQ plans to stop publishing new releases to rabbitmq.com in a few months (note: existing packages won't be removed). 3.7.0 will
be distributed via Bintray, GitHub, and Package Cloud. It would be great if this module was updated
to use those three ahead of the 3.7.0 release in late November.

[wyardley]

@michaelklishin Thanks for the heads up. I'm happy to update apt to use packagecloud when repos_ensure is set (keep in mind that it's disabled by default, so the module's default behavior is to use the vendor package).

Is this how we'd want the resulting repo to look on Ubuntu 16?

deb https://packagecloud.io/rabbitmq/rabbitmq-server/ubuntu xenial main

Also, will the signing key [for the package itself, vs. the repo, which I think uses https://packagecloud.io/rabbitmq/rabbitmq-server/gpgkey] continue to be at:
https://www.rabbitmq.com/rabbitmq-release-signing-key.asc

Thanks for the heads up.

[wyardley]

@michaelklishin I created #641. This will probably get merged soon, but let me know if you have any feedback, especially anything in regards to whether signing practices will remain the same.

[michaelklishin]

@wyardley I think for the cases of vendor (distribution?) provided packages nothing should change. The signing key on rabbitmq.com isn't going anywhere, as won't existing packages. Note that Package Cloud repositories use their own, PC-provided signing keys. It's a good question how we should go about this.

Our key is also available from Bintray. To my knowledge we can't just add an arbitrary key to a repo, or an arbitrary file to our account.

Would Bintray work for the key? Or should we create a GitHub repo for public keys?

[wyardley]

@michaelklishin
I will have to check again, but my memory from when I added the packagecloud repo for yum is that the repo metadata is signed by packagecloud, but the package itself is still signed with the RabbitMQ signing key; in my brief testing with apt, it seemed as if that was true as well (if you think only the PC key is sufficient, I can try using that one only).

Separately, there has been discussion about the safest way of including the key -- in the module, via a site unconnected to the package source, and so on.
Currently, we import both the RabbitMQ signing key (via the one on the RabbitMQ site, but user-overridable) and the Packagecloud key (currently done via key ID + pgp keyservers).

[wyardley]

@michaelklishin I stand corrected -- for Ubuntu, with only the packagecloud key, the 3.6.12 package seems to install cleanly. So I think we can rework this a little bit.

However, with RHEL, it seems to still be using the RabbitMQ signing key (which is what we've been using even since I switched to the packagecloud repo)?

 Failing package is: rabbitmq-server-3.6.12-1.el7.noarch
 GPG Keys are configured as: https://packagecloud.io/gpg.key
Error: /Stage[main]/Rabbitmq::Install/Package[rabbitmq-server]/ensure: change from purged to present failed: Execution of '/bin/yum -d 0 -e 0 -y install rabbitmq-server' returned 1: warning: /var/cache/yum/x86_64/7/rabbitmq_rabbitmq-server/packages/rabbitmq-server-3.6.12-1.el7.noarch.rpm: Header V4 RSA/SHA512 Signature, key ID 6026dfca: NOKEY
Public key for rabbitmq-server-3.6.12-1.el7.noarch.rpm is not installed
[root@centos-7-x64 ~]# rpm -q gpg-pubkey --qf '%{name}-%{version}-%{release} --> %{summary}\n'  | grep package
gpg-pubkey-d59097ab-52d46e88 --> gpg(packagecloud ops (production key) <ops@packagecloud.io>)

So for now, I'll use the old signing key for yum, and the new for apt?

[wyardley]

I'm going to close this one for benefit of being in the right place in the Changelog... but, please do keep us up to date, and if the rpm packages switch to using the same signing key, we may need to make some adjustments. Having a mix of signing keys within the same repo may also cause problems, since the module does allow users to specify a specific version.