elasticsearch
elasticsearch copied to clipboard
elastic
rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch not working on centOS stream. gives a key import error.
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
Newest version, but I couldn't even get to that part as importing the keys failed
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.
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
Seeing the same issue on Alma 9, and I believe you are correct in that changes to RPM are causing this.
Thanks for the tip, thats a better workaround than disabling GPG checks entirely
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: @.***>
Will something happen here or should we just mark ELK stack as dead on RHEL9 family of systems?
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.
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.
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?
I'm having the same problem installing logstash on Rocky Linux 9. The workaround from a redhat.com blog post:
- As @nerijus mentioned, switch to legacy crypto policy:
update-crypto-policies --set LEGACYOR Explicitly allow SHA-1:update-crypto-policies --set DEFAULT:SHA1 - Install whatever you need. I need to install logstash so:
dnf install logstash - Switch back:
update-crypto-policies --set DEFAULT
Thanks james. I was considering moving to Rocky Linux 9 recently. good to know it's happening there too.
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.
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.
Can you dual publish the RPMs? It's not disruptive for existing OS and it's already an issue with new OS.
Like @Sxderp wrote: make separete distro for EL9 family with separate gpg key.
Those on EL7/8 will use old SHA1 one, EL9 users will get new one.
Everything works for everyone.
anyway we stopped using elasticsearch in favour of opensearch so I am unsubscribing
same issue on ubuntu:22.04
Replication:
docker run -it --rm --name bob1 ubuntu:22.04 /bin/bash
apt-get update
apt-get -y install apt-transport-https ca-certificates curl gnupg
echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/8.x/apt stable main" | tee /etc/apt/sources.list.d/elastic-8.x.list
curl -L https://artifacts.elastic.co/GPG-KEY-elasticsearch |apt-key add -
apt-get update && apt-get -y install elasticsearch
Result:
W: GPG error: https://artifacts.elastic.co/packages/8.x/apt stable InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY D27D666CD88E42B4
E: The repository 'https://artifacts.elastic.co/packages/8.x/apt stable InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
We intend on generating a new signing key for these artifacts that will be used for future versions of Elastic stack releases.
We intend on generating a new signing key for these artifacts that will be used for future versions of Elastic stack releases.
Is there an ETA on this? I have package requirements in an enterprise environment where update-crypto-policies --set FIPS:OSPP is mandatory and rpm signatures are validated through STIG's. None of the aforementioned "work arounds" are acceptable in enterprise environments with audit/governance requirements.
Elasticsearch for 8.x 7.6 kB/s | 1.8 kB 00:00
Importing GPG key 0xD88E42B4:
Userid : "Elasticsearch (Elasticsearch Signing Key) <[email protected]>"
Fingerprint: 4609 5ACC 8548 582C 1A26 99A9 D27D 666C D88E 42B4
From : https://obfuscated.com/katello/api/v2/repositories/25/gpg_key_content
warning: Signature not supported. Hash algorithm SHA1 not available.
Key import failed (code 2). Failing package is: auditbeat-8.6.1-1.x86_64
GPG Keys are configured as: https://obfuscated.com/katello/api/v2/repositories/25/gpg_key_content
Public key for filebeat-8.6.1-x86_64.rpm is not installed. Failing package is: filebeat-8.6.1-1.x86_64
GPG Keys are configured as: https://obfuscated.com/katello/api/v2/repositories/25/gpg_key_content
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'yum clean packages'.
We intend on generating a new signing key for these artifacts that will be used for future versions of Elastic stack releases.
@mark-vieira we've got some other customers asking for the same update on the signing key. Any idea of when this may occur?
I don't have an estimate on which release this will be targeted for at this time.