Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x264-xpra installation on CentOS 7 fails (GPG key not installed) #3499

Closed
olifre opened this issue Mar 23, 2022 · 8 comments
Closed

x264-xpra installation on CentOS 7 fails (GPG key not installed) #3499

olifre opened this issue Mar 23, 2022 · 8 comments
Labels
bug Something isn't working

Comments

@olifre
Copy link

olifre commented Mar 23, 2022

Describe the bug
Even though the repository is added and the gpgp.asc is imported, package installation fails, claiming the key is not installed.
Note this is new behaviour since <24 hours.

To Reproduce
Steps to reproduce the behavior:

wget -O /etc/yum.repos.d/xpra.repo https://xpra.org/repos/CentOS/xpra.repo
yum -y install x264-xpra
...
Downloading packages:
warning: /var/cache/yum/x86_64/7/xpra/packages/x264-xpra-20211215-1.el7.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID f18ad6bb: NOKEY
Retrieving key from https://xpra.org/gpg.asc
Importing GPG key 0x11BB7837:
 Userid     : "Antoine Martin <antoine@nagafix.co.uk>"
 Fingerprint: e32f 3184 d959 d5e4 6986 6ec8 ad30 6b2d 11bb 7837
 From       : https://xpra.org/gpg.asc


Public key for x264-xpra-20211215-1.el7.x86_64.rpm is not installed


 Failing package is: x264-xpra-20211215-1.el7.x86_64
 GPG Keys are configured as: https://xpra.org/gpg.asc

System Information (please complete the following information):

  • OS: CentOS Linux release 7.9.2009 (Core)

Additional context
The issue can also be confirmed manually:

wget https://xpra.org/gpg.asc
rpm --import gpg.asc
wget https://xpra.org/dists/CentOS/7/x86_64/x264-xpra-20211215-1.el7.x86_64.rpm
rpm -qpi x264-xpra-20211215-1.el7.x86_64.rpm 
warning: x264-xpra-20211215-1.el7.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID f18ad6bb: NOKEY
...
Signature   : DSA/SHA1, Thu Jan 27 13:56:16 2022, Key ID 18adb31cf18ad6bb

However, the import seems to have gone well:

rpm -qa gpg-pubkey --qf '%{Description}'|gpg --with-fingerprint
...
pub  1024D/11BB7837 2006-03-15 Antoine Martin <antoine@nagafix.co.uk>
  Schl.-Fingerabdruck = E32F 3184 D959 D5E4 6986  6EC8 AD30 6B2D 11BB 7837
sub  2048g/2E4D9F3F 2006-03-15 [verfällt: 2007-03-15]
pub  1024D/F18AD6BB 2007-04-18 Antoine Martin <antoine@nagafix.co.uk>
  Schl.-Fingerabdruck = C11C 0A4D F702 EDF6 C04F  458C 18AD B31C F18A D6BB
uid                            [jpeg image of size 4992]
sub  2048g/6E23E963 2007-04-18 [verfällt: 2026-03-21]
@olifre olifre added the bug Something isn't working label Mar 23, 2022
@totaam
Copy link
Collaborator

totaam commented Mar 24, 2022

