Releases: sign version tags in addition to release artifacts

[carlsmedstad]

Is your feature request related to a problem? Please describe.

We recently started building the Arch Linux package for RabbitMQ from the Git repository instead of the released source archives, e.g. rabbitmq-server-4.0.5.tar.xz. Unfortunately this means we no longer verify the source with the release key, as tags in the repository are unsigned.

The goal for this change was to:

• Be able to run some tests. Upstream tests, even a limited subset of them, are a great way for us to detect issues and incompatibilities in our packages.
• Use a more transparent source (see candidate RFC0046), i.e. build straight from the source instead of from an archive that was generated out of our control.

Describe the solution you'd like

As far as I understand, the release process (and signing) is currently manual, as described by SERVER_RELEASES.md. Adding the following step to the process would ensure tags are signed in addition to released artifacts:

git tag -s v$version -u 0A9AF2115F4687BD29803A206B73A36E6026DFCA -m "Release v$version"
git push --tags

Describe alternatives you've considered

Including the tests in the released and signed source archives would also allow us to run tests in our package build, while only relying on signed sources.

Additional context

No response

[carlsmedstad]

CC @anthraxx

[michaelklishin]

@carlsmedstad your understanding is incorrect. The process is not manual and has not been manual for over a decade. The outdated file describes the Make target that were relevant a while ago.

Open source RabbitMQ releases are produced on GitHub Actions.

[michaelklishin]

The tags are already signed according to GitHub. This is the case even for the alpha builds.

I don't think we have any interest in shipping tests with the source tarball. RabbitMQ has just turned 18 and this is the first time I see someone asking for tests. You can get them by checking out a tag, they have a fairly straightforward mapping to version numbers.

You can run N client test suites, we have a double digit number of libraries that our team alone maintains.

You can add rabbitmqadmin v2 or PerfTest or Stream PerfTest suites on top.

[michaelklishin]

@carlsmedstad we are not going to re-create older releases and re-tag them, I'm sorry.

4.0.5 was released using the (virtually) open source infrastructure you can inspect (except for the secrets and keys). Older releases were built using completely closed source infra we no longer use and are not going back to.

4.0.6 has just been built by the same infrastructure.

[michaelklishin]

Now I see what GitHub reports with its signing ✅ checkmark: it's the GPG key of the account whose PAT (token) was used
to sign the release.

We do sign artifacts with our standard key and that's why this question has not come up, most of our users use binary packages.

In order to sign it with the standard key I'd need to see how that can be configured in the GH action we use, or we would have to use another token belonging to rabbitmq-ci that would have only that key.

I don't have an ETA on this, outside of a few very large users who build RabbitMQ from source for all kinds of reasons, this is simply not something most users need.

[michaelklishin]

On the positive side, while you @carlsmedstad do not have access to the token, you do have access to everything else (except for the next version stored in a GH org variable), so you can at the very least see what exactly happens during the build process in:

• rabbitmq/build-env-images
• rabbitmq/server-packages

I am not against changing the signing key for the commit and tag but it is difficult to justify making this a priority.

Same with rotating the key. Currently my key is used, which is not great but also gives you a good enough indication of provenance.

Any specific suggestions in rabbitmq/server-packages are welcome, in fact, you can even submit a PR there, even though I wouldn't have an easy way for you to test it.

[anthraxx]

@carlsmedstad we are not going to re-create older releases and re-tag them, I'm sorry.

No worries here, we explicitly do not expect to change tags retrospectively. We are just trying to get a buy-in for a consistent solution for future tags. We do understand this is not your highest priority, and we are very grateful for your lengthy explanations and discussions trying to find a consensus: thank you.

[michaelklishin]

@anthraxx thank you. I will investigate what the action we use has to offer in terms of tag signing, my experience suggests that producing releases on actions is less of a solved problem that one would expect.

Having shipped 4.0.6 today we can go back to actively working on rabbitmq/server-packages again, swap tokens, and so on.