Bugzilla – Bug 1212114
unknown undecided new repository or package signing key received - zypper dup 15.4 to 15.5
Last modified: 2023-10-04 12:41:15 UTC
completely up to date opensuse leap 15.4 including most up todate todays buildkey package: (just observed the update on 15.4 right before) ...... rpm -qi openSUSE-build-key Name : openSUSE-build-key Version : 1.0 Release : lp154.3.11.1 Architecture: noarch Install Date: Wed Jun 7 17:16:33 2023 Group : System/Packages Size : 26236 License : GPL-2.0+ Signature : RSA/SHA256, Mon Jun 5 11:46:16 2023, Key ID b88b2fd43dbdc284 Source RPM : openSUSE-build-key-1.0-lp154.3.11.1.src.rpm Build Date : Mon Jun 5 11:46:11 2023 Build Host : cumulus3 Relocations : (not relocatable) Packager : http://bugs.opensuse.org Vendor : openSUSE Summary : The public gpg keys for rpm package signature verification Description : This package contains the gpg keys that are used to sign the openSUSE rpm packages. The keys installed here are not actually used by anything. rpm/zypper use the keys in the rpm db instead. Distribution: openSUSE Leap 15.4 ....... zypper dup with releasever 15.5: sudo zypper -vvvv --releasever=15.5 ref Verbosity: 3 Warning: Enforced setting: $releasever=15.5 Initializing Target Specified repositories: Skipping disabled repository 'Update repository with updates for openSUSE Leap debuginfo packages from openSUSE Backports' Checking whether to refresh metadata for Update repository of openSUSE Backports Retrieving: http://download.opensuse.org/update/leap/15.5/backports/repodata/repomd.xml ...................................................................[done (893 B/s)] Retrieving: http://download.opensuse.org/update/leap/15.5/backports/repodata/repomd.xml.asc ...............................................................[done (827 B/s)] Retrieving: http://download.opensuse.org/update/leap/15.5/backports/repodata/repomd.xml.key .............................................................[done (1.7 KiB/s)] Retrieving: http://download.opensuse.org/update/leap/15.5/backports/repodata/repomd.xml .............................................................................[done] New repository or package signing key received: Repository: Update repository of openSUSE Backports Key Fingerprint: F044 C2C5 07A1 262B 538A AADD 8A49 EB03 25DB 7AE0 Key Name: openSUSE:Backports OBS Project <openSUSE:Backports@build.opensuse.org> Key Algorithm: RSA 4096 Key Created: Wed May 10 16:46:12 2023 Key Expires: Sun May 9 16:46:12 2027 Rpm Name: gpg-pubkey-25db7ae0-645bae34 Note: Signing data enables the recipient to verify that no modifications occurred after the data were signed. Accepting data with no, wrong or unknown signature can lead to a corrupted system and in extreme cases even to a system compromise. Note: A GPG pubkey is clearly identified by its fingerprint. Do not rely on the key's name. If you are not sure whether the presented key is authentic, ask the repository provider or check their web site. Many providers maintain a web page showing the fingerprints of the GPG keys they are using. Do you want to reject the key, trust temporarily, or trust always? [r/t/a/?] (r): ^Cd ---------------- I aborted zypper dup right there, so maybe theres even more keys to decide afterwards? only having plain very default standard repos included and activated what came with a normal 15.4 system. another missing key? how can the normal distro using user decide such questions? will opensuse ever have a complete and foolproof design to upgrade itself to the latest and most current distribution+1 release? thanks for looking into this.
meissner@suse.com openSUSE-build-key includes SP4 PackageHub key: │9C214D4065176565│openSUSE:Backports OBS Project <openSUSE:Backports@build.opensuse.org> - gpg-pubkey-65176565-59787af5.asc but not the SP5 one. Essentially the same as bug 1212134.
Actually the key *is* in the package. From https://en.opensuse.org/SDB:System_upgrade#0._New_4096_bit_RSA_signing_key > Users of 15.4 release currently need to import key manually with: > > rpm --import /usr/lib/rpm/gnupg/keys/gpg-pubkey-29b700a4-62b07e22.asc > > and also the new 4096 openSUSE Backports key needs to be imported: > > rpm --import /usr/lib/rpm/gnupg/keys/gpg-pubkey-25db7ae0-645bae34.asc I guess the normal distribution user just needs to read the fine manual.
wow maybe I only looked into this very newly added article at: <https://en.opensuse.org/openSUSE:Signing_Keys> at it doesnt say one need to import or do stuff anything except using zypper to add or update or install that openSUSE-build-key package? what would be the reason to actually bring in key and payload inside such a openSUSE-build-key package that has just been made available right on release-day, and this package NOT importing or not doing further steps such as rpm --import and so on? what is the idea behind this behaviour? is there any reason to install such a package but not make use of the keys inside it in say rpm etc? to return back to my maybe request, when will openSUSE really feature a simple and complete way of upgrading itself? maybe it boils down to that question then. thanks.
This is probably a design decision, as the distribution signing keys are added from the media during the installation only, and we have no pattern of delivering repositories or keys as packages. Except from openSUSE-build-key, but this is for reference only. The "easy consumption" piece is already covered, closing as feature request already in progress.
small update addtl note on this bug. i have exactly one machine 15.4 which doesnt have at all installed the package named "openSUSE-build-key" and thus can not rpm --import those path names at all both commands from <https://en.opensuse.org/SDB:System_upgrade#0._New_4096_bit_RSA_signing_key> when i zypper se for that package, it doesnt shows up as installed but i could zypper in that package to begin with. this one machine was offline for a longer while, without receiving any update packages for i dont know how many weeks now. is this maybe another bug regarding this openSUSE-build-key package? how is this possible? all other machine i have running with 15.4 they all have and did receive the update some days ago that installed the latest openSUSE-build-key rpm package. thanks.
the issue is that there is no key auto-import currently on updates of openSUSE-build-key, which is missing in the migration scenario 15.4 -> 15.5. It is my plan for this week to work on that.
just wondering why all the other machines all had (and became installed around the official release date of leap 15.5) this openSUSE-build-key installed and/or patched/updated I remember that, except for this one machine, which apparently does not have this package installed at all, so there was nothing to rpm import those .asc files in /usr/lib/rpm/gnupg/keys/ were apparently not even there. i still have this affected system (15.4) available at the moment and I deliberately stopped its upgrade to 15.5 when I encountered this situation. if anyone wants to make use of some logs or stuff i could extract. was just wondering how or why all other 15.4 systems were having at least that openSUSE-build-key rpm installed and the .asc files present. but this one had not. thanks.
i did some digging around on that one odd machine, with 15.4, grep inside the zypper history, there is no openSUSE-build-key package installed etc. its kind of odd, as it has had zypper dup or upgrades in the past from at leat 2021 fall onwards, and dup to 15.4 was only this februar 2023. it has some ancient? lines in .../zypp/history but those are called suse-build-key applied in march 2022 and february 2023 and april 2023 but all my other machines have packages named: openSUSE-build-key very odd. maybe there are some shortcomings if this openSUSE-build-key package should be mandatory and forced install or something? maybe I dont understand this issue just at all.
is this supposed to be solved yet? i have deliberately refrained from upgrading one 15.4 machine here to 15.5 just to keep an eye on this bug a bit further does anyone still care for 15.4? this machine is up-to-date today (except for this other zypper patch bug... (see https://bugzilla.opensuse.org/show_bug.cgi?id=1214835 ) so this machine currently, when i try to zypper dup --------- zypper --releasever=15.5 ref Warning: Enforced setting: $releasever=15.5 New repository or package signing key received: Repository: Update repository of openSUSE Backports Key Fingerprint: F044 C2C5 07A1 262B 538A AADD 8A49 EB03 25DB 7AE0 Key Name: openSUSE:Backports OBS Project <openSUSE:Backports@build.opensuse.org> Key Algorithm: RSA 4096 Key Created: Wed 10 May 2023 04:46:12 PM CEST Key Expires: Sun 09 May 2027 04:46:12 PM CEST Rpm Name: gpg-pubkey-25db7ae0-645bae34 Note: Signing data enables the recipient to verify that no modifications occurred after the data were signed. Accepting data with no, wrong or unknown signature can lead to a corrupted system and in extreme cases even to a system compromise. Note: A GPG pubkey is clearly identified by its fingerprint. Do not rely on the key's name. If you are not sure whether the presented key is authentic, ask the repository provider or check their web site. Many providers maintain a web page showing the fingerprints of the GPG keys they are using. Do you want to reject the key, trust temporarily, or trust always? [r/t/a/?] (r): ^C ---------------- rpm -aq | grep -i pubkey gpg-pubkey-1d061a62-427a396f gpg-pubkey-0dfb3188-41ed929b.src gpg-pubkey-9c800aca-481f343a.src gpg-pubkey-7e2e3b05-44748aba.src gpg-pubkey-6b9d6523-447450b7.src gpg-pubkey-65176565-61a0ee8f gpg-pubkey-9c800aca-40d8063e.src gpg-pubkey-392ffa88-560516c9 gpg-pubkey-9c800aca-4be01999.src gpg-pubkey-7e2e3b05-4816488f.src gpg-pubkey-a1912208-446a0899 gpg-pubkey-56b4177a-47965b33.src gpg-pubkey-39db7c82-5f68629b gpg-pubkey-3dbdc284-53674dd4 gpg-pubkey-307e3d54-5aaa90a5 ----------------- thanks.
I did try to solve withj a post installation script run via zypper. rpm -ql openSUSE-build-key it should have: /var/adm/update-scripts/openSUSE-build-key-1.0-lp154.3.34.1-import-openSUSE-build-key.sh which should have run after the update. - did you update using libzypp / zypper / packagekit, or other methods? - can you run the script as root manually perhaps
results in: package openSUSE-build-key is not installed this is my last machine in the list of 15.4 machines from back then, that I kept to keep an eye on this bug. i am a very normal simple user. i only zypper and all my other 15.4 machines I needed to add the opensuse key manually as I wanted to upgrade to 15.5 early then i reported this bug and you guys answered and worked on it and I decided to revisit this bug but it never gotton solved or resolved for that one last 15.4 machine so far. -------- ls /var/adm/update-scripts/ -lart total 44 -rw-r--r-- 1 root root 259 Nov 2 2014 ghostscript-fonts-9.06-6.1.5-reconfigure-fonts -rw-r--r-- 1 root root 256 Nov 2 2014 xorg-x11-fonts-7.6-30.1.5-reconfigure-fonts -rw-r--r-- 1 root root 257 Nov 8 2015 ghostscript-fonts-9.06-7.4-reconfigure-fonts -rw-r--r-- 1 root root 254 Nov 8 2015 xorg-x11-fonts-7.6-31.4-reconfigure-fonts -rw-r--r-- 1 root root 253 Feb 1 2017 google-noto-fonts-20151215-2.3-reconfigure-fonts -rw-r--r-- 1 root root 250 Feb 1 2017 ghostscript-fonts-9.06-8.19-reconfigure-fonts -rw-r--r-- 1 root root 247 Feb 1 2017 xorg-x11-fonts-7.6-32.20-reconfigure-fonts -rw-r--r-- 1 root root 254 Jul 23 2017 google-noto-fonts-20151215-4.13-reconfigure-fonts -rw-r--r-- 1 root root 251 Jul 23 2017 ghostscript-fonts-9.06-10.13-reconfigure-fonts drwxr-xr-x 10 root root 4096 Mar 15 2022 .. drwx------ 2 root root 4096 Sep 8 10:45 . --------------
my 15.4 leftover machine that I kept, is still showing this unknown key error. does anyone still care for 15.4 users having this situation and can or is this still gona be fixed by an additional? update or should i just go on with this manually add the 15.5 key and go on with the zypper dup then? as of right now, a completely refereshed 15.4 shows: ------------- zypper --releasever=15.5 ref Warning: Enforced setting: $releasever=15.5 New repository or package signing key received: Repository: Update repository of openSUSE Backports Key Fingerprint: F044 C2C5 07A1 262B 538A AADD 8A49 EB03 25DB 7AE0 Key Name: openSUSE:Backports OBS Project <openSUSE:Backports@build.opensuse.org> Key Algorithm: RSA 4096 Key Created: Wed 10 May 2023 04:46:12 PM CEST Key Expires: Sun 09 May 2027 04:46:12 PM CEST Rpm Name: gpg-pubkey-25db7ae0-645bae34 Note: Signing data enables the recipient to verify that no modifications occurred after the data were signed. Accepting data with no, wrong or unknown signature can lead to a corrupted system and in extreme cases even to a system compromise. Note: A GPG pubkey is clearly identified by its fingerprint. Do not rely on the key's name. If you are not sure whether the presented key is authentic, ask the repository provider or check their web site. Many providers maintain a web page showing the fingerprints of the GPG keys they are using. Do you want to reject the key, trust temporarily, or trust always? [r/t/a/?] (r): ^C
zypper in openSUSE-build-key its supposed to be on openSUSE Leap machines... not sure how far you migrated, it might not hafve been added during the migration
ok maybe my final attempt, will migrate this 15.4 box to 15.5 no matter what but this is the result of the zypper in command.... maybe thats a reason because it conflicts with some differing named package etc ---------- zypper in openSUSE-build-key Loading repository data... Reading installed packages... Resolving package dependencies... Problem: the to be installed openSUSE-build-key-1.0-lp154.3.14.1.noarch conflicts with 'suse-build-key' provided by the installed suse-build-key-12.0-150000.8.34.1.noarch Solution 1: deinstallation of suse-build-key-12.0-150000.8.34.1.noarch Solution 2: do not install openSUSE-build-key-1.0-lp154.3.14.1.noarch ---------- i kind of give up. i had thought it would make sense and help the community overall to get these bugs fixed. but apparently (my?) real world scenario, namely that you always have life before a situation and you never only? always? start on a clean desk with freshly installed systems. this has quite often broken my neck and 'always' forced me to fix just way too many things when only doing small incremental things inside a suse release and then zypper dup towards its lifetimes end. apparently this all doesnt help and maybe you guys developers or the whole? user base of suse lives and acts differently from my life. anyhow thanks nevertheless nothing personal. maybe i am just not compatible. thanks for looking into this up til now and lets hope for the best for the next dup session and the next suse leap successor etc. we shall see.
i think this deeply long term migrated scenarios we do not support well. solution 1 should have solved it I think.