This is caused by #3446 - an RPM package can only be signed by a single key.
(it is in fact still the same underlying key - but the tools don't see it that way)

Most users have the "old" (2018) one installed, but because of #3446, there is now an updated key - without SHA1 signatures.
That's the key that the instructions and repositories were pointing to.
(why we can't just keep the old signatures and tell the tools to not use SHA1 if they don't want to... is why we're all going to waste a lot of time dealing with the ugly fallout)

The old key (with SHA1 amongst the signatures) is here:
https://xpra.org/gpg-2018.asc
The updated key is here:
https://xpra.org/gpg-2022.asc

I have switched back to pointing to the older key by default here:
https://xpra.org/gpg.asc

So things should work again by default.
@olifre does that work for you?


Anyone still encountering problems should:

  • import the old key for using packages signed with the old key (typically older distributions or existing packages)
  • import the updated key or update it from a gpg key server for distributions that cause problems (ie: newer Debian releases)

@olifre
Copy link
Author

olifre commented Mar 24, 2022

Indeed, that fixes it for me. For reference, I have been using a "from scratch" installation of CentOS 7 (actually, a container build), so it was "fresh" and had no memory of older keys.
I wonder whether RedHat-based distros could be satisfied by specifying:

gpgkey= https://xpra.org/gpg-2018.asc
        https://xpra.org/gpg-2022.asc

I have not tested this, but the syntax is supported — maybe this would cause yum / dnf to import both keys?

mjharkin pushed a commit to mjharkin/Xpra that referenced this issue Mar 24, 2022
git-svn-id: https://xpra.org/svn/Xpra@28375 3bb7dfac-3a0b-4e04-842a-767bc560f471
mjharkin pushed a commit to mjharkin/Xpra that referenced this issue Mar 24, 2022
git-svn-id: https://xpra.org/svn/Xpra@28376 3bb7dfac-3a0b-4e04-842a-767bc560f471
@totaam
Copy link
Collaborator

totaam commented Mar 24, 2022

Done.
If that works for CentOS 7, it should work for newer versions of RHEL / Fedora, one would assume..

@totaam totaam closed this as completed Mar 24, 2022
@olifre
Copy link
Author

olifre commented Mar 24, 2022

@totaam I tested it right now on CentOS 7, again with a fresh system — while it indicates both keys are fetched, it still seems to fail:

yum -y install x264-xpra
...
Install  1 Package

Total size: 662 k
Installed size: 2.3 M
Downloading packages:
warning: /var/cache/yum/x86_64/7/xpra/packages/x264-xpra-20211215-1.el7.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID f18ad6bb: NOKEY
Retrieving key from https://xpra.org/gpg.asc
Retrieving key from https://xpra.org/gpg-2022.asc
Importing GPG key 0x11BB7837:
 Userid     : "Antoine Martin <antoine@nagafix.co.uk>"
 Fingerprint: e32f 3184 d959 d5e4 6986 6ec8 ad30 6b2d 11bb 7837
 From       : https://xpra.org/gpg-2022.asc


Public key for x264-xpra-20211215-1.el7.x86_64.rpm is not installed


 Failing package is: x264-xpra-20211215-1.el7.x86_64
 GPG Keys are configured as: https://xpra.org/gpg.asc, https://xpra.org/gpg-2022.asc

So while this has fetched both keys, it seems only one is imported. Maybe there is some misled intelligence not checking for signature differences :-(.

@totaam
Copy link
Collaborator

totaam commented Mar 26, 2022

Just tried it in two separate CentOS 7 VMs, and the installation / update did install both keys.
The installation grabbed xpra and its dependencies (including x264-xpra) so it must have used both keys. I've also tried enabling the beta repo, still no problems.
What am I missing / doing wrong?

@olifre
Copy link
Author

olifre commented Mar 26, 2022

You are correct, it's my bad. Apparently my testing VM was not fully cleansed between the tests. While I did purge the repo, and clean all cached repository content and packages, apparently the presence of the single already-imported GPG key from the previous tests broke it.

So in fact, the issue is fixed. I tried now with a completely virgin CentOS 7 container, and it works. I could also make it work on the VM by first purging the previously imported GPG key.

Sorry for causing you extra testing work due to my unclean environment :-(. At least, in case another user is affected by this at some point, it means cleaning out the imported GPG keys may be needed, as follows:

rpm -q gpg-pubkey --qf '%{NAME}-%{VERSION}-%{RELEASE}\t%{SUMMARY}\n'
rpm -e gpg-pubkey-f18ad6bb-46268319
rpm -e gpg-pubkey-f18ad6bb-5aeef501
yum clean all
wget -O /etc/yum.repos.d/xpra.repo https://xpra.org/repos/CentOS/xpra.repo

It seems the presence of gpg-pubkey-f18ad6bb-46268319 in the RPM key store before in my VM broke things. After purging this and installing a package, both keys are imported just fine and things work as expected.
Sorry again for the noise, hope these instructions help in case another user is hit by this on an existing setup.

@totaam
Copy link
Collaborator

totaam commented Jul 18, 2023

For GPG key issues, please refer to #3863

@olifre
Copy link
Author

olifre commented Jul 18, 2023

@totaam Many thanks, I can confirm that the new keys are working on my end even on good old CentOS 7. The students and scientists using XPRA in their scientific work will be happy about the continued energy you breathe into the project! ❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants