openHAB version: Attempting install of 3.2 using “dnf install openhab”
Issue of the topic:
Hi,
I preface this with the fact I’m not a Linux expert, but have “entry level” experience with CentOS.
I’m looking to understand if OpenHAB 3 is supported on CentOS 9 Streams.
The documentation seems to suggest it is, however when attempting to install OpenHAB 3 using the jfrog repository (JFrog) I’m getting an error.
The following is the output following the installation of the GPG key which is done by dnf.
Key imported successfully
Import of key(s) didn’t help, wrong key(s)?
Problem opening package openhab-3.2.0-1.noarch.rpm. Failing package is: openhab-3.2.0-1.noarch
GPG Keys are configured as: https://openhab.jfrog.io/artifactory/api/gpg/key/public
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing ‘dnf clean packages’.
Error: GPG check FAILED
I have also attempted to attach a screenshot of the full command and output. The key seems to have been imported successfully. While I’m not familiar with this error it seems there could be a problem with the key.
All I can say is it’s supposed to work. MAybe the GPG key expired or something like that. If the problem persists open an issue on the openhab-distro repo. How to file an Issue
In the mean time, I’d recommend following the manual installation instructions, or if you want to learn something else new Docker.
I went back and tried the installation on a different distro (something other than CentOS Streams) and this issue did not occur. It seems this may be something specific to CentOS Streams.
I was able to successfully install OpenHAB 3 on both Rocky and ALMA without issue.
My guess is there is something up with CentOS Streams.
I attached a screenshot of the successful outcome.
I’m going to take the advice of those who suggest looking at Docker and give that a try.
I believe this is due to the fact the CentOS Stream 9 disables SHA-1 signature verification on GPG keys by default. The key imports fine in CS9, but the verification fails as SHA-1 is considered insecure. See this bug for details. It’s only a matter of time before this gets to more distros, so I would suggest the package maintainer update the signing method to use a more secure signature hash.
You can install OH3 on CentOS 9 by disabling the GPG key check in the yum.repos.d config file:
Thanks for reporting it, I’m looking into this now - the upstream libraries have changed to support SHA256 and I have merged these with my workaround to support larger keys.
Current RPM packages:
openhab-3.3.0-1.noarch.rpm:
Header V4 RSA/SHA1 Signature, key ID a224060a: OK
Header SHA1 digest: OK
V4 RSA/SHA1 Signature, key ID a224060a: OK
MD5 digest: OK
Initial tests with a local dummy key seem good:
openhab-3.3.0-1.noarch.rpm:
Header V4 RSA/SHA1 Signature, key ID 6cf32def: OK
Header SHA256 digest: OK
Header SHA1 digest: OK
Payload SHA256 ALT digest: OK
Payload SHA256 digest: OK
V4 RSA/SHA1 Signature, key ID 6cf32def: OK
MD5 digest: OK
It’s only changes to the signing method, so we don’t need to change the key that we use we may also have to change the key if the crypto policies do not allow the RSA/SHA1 signature at all. There were a large number of unrelated changes to the 3rd party plugins so I need to test if the packages generated work in the same way (and are compatible with older packages on upgrade).
Not as successful as I’d hoped… my test on an Centos9 Stream build still reports a bad signature with the updated libraries (which I should have probably expected since the signature method didn’t actually change in my above post).
openhab-3.3.0-1.noarch.rpm:
warning: Signature not supported. Hash algorithm SHA1 not available.
warning: Signature not supported. Hash algorithm SHA1 not available.
Header V4 RSA/SHA1 Signature, key ID 82573a7c: BAD
Header SHA256 digest: OK
Header SHA1 digest: OK
Payload SHA256 ALT digest: OK
Payload SHA256 digest: OK
V4 RSA/SHA1 Signature, key ID 82573a7c: BAD
MD5 digest: OK
But resigning with RPMs own tools (rpm --resign) using the same key is valid:
openhab-3.3.0-1.noarch.rpm:
Header V4 RSA/SHA512 Signature, key ID 82573a7c: OK
Header SHA256 digest: OK
Header SHA1 digest: OK
Payload SHA256 ALT digest: OK
Payload SHA256 digest: OK
MD5 digest: OK
I don’t understand why this is the case - so it may take a while for me to have a look at what’s happening here but at the moment @jeremyrumpf 's suggestions above work as a temporary measure.