Bug 1212114 - unknown undecided new repository or package signing key received - zypper dup 15.4 to 15.5
Summary: unknown undecided new repository or package signing key received - zypper dup...
Status: REOPENED
Alias: None
Product: openSUSE Distribution
Classification: openSUSE
Component: Other (show other bugs)
Version: Leap 15.4
Hardware: x86-64 openSUSE Leap 15.4
: P5 - None : Major (vote)
Target Milestone: ---
Assignee: Marcus Meissner
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-06-07 17:27 UTC by andreas bittner
Modified: 2023-10-04 12:41 UTC (History)
0 users

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description andreas bittner 2023-06-07 17:27:49 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.
Comment 1 Andreas Stieger 2023-06-08 12:35:10 UTC
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.
Comment 2 Andreas Stieger 2023-06-08 13:28:04 UTC
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.
Comment 3 andreas bittner 2023-06-08 17:12:25 UTC
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.
Comment 4 Andreas Stieger 2023-06-08 17:35:55 UTC
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.
Comment 5 andreas bittner 2023-06-11 20:28:41 UTC
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.
Comment 6 Marcus Meissner 2023-06-12 07:23:09 UTC
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.
Comment 7 andreas bittner 2023-06-12 11:01:08 UTC
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.
Comment 8 andreas bittner 2023-06-12 13:00:33 UTC
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.
Comment 9 andreas bittner 2023-09-08 09:01:17 UTC
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.
Comment 10 Marcus Meissner 2023-09-08 09:11:59 UTC
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
Comment 11 andreas bittner 2023-09-08 09:16:11 UTC
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 .


--------------
Comment 12 andreas bittner 2023-09-27 14:22:29 UTC
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
Comment 13 Marcus Meissner 2023-09-27 14:31:08 UTC
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
Comment 14 andreas bittner 2023-10-04 12:30:11 UTC
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.
Comment 15 Marcus Meissner 2023-10-04 12:41:15 UTC
i think this deeply long term migrated scenarios we do not support well.

solution 1 should have solved it I think.