Installation on CentOS 7 fails (gpg key mismatch)

[olifre]

Describe the bug
In a (fresh) CentOS 7 system, package signature verification fails (started to happen some time in the last 24 hours):

warning: /var/cache/yum/x86_64/7/xpra/packages/ffmpeg-xpra-5.1.2-1.el7.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID f18ad6bb: NOKEY
Public key for ffmpeg-xpra-5.1.2-1.el7.x86_64.rpm is not installed
--------------------------------------------------------------------------------
Total                                               24 MB/s |  46 MB  00:01     
Retrieving key from https://xpra.org/gpg.asc
Importing GPG key 0x11BB7837:
 Userid     : "Antoine Martin [<[email protected]>](mailto:[email protected])"
 Fingerprint: e32f 3184 d959 d5e4 6986 6ec8 ad30 6b2d 11bb 7837
 From       : https://xpra.org/gpg.asc
Retrieving key from https://xpra.org/gpg-2022.asc
Importing GPG key 0x11BB7837:
 Userid     : "Antoine Martin [<[email protected]>](mailto:[email protected])"
 Fingerprint: e32f 3184 d959 d5e4 6986 6ec8 ad30 6b2d 11bb 7837
 From       : https://xpra.org/gpg-2022.asc


Public key for turbojpeg-1.2.90-8.el7_9.x86_64.rpm is not installed


 Failing package is: turbojpeg-1.2.90-8.el7_9.x86_64
 GPG Keys are configured as: https://xpra.org/gpg.asc, https://xpra.org/gpg-2022.asc

To Reproduce
More basic commands to reproduce:

