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 https://github.com/rpm-software-management/rpm/pull/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 https://github.com/elastic/elasticsearch/issues/85876#issuecomment-1150112807, 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.