[Rpm-maint] [rpm-software-management/rpm] rpm --import does not replace old keys with new keys (Issue #2577)

[Andrew Clausen]

# 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 'linux-packages-keymaster at google.com' | 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 at 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 at disp8080 ~]$ sudo rpm --import linux_signing_key.pub
[user at 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) <linux-packages-keymaster at google.com>
sub   rsa4096 2016-04-12 [S] [expired: 2019-04-12]
      3B068FB4789ABE4AEFA3BB491397BC53640DB551
sub   rsa4096 2017-01-24 [S] [expired: 2020-01-24]
      3E50F6D3EC278FDEB655C8CA6494C6D6997C215E

[user at disp8080 ~]$ rpm -qa gpg-pubkey* --qf '%{NAME}-%{VERSION}-%{RELEASE} %{PACKAGER}\n' | grep 'linux-packages-keymaster at google.com' | sed 's/ .*$//' | sudo xargs rpm -e
[user at disp8080 ~]$ sudo rpm --import linux_signing_key.pub
[user at 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) <linux-packages-keymaster at google.com>
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 'linux-packages-keymaster at google.com' | 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/2577 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20230721/bf495298/attachment-0001.html>