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

2023-07-21 Thread Neal H. Walfield 
Looking at the code, it seems:

  - 
[`rpmcliImportPubkeys`](https://github.com/rpm-software-management/rpm/blob/1bd0f9cd2eb60c30f6076b202942ab8f43c4e41b/lib/rpmchecksig.c#L83)
 - 
[calls](https://github.com/rpm-software-management/rpm/blob/1bd0f9cd2eb60c30f6076b202942ab8f43c4e41b/lib/rpmchecksig.c#L99)
 
[`doImport`](https://github.com/rpm-software-management/rpm/blob/1bd0f9cd2eb60c30f6076b202942ab8f43c4e41b/lib/rpmchecksig.c#L27)
 - 
[calls](https://github.com/rpm-software-management/rpm/blob/1bd0f9cd2eb60c30f6076b202942ab8f43c4e41b/lib/rpmchecksig.c#L55)
 
[`rpmtsImportPubkey`](https://github.com/rpm-software-management/rpm/blob/master/lib/rpmts.c#L603)
 - 
[calls](https://github.com/rpm-software-management/rpm/blob/master/lib/rpmts.c#L646)
 
[`rpmKeyringAddKey`](https://github.com/rpm-software-management/rpm/blob/1bd0f9cd2eb60c30f6076b202942ab8f43c4e41b/rpmio/rpmkeyring.c#L82)

which [checks if the certificate's key id is known, and if so, don't do 
anything](https://github.com/rpm-software-management/rpm/blob/1bd0f9cd2eb60c30f6076b202942ab8f43c4e41b/rpmio/rpmkeyring.c#L88-L90).

OpenPGP certificates are made up of packets.  It is possible to add new packets 
without updating other packets (e.g., a new subkey, a new self signature that 
extends the certificate's expiration time).  So it is not easy to generate a 
linear version number for an OpenPGP certificate.

I think we need to extend rpm's [pgp 
interface](https://github.com/rpm-software-management/rpm/blob/master/include/rpm/rpmpgp.h)
 to add a function to merge two versions of a certificate.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2577#issuecomment-1646382884
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

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

2023-07-21 Thread Andrew Clausen 
I should mention that I am not the first person to encounter this problem -- I 
imagine many people are affected.  See for example this Reddit thread: 





-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2577#issuecomment-1646334035
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

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

2023-07-21 Thread 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-keymas...@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@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/sin 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) 

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 'linux-packages-keymas...@google.com' | 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) 

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-keymas...@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-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] [RFE] Please provide `%excludes` section (Issue #1852)

2023-07-21 Thread rguenth 
I've opened kind-of a duplicate with 
https://github.com/rpm-software-management/rpm/issues/2555 since I have
the need to conditionally "drop" built subpackages.  So my idea is to add the 
ability to do this by turning
an existing %files into what you describe as %excludes section with a new 
option to %files (which I can then add
conditionally).  Implementation wise (without any of your suggested 
optimization) it could simply skip the
final .rpm file generation for such subpackages either by turning the name of 
the subpackage to something special
or by adding a flag to the metadata tracked.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1852#issuecomment-1645239714
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] [RFE] Add option to %files to ignore listed files (suggest: -i) (Issue #2555)

2023-07-21 Thread rguenth 
But I don't really want to rely on this bug in %exclude - see 
https://github.com/rpm-software-management/rpm/issues/994 which is acknowledged 
as a bug (but appearently hard to fix because of Fedora relying on this).

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2555#issuecomment-1645234765
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint