Current gpg key is composed one and can't be successfully import via rhel's yum. Can we provide different key based on target os or use just one? $ yum copr enable tkopecek/koji ... $ yum install koji ... Retrieving key from https://download.copr.fedorainfracloud.org/results/tkopecek/koji/pubkey.gpg Importing GPG key 0x3802E829: Userid : "tkopecek_koji (None) <tkopecek#koji.org>" Fingerprint: 7f05 4cc6 6501 2a24 b0dd b892 a033 6e0a 3802 e829 From : https://download.copr.fedorainfracloud.org/results/tkopecek/koji/pubkey.gpg Is this ok [y/N]: y Public key for python2-koji-1.21.0-20200422.16.g613bbbd1.el7.noarch.rpm is not installed Failing package is: python2-koji-1.21.0-20200422.16.g613bbbd1.el7.noarch GPG Keys are configured as: https://download.copr.fedorainfracloud.org/results/tkopecek/koji/pubkey.gpg Note, that there should be line "Key imported successfully" and second block with next key. Compare with fedora: Copr repo for koji owned by tkopecek 17 kB/s | 1.8 kB 00:00 Importing GPG key 0x3802E829: Userid : "tkopecek_koji (None) <tkopecek#koji.org>" Fingerprint: 7F05 4CC6 6501 2A24 B0DD B892 A033 6E0A 3802 E829 From : https://download.copr.fedorainfracloud.org/results/tkopecek/koji/pubkey.gpg Is this ok [y/N]: y Key imported successfully Importing GPG key 0x8F2BCCA6: Userid : "tkopecek_koji (None) <tkopecek#koji.org>" Fingerprint: 7FBE DD55 4C88 D63C BAD0 EB8F 5F02 8C6B 8F2B CCA6 From : https://download.copr.fedorainfracloud.org/results/tkopecek/koji/pubkey.gpg Is this ok [y/N]: y Key imported successfully Running transaction check Transaction check succeeded.
Thanks for the report. > Current gpg key is composed one and can't be successfully import via rhel's yum. Can you please elaborate on what yum doesn't like about that key? So copr generates incompatible GPG keys with RHEL, right? Any hint what we do wrong? https://pagure.io/copr/copr/blob/master/f/keygen/src/copr_keygen/logic.py#_72 > Can we provide different key based on target os or use just one? Copr generates one gpg key per project. We can somehow replace that key manually, but there's no API for that so it doesn't scale ATM. I'm not sure I got your question correctly, though. It is weird that I (we?) see this error for the first time.
Question is maybe, why there are two keys in one file? 0x3802E829 and 0x8F2BCCA6 - wouldn't it work with just one? Key itself is ok, but problem is, that there is a container with two keys. Maybe there are not many users with multiple keys? In fact I don't know why I have two :-) if they have almost same date of expiration.
gpg < pubkey.gpg gpg: WARNING: no command supplied. Trying to guess what you mean ... pub rsa2048 2016-12-06 [SCEA] [expires: 2021-12-05] 7F054CC665012A24B0DDB892A0336E0A3802E829 uid tkopecek_koji (None) <tkopecek#koji.org> pub rsa2048 2016-12-08 [SCEA] [expires: 2021-12-07] 7FBEDD554C88D63CBAD0EB8F5F028C6B8F2BCCA6 uid tkopecek_koji (None) <tkopecek#koji.org>
Created attachment 1681024 [details] Users with duplicated keys Thanks for the additional info. > Maybe there are not many users with multiple keys? Right, there are only few of them, on keygen I run: $ gpg-copr --list-keys 2>&1 | grep ^uid | cut -d\] -f2 | sort | uniq -c | sort -n ... duplicated output attached ...
I did the following steps... can you please rebuild some package (to update the pub key in your result directory), and confirm that the it helped? [copr-signer@copr-keygen gnupg][PROD]$ gpg-copr --list-keys 'tkopecek#koji.org' gpg: please do a --check-trustdb pub rsa2048 2016-12-06 [SCEA] [expires: 2021-12-05] 7F054CC665012A24B0DDB892A0336E0A3802E829 uid [ultimate] tkopecek_koji (None) <tkopecek#koji.org> pub rsa2048 2016-12-08 [SCEA] [expires: 2021-12-07] 7FBEDD554C88D63CBAD0EB8F5F028C6B8F2BCCA6 uid [ unknown] tkopecek_koji (None) <tkopecek#koji.org> [copr-signer@copr-keygen gnupg][PROD]$ gpg-copr --batch --yes --delete-secret-and-public-keys 7FBEDD554C88D63CBAD0EB8F5F028C6B8F2BCCA6 [copr-signer@copr-keygen gnupg][PROD]$ echo $? 0
Yes, now it works without issues. Thanks! Ken, is it ok also for you?
This is working for me now! Pavel, I'm curious how Copr ended up with two keys for this project?
> Pavel, I'm curious how Copr ended up with two keys for this project? We need to figure this out, I didn't have a chance to diagnose properly. Well, iff there's some sane way to find the original reason ... (I mean... if all the duplicate keys are as old as this one...)
Created attachment 1692193 [details] list affected pub keys These inconsistencies happened in limited time periods in Y2015 and Y2016, so it seems to be some historical problem. Very hard try to find the reasons ... I'm falling back to just doing the cleanup. Sorry. $ bash /var/tmp/duplicates-affected-list-keys | grep pub | sort | uniq -c 4 pub rsa2048 2015-01-29 [SCEA] [expires: 2025-02-04] 2 pub rsa2048 2015-02-01 [SCEA] [expires: 2025-02-04] 2 pub rsa2048 2015-02-05 [SCEA] [expires: 2025-02-04] 1 pub rsa2048 2015-02-05 [SCEA] [expires: 2025-02-16] 2 pub rsa2048 2015-05-17 [SCEA] [expires: 2025-02-04] 2 pub rsa2048 2015-06-05 [SCEA] [expires: 2025-02-04] 4 pub rsa2048 2015-06-09 [SCEA] [expires: 2025-02-04] 2 pub rsa2048 2015-06-19 [SCEA] [expires: 2025-02-04] 2 pub rsa2048 2015-06-30 [SCEA] [expires: 2025-02-04] 1 pub rsa2048 2015-07-07 [SCEA] [expires: 2025-02-04] 1 pub rsa2048 2015-07-08 [SCEA] [expires: 2025-02-04] 3 pub rsa2048 2015-07-14 [SCEA] [expires: 2025-02-04] 2 pub rsa2048 2016-03-11 [SCEA] [expires: 2025-03-10] 1 pub rsa2048 2016-03-25 [SCEA] [expires: 2025-03-24] 3 pub rsa2048 2016-12-02 [SCEA] [expires: 2021-12-01] 3 pub rsa2048 2016-12-03 [SCEA] [expires: 2021-12-02] 2 pub rsa2048 2016-12-04 [SCEA] [expires: 2021-12-03] 19 pub rsa2048 2016-12-05 [SCEA] [expires: 2021-12-04] 13 pub rsa2048 2016-12-06 [SCEA] [expires: 2021-12-05] 20 pub rsa2048 2016-12-07 [SCEA] [expires: 2021-12-06] 38 pub rsa2048 2016-12-08 [SCEA] [expires: 2021-12-07] 2 pub rsa2048 2016-12-09 [SCEA] [expires: 2021-12-08]
ok, np - feel free to close this one.
Created attachment 1692259 [details] protocols from manual action Ok, I removed the rest of duplicated keys from 2015-2016.