wget https://xpra.org/dists/CentOS/7/x86_64/ffmpeg-xpra-5.1.2-1.el7.x86_64.rpm
rpm --import https://xpra.org/gpg.asc
rpm --import https://xpra.org/gpg-2022.asc
rpm -K ffmpeg-xpra-5.1.2-1.el7.x86_64.rpm 
ffmpeg-xpra-5.1.2-1.el7.x86_64.rpm: (SHA1) DSA sha1 md5 (GPG) NOT OK (MISSING KEYS: GPG#f18ad6bb)

System Information (please complete the following information):

• CentOS Linux release 7.9.2009 (Core)

[totaam]

Duplicate of #3846 - re-importing the key should fix this.

[olifre]

re-importing the key should fix this.

Sadly, it does not — as outlined in the reproduction commands above, I already tried re-importing the key. I can also reproduce both in a fresh CentOS 7 container (without having XPRA keys added before), and on a system after purging all XPRA-related keys, both systems are not using any HTTP proxies / caches:

$ rpm -qa gpg-pubkey* | grep f18ad6bb
gpg-pubkey-f18ad6bb-46268319
$ rpm -e gpg-pubkey-f18ad6bb-46268319
$ rpm -qa gpg-pubkey* | grep f18ad6bb
<no output>
$ rpm --import https://xpra.org/gpg.asc
$ rpm --import https://xpra.org/gpg-2022.asc
$ rpm -qa gpg-pubkey* | grep f18ad6bb
gpg-pubkey-f18ad6bb-46268319
$ rpm -K ffmpeg-xpra-5.1.2-1.el7.x86_64.rpm 
ffmpeg-xpra-5.1.2-1.el7.x86_64.rpm: (SHA1) DSA sha1 md5 (GPG) NOT OK (MISSING KEYS: GPG#f18ad6bb)

To confirm that the systems see the current keys:

$ gpg --with-fingerprint <(curl -s https://xpra.org/gpg.asc)
pub  1024D/11BB7837 2006-03-15 Antoine Martin <[email protected]>
      Key fingerprint = E32F 3184 D959 D5E4 6986  6EC8 AD30 6B2D 11BB 7837
sub  2048g/2E4D9F3F 2006-03-15 [expires: 2007-03-15]
pub  1024D/F18AD6BB 2007-04-18 Antoine Martin <[email protected]>
      Key fingerprint = C11C 0A4D F702 EDF6 C04F  458C 18AD B31C F18A D6BB
uid                            [jpeg image of size 4992]
sub  2048g/6E23E963 2007-04-18 [expires: 2026-03-21]
$ gpg --with-fingerprint <(curl -s https://xpra.org/gpg-2022.asc)
pub  1024D/11BB7837 2006-03-15 Antoine Martin <[email protected]>
      Key fingerprint = E32F 3184 D959 D5E4 6986  6EC8 AD30 6B2D 11BB 7837
sub  2048g/2E4D9F3F 2006-03-15 [expires: 2007-03-15]
pub  1024D/F18AD6BB 2007-04-18 Antoine Martin <[email protected]>
      Key fingerprint = C11C 0A4D F702 EDF6 C04F  458C 18AD B31C F18A D6BB
uid                            [jpeg image of size 4992]
sub  2048g/6E23E963 2007-04-18 [expires: 2026-03-21]

[olifre]

Well, that's interesting, importing the expired key helps:

$ gpg --with-fingerprint <(curl -s https://xpra.org/gpg-2018.asc)
pub  1024D/F18AD6BB 2007-04-18 Antoine Martin <[email protected]>
      Key fingerprint = C11C 0A4D F702 EDF6 C04F  458C 18AD B31C F18A D6BB
uid                            [jpeg image of size 4992]
sub  2048g/6E23E963 2007-04-18 [expires: 2023-05-05]
$ rpm --import https://xpra.org/gpg-2018.asc
$ rpm -qa gpg-pubkey* | grep f18ad6bb
gpg-pubkey-f18ad6bb-5aeef501
gpg-pubkey-f18ad6bb-46268319
$ rpm -K ffmpeg-xpra-5.1.2-1.el7.x86_64.rpm 
ffmpeg-xpra-5.1.2-1.el7.x86_64.rpm: (sha1) dsa sha1 md5 gpg OK

Of course, that key is not imported by default anymore, since it is not referenced in the repo files.

Do you have an idea on what's going on here?

[totaam]

I have re-signed every RPM with the (same) key again, which turned out to be harder than you would think.
@olifre can you try again please.

[olifre]

@totaam Thanks, sadly, that did not help (I also tried in a fresh container, here's what I get doing things manually):

$ rpm -qa gpg-pubkey* | grep f18ad6bb
gpg-pubkey-f18ad6bb-46268319
$ rpm -e gpg-pubkey-f18ad6bb-46268319
$ rpm -qa gpg-pubkey* | grep f18ad6bb
<no output>
$ rpm --import https://xpra.org/gpg.asc
$ rpm -qa gpg-pubkey* | grep f18ad6bb
gpg-pubkey-f18ad6bb-46268319
$ wget https://xpra.org/dists/CentOS/7/x86_64/ffmpeg-xpra-5.1.2-1.el7.x86_64.rpm
$ rpm -K ffmpeg-xpra-5.1.2-1.el7.x86_64.rpm
ffmpeg-xpra-5.1.2-1.el7.x86_64.rpm: (SHA1) DSA sha1 md5 (GPG) NOT OK (MISSING KEYS: GPG#f18ad6bb)
$ rpm --import https://xpra.org/gpg-2018.asc
$ rpm -K ffmpeg-xpra-5.1.2-1.el7.x86_64.rpm
ffmpeg-xpra-5.1.2-1.el7.x86_64.rpm: (sha1) dsa sha1 md5 gpg OK

So again, it only works if I import the expired key — even though I can confirm the md5sum of the RPM downloaded today is different than the one from yesterday, i.e. I see you re-signed them.

[olifre]

Hi @totaam ,
since the issue persists and prevents new installations on CentOS 7 systems, I am for now in fact using:

rpm --import https://xpra.org/gpg-2018.asc

as a (temporary) workaround in container builds. One way to go could be to adapt the repo file for CentOS 7 for the remaining lifetime of this distribution, i.e. add the old key there explicitly?

[totaam]

@olifre is the commit above what you expected? If so, please close.
If not, please submit a PR - I really don't have any time to spend on CentOS 7.x
It isn't even listed on the download page
Why would you use 7.x and be stuck on an old version since you have the freedom to use containers?
(if an app only runs on 7.x, you could always run X11 and xpra in a different container and only share the X11 sockets with that app)

[olifre]

@totaam Yes, many thanks! The commit above is exactly what I expected — it's not deployed to xpra.org yet, correct?
In case that's expected / will follow later, of course the issue can be closed from my point of view.

Why would you use 7.x and be stuck on an old version since you have the freedom to use containers?

In fact, the use case is for older compiled / linked code — and containers are only used "behind the scenes", i.e. users choose "I need a CentOS 7 environment to run my software", start that on a large HPC/HTC resource, and don't interact with containers themselves. You may summarize this as "operating system / software environment as a service".
We plan to support CentOS 7 only for as long as the distribution itself still receives security updates, so of course the clock is ticking, but as of now, we still have to.

[totaam]

Pushed to xpra.org