RabbitMQ uninstall.exe is not digitally signed

[ophirzk]

Hi,

The RabbitMQ installer, rabbitmq-server.exe, is signed by VMWare but uninstall.exe is not signed.

That can cause the uninstall.exe to be blocked from executing and might expose RabbitMQ users in Windows to attacks that pretend they are RabbitMQ's uninstall.exe.

Can the uninstall.exe be signed the same way as the installation exe is signed?

Version checked: 3.10.8.

[michaelklishin]

You are welcome to contribute any relevant changes to the installer. I do realize there may be changes necessary in the release pipeline but everything else is open source.

[ophirzk]

I assumed that there should be changes only in the release pipeline and not in the code.

There should be changes in the installer as well?

[michaelklishin]

@ophirzk I don't know, you are welcome to investigate this

[lukebakken]

Unfortunately this is not easily solved. We sign the .exe installer using osslsigncode as part of our Linux-based packaging process.

The NSIS installer file specifies that uninstall.exe is written at install time here: link

Here are the relevant docs for signing an un-installer:

• https://nsis.sourceforge.io/Signing_an_Uninstaller
• https://nsis.sourceforge.io/Docs/Chapter5.html#uninstfinalize

Neither of those processes will work given our current pipeline. I honestly don't think it's worth the effort. I'll leave this issue open for a few days in case anyone else wants to chime in.

[ophirzk]

@lukebakken Can you please elaborate more on why it won't work with the current pipeline?

I think it is worth solving, there is no reason to have the uninstall.exe unsigned especially when the installer is signed, and in Linux, everything is signed. Windows should not be different.

[lukebakken]

Can you please elaborate more on why it won't work with the current pipeline?

The code is private, so I can't share it. But the installer is built on Linux. To "pre-create" the "uninstall.exe" file (https://nsis.sourceforge.io/Signing_an_Uninstaller), we would have to figure out how to run the installer on Windows, and then package up the signed uninstall file.

The second option, using !uninstfinalize won't work because we'd have to ship our signing cert and key with the installer.

If we had even one RabbitMQ customer who paid for a license we'd consider this, but as of now no paying customers have even noticed that uninstall.exe is not signed. This is probably due to the fact that the general practice of NSIS installers is to write the uninstall.exe file at install-time. Since you trust the installer you should then trust the generated uninstall.exe file.

[inikulshin]

Hi @lukebakken

I'm 100% sure that !uninstfinalize and !finalize commands do not require to ship any cert or key with the installer.

According to the !uninstfinalize documentation, you should just run the same command you use to sign rabbitmq-server.exe after running make on Makefile.

[inikulshin]

@lukebakken what do you mean by "ship"?

If you run this command in !uninstfinalize/!finalize (with different -in and -out), it will not cause crt/key to be included in the rabbitmq-server-$VERSION.exe. Its content is configured by nsi file...

Maybe you mean that crt/key files can't be added to version control (git)? Ok, but you can just write a simple script that executes osslsigncode conditionally, only if crt/key files are present in the predefined location. And to execute this script in !uninstfinalize/!finalize. (And maybe also to add target with this script in Makefile, after the makensis, instead of separate build step).

This way the build (make) will work without signing by default, but once you put crt/key in the predefined location before build, like you do now, everything will be signed.

[lukebakken]

I misunderstood the documentation. I thought that !uninstfinalize was run during the installation of the .exe file, instead of when it's being built.

We'll take a look at changing the CI pipeline to accommodate this, but it's not high priority.

[inikulshin]

@lukebakken np, thanks.

Meanwhile I can create a PR with a necessary changes.

I think, the best is !uninstfinalize 'if exist sign.bat sign.bat "%1"' or similar. This way you shouldn't expose anything related to signing. Just implement sign.bat and copy it before making the installer.

However, !uninstfinalize is added to makensis since 3.08 only. Do you already have it? Last time is was v3.06.1-1.

[lukebakken]

The .exe installer is built on Linux, not Windows, and the code is private. You won't be able to create a PR for that. Creating a PR for the NSIS input file is the least of our worries 😉

We'll get to this issue when we have time.

We still only have NSIS 3.06.1 available as well, which will complicate things.

[inikulshin]

I'm not familiar with Debian, but it looks like nsis 3.08 is available as testing/unstable: https://tracker.debian.org/pkg/nsis I don't know if it's relevant...

[ophirzk]

@lukebakken in what version is it planned to be addressed?

[lukebakken]

in what version is it planned to be addressed?

There is no plan at this time. If someone with a RabbitMQ support contract requests it be prioritized, then it will move up. Otherwise, we're all very busy working on higher priority items.

[ophirzk]

@lukebakken any news regarding siginig the uninstall.exe?

[michaelklishin]

@ophirzk Luke's comment from May 30 still stands

[lhoguin]

For what it's worth, OTP team were not convinced and closed the companion to this ticket: https://github.com/erlang/otp/issues/7002

To move this forward I would recommend convincing the Erlang/OTP team to sign their uninstall.exe, since RabbitMQ depends on Erlang/OTP. This issue can only be fully resolved when both Erlang/OTP and RabbitMQ have their uninstall.exe signed.

[IngelaAndin]

You would have to explain the perceived problem in much more detail. What tool is it that cause the uninstaller to be blocked, and why is this our problem?