# Encountering the problem with Google Linux Signing keys
When I try to install new Google Linux Signing keys in Fedora 37 (with the
latest stable release of ``rpm``, namely 4.18.1), it fails. However, when I
delete the old (pre-installed) keys, and try again, it works. Here is what I
typed:
```
wget https://dl.google.com/linux/linux_signing_key.pub
sudo rpm --import linux_signing_key.pub
rpm -qi gpg-pubkey-d38b4796-* | gpg --show-keys --with-subkey-fingerprint
rpm -qa gpg-pubkey* --qf '%{NAME}-%{VERSION}-%{RELEASE} %{PACKAGER}\n' | grep
'[email protected]' | sed 's/ .*$//' | sudo xargs rpm -e
sudo rpm --import linux_signing_key.pub
rpm -qi gpg-pubkey-d38b4796-* | gpg --show-keys --with-subkey-fingerprint
```
Here is the output. Notice that the first attempt at importing the keys fails
silently, whereas the second attempt (after deleting old keys) succeeds.
```
[user@disp8080 ~]$ wget https://dl.google.com/linux/linux_signing_key.pub
--2023-07-21 23:26:12-- https://dl.google.com/linux/linux_signing_key.pub
Resolving dl.google.com (dl.google.com)... 142.250.178.14,
2a00:1450:4009:81f::200e
Connecting to dl.google.com (dl.google.com)|142.250.178.14|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 14605 (14K) [application/octet-stream]
Saving to: ‘linux_signing_key.pub’
linux_signing_key.p 100%[===================>] 14.26K --.-KB/s in 0s
2023-07-21 23:26:14 (43.0 MB/s) - ‘linux_signing_key.pub’ saved [14605/14605]
[user@disp8080 ~]$ sudo rpm --import linux_signing_key.pub
[user@disp8080 ~]$ rpm -qi gpg-pubkey-d38b4796-* | gpg --show-keys
--with-subkey-fingerprint
gpg: directory '/home/user/.gnupg' created
gpg: keybox '/home/user/.gnupg/pubring.kbx' created
pub rsa4096 2016-04-12 [SC]
EB4C1BFD4F042F6DDDCCEC917721F63BD38B4796
uid Google Inc. (Linux Packages Signing Authority)
<[email protected]>
sub rsa4096 2016-04-12 [S] [expired: 2019-04-12]
3B068FB4789ABE4AEFA3BB491397BC53640DB551
sub rsa4096 2017-01-24 [S] [expired: 2020-01-24]
3E50F6D3EC278FDEB655C8CA6494C6D6997C215E
[user@disp8080 ~]$ rpm -qa gpg-pubkey* --qf '%{NAME}-%{VERSION}-%{RELEASE}
%{PACKAGER}\n' | grep '[email protected]' | sed 's/ .*$//' |
sudo xargs rpm -e
[user@disp8080 ~]$ sudo rpm --import linux_signing_key.pub
[user@disp8080 ~]$ rpm -qi gpg-pubkey-d38b4796-* | gpg --show-keys
--with-subkey-fingerprint
pub rsa4096 2016-04-12 [SC]
EB4C1BFD4F042F6DDDCCEC917721F63BD38B4796
uid Google Inc. (Linux Packages Signing Authority)
<[email protected]>
sub rsa4096 2016-04-12 [S] [expired: 2019-04-12]
3B068FB4789ABE4AEFA3BB491397BC53640DB551
sub rsa4096 2017-01-24 [S] [expired: 2020-01-24]
3E50F6D3EC278FDEB655C8CA6494C6D6997C215E
sub rsa4096 2019-07-22 [S] [expired: 2022-07-21]
2F528D36D67B69EDF998D85778BD65473CB3BD13
sub rsa4096 2021-10-26 [S] [expires: 2024-10-25]
8461EFA0E74ABAE010DE66994EB27DB2A3B88B8B
sub rsa4096 2023-02-15 [S] [expires: 2026-02-14]
A5F483CD733A4EBAEA378B2AE88979FB9B30ACF2
```
# The root of the problem
Google's Linux Signing keys have an unusual configuration: they retain the same
master key, but replace the subkeys which do the actual signing. Since ``rpm``
identifies the whole collection of keys by the master key, the new key looks
like the pre-existing key. So it ignores it.
# Work around
The work around -- as alluded to above -- is to delete the old keys before
trying to import the new ones. This can be done with:
```
rpm -qa gpg-pubkey* --qf '%{NAME}-%{VERSION}-%{RELEASE} %{PACKAGER}\n' | grep
'[email protected]' | sed 's/ .*$//' | sudo xargs rpm -e
```
# Discussion
This bug is potentially quite serious. Millions of Linux users use Google
Chrome, and right now, there is no way for them to install or upgrade it. They
will just see that signature verification fails. Most people will give up, or
worse, disable signature checks. Those that try to check the signature
manually will be thwarted by the same bug again.
This means there is a serious usability impact (not being able to install
Google Chrome), as well as a serious security impact (not getting security
updates, or installing unverified updates for Google Chrome).
# Solution
Please either fix ``rpm`` so that it correctly imports keys (e.g. by using a
timestamp as the key version), or deprecate the use of subkeys.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2577
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/issues/[email protected]>_______________________________________________
Rpm-maint mailing list
[email protected]
http://lists.rpm.org/mailman/listinfo/rpm-maint
