rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch not working on centOS stream. gives a key import error.

[ingenium21]

Elasticsearch Version

doesn't matter

Installed Plugins

none

Java Version

bundled

OS Version

5.14.0-75.el9.x86_64 #1 SMP PREEMPT Sat Mar 26 08:10:05 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Problem Description

I am trying to install elasticsearch in a centOS stream using rpm and following elastic's own directions.
When I try to import the gpg key using rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch I get a 'key 1 import failed' error. using -v doesn't give me anything useful either.

Steps to Reproduce

rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch

Logs (if relevant)

No response

[elasticmachine]

Pinging @elastic/es-delivery (Team:Delivery)

[breskeby]

@ingenium21 which elasticsearch version did you try to install?

[ingenium21]

Newest version, but I couldn't even get to that part as importing the keys failed

[breskeby]

ah I see

[ingenium21]

I was able to get around it by change gpgcheck=1 to gpgcheck=0 in the elasticsearch.repo file. But yes, ideally I would like to be installing applications with a valid gpg check.

[breskeby]

Thanks again for bringing this up. I think what we see is an issue introduced by rpm-software-management/rpm#1788

[ingenium21]

No problem. Happy to support such a cool product. 👍

[cisco-abrandel]

Seeing the same issue on Alma 9, and I believe you are correct in that changes to RPM are causing this.

[nerijus]

A workaround on CentOS 9 is to run update-crypto-policies --set LEGACY.

[cisco-abrandel]

Thanks for the tip, thats a better workaround than disabling GPG checks entirely

[ingenium21]

oh nice. Thanks Nerijus for the tip!

…

On Wed, Jun 8, 2022 at 11:06 AM Anthony Brandelli ***@***.***> wrote: Thanks for the tip, thats a better workaround than disabling GPG checks entirely — Reply to this email directly, view it on GitHub <#85876 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADSSPQJRDSPCCK5CI2MH6MDVODAHXANCNFSM5TLNIBUA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[hrw]

Will something happen here or should we just mark ELK stack as dead on RHEL9 family of systems?

[mark-vieira]

I'm reaching out to our release engineering team to get a status update on this. We should be able to update the signing key to sort out this problem.

[hrw]

@mark-vieira so how it went?

[mark-vieira]

We're trying to figure out what exactly needs to be done here. It seems you cannot remove SHA-1 as a supported algorithm from a PGP key. It's actually mandatory according to the spec. I think the issue is the actual signature of the key itself, which implies we'll have to generate a new one and that has the potential to be disruptive for existing users. We're looking at how to sort this out in a backwards-compatible way.

[hrw]

Not tried, but maybe this can help: https://old.nixaid.com/gpg-migration-sha1-to-sha2/ a bit?

Other idea: what about creating second key (modern one) and use it for signing rhel9 repo first (as you lack them anyway) and choose a date to switch old repos to a new key?

[jameswiggins]

I'm having the same problem installing logstash on Rocky Linux 9. The workaround from a redhat.com blog post:

1. As @nerijus mentioned, switch to legacy crypto policy: update-crypto-policies --set LEGACY OR Explicitly allow SHA-1: update-crypto-policies --set DEFAULT:SHA1
2. Install whatever you need. I need to install logstash so: dnf install logstash
3. Switch back: update-crypto-policies --set DEFAULT

[ingenium21]

Thanks james. I was considering moving to Rocky Linux 9 recently. good to know it's happening there too.

[hrw]

It is problem on each RHEL9 rebuild. Alma Linux, Rocky Linux, Euro Linux etc.

[inputvalidation]

Checking in to see if this is still progressing? We have customers where we can't disable or allow SHA1 anymore due to security policies.

[ingenium21]

The fix isn't really a fix but rather a workaround and I believe just disables the security or installs with a less secure GPG key.

[Nirjonadda]

Do you have any plan add support for AlmaLinux OS 9? Can not install Elasticsearch in AlmaLinux OS 9 because RPM signing key is invalid.

[ingenium21]

Once they fix the issue with RPM, it should work with all distros that use RPM

…

On Thu, Jul 20, 2023, 4:24 PM Nirjonmela Desi Forum < ***@***.***> wrote: Do you have any plan add support for AlmaLinux OS 9? Can not install Elasticsearch in AlmaLinux OS 9 because RPM signing key is invalid. — Reply to this email directly, view it on GitHub <#85876 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADSSPQJR4Y4HIYFG4S5B2QDXRGOXJANCNFSM5TLNIBUA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[keys1234249]

Bump it would be great to not have to use workarounds to install this key in EL9 systems.

[ronald-den-otter]

SHA1 is not advisable since 2014 something. Why didn't elasticsearch wakeup. Packages need to be resigned. Switching to legacy is the wrong way in my opinion

[Nirjonadda]

This issue created in Apr 13, 2022 but still no fix happened after more 1 years now.

[chrisberkhout]

@elastic/release-eng Here's a way to fix the SHA1 signatures without migrating to a new key:
https://github.com/chrisberkhout/sha1-key-fix/blob/master/SHA1KeyFix.ipynb

[ronald-den-otter]

Thinks this is more the way : https://access.redhat.com/solutions/185173
summarized:
gpg --gen-key
gpg -a --export KEYID > /root/CUSTOMER-GPG-KEY
~/.rpmmacros
%_signature gpg
%_gpg_name KEYID
rpm --resign rpmname.rpm

And share GPG-KEY and resigned RPM in new repository

[tr0k]

Hello, is there any plan to fix this issue? We need a manual workaround when installing the RPMs in our RHEL9 hosts. That would be very much appreciated.

[alpar-t]

We're working on a solution and hope to have something soon.

[mmoser-aires]

@alpar-t ,

As @ronald-den-otter pointed out, via this article (Which is dated over 3 years ago...) just resign the packages.

Rotating GPG keys/resigning packages does not require a new product release, you just have to generate a new gpg private key using modern algorithms, resign the packages and publish the public key.

From your side all you have to do is:

gpg --gen-key
gpg -a --export KEYID > RPM-GPG-KEY-ELASTICSEARCH
for i in `ls *.rpm`;do rpm --resign $i;done
cp  RPM-GPG-KEY-ELASTICSEARCH /var/www/html/   # Or wherever your document root is for https://artifacts.elastic.co/

Update your documentation to include the new URL to the new key along with the following command:

rpm -e gpg-pubkey-d88e42b4-52371eca

The above could actually be part of the a minor rpm release to install the new and remove the old for an unattended/automatic update.

GPG key rotation does not require a new release of your software, package distributors rotate GPG keys all of the time, nVidia regular resigns for security purposes. Making this fix contingent on your next software release is a self imposed restriction for a problem that RedHat provided guidance for 3 years ago and this github issue has been open since April of 2022...

Can we please get these packages updated soon?

[mcarifio]

Problem appears in Rocky Linux 9.2 with elasticsearch-8.10.1. https://www.redhat.com/en/blog/rhel-security-sha-1-package-signatures-distrusted-rhel-9 and the comments above provide more context.

[alpar-t]

We just updated https://artifacts.elastic.co/GPG-KEY-elasticsearch to have a signature that works on RHEL 9 and similar. Note that this only changes the algorithms that were problematic and is not a key rotation. Thanks to @chrisberkhout for the suggestion.

[ghen2]

If you still have the old key installed (and any package matching it), rpm will still complain about SHA-1 on every invocation. After installing the new key, you should explicitly remove the old one from the RPM db: rpm -e gpg-pubkey-d88e42b4-52371eca