Bug 283738

media problem?

at least /dist/install/SLP/openSUSE-10.3-Build402-KDE/i386/CD1 
looks fine. Which one exactly did you test ?

I'm installing Alpha5 (openSUSE-10.3-Alpha5-DVD-x86_64-Build402 according to media.1/build) and I also hit this issue:

1) During internet test, release-notes.rpm can't be installed b/c of the missing public key
2) When adding the factory inst source, I'm asked whether I trust build@suse.de (clicking the "Import" button works as Adrian wrote).

/ # rpm -q gpg-pubkey
package gpg-pubkey is not installed

Interestingly, the suse-build-key package is installed and the key is imported in /root/.gnupg. Also the system itself installed w/o any problem.

Created attachment 146276 [details]
y2logs

I think all informations are already inside, back to YaST

Duncan, could you please check whether this is a libzypp problem. I found some logging about unavailable key (RpmDb.cc(checkPackage):1517 Public key is unavailable. /tmp/YaST2-04973-vVfymY/1-release-notes.rpm{- 0644 0/0 size 32519}) in attached y2log-file.

*** Bug 290670 has been marked as a duplicate of this bug. ***

*** Bug 292402 has been marked as a duplicate of this bug. ***

I havent seen this in the latest builds

Did not see it in alpha7 too.

I haven't seen it either. I can't remember having seen an explicit fix, but it's gone

just installed build908 and there it's again

Created attachment 156323 [details]
new log file

what is the output of 

rpm -qa | grep gpg-pubkey

empty

Then nothing ZYpp can do. ZYpp reads rpm database and puts its keys in the ZYpp trusted keyring.

Steffen, which component is responsible to install those rpm keys?

All I do is to copy /usr/lib/rpm/gnupg/suse-build-key.gpg as /installkey.gpg
into the instsys (bug 164001). And that's unchanged for some time now.

We changed from gpg to gpg2 some weeks ago, maybe that's the difference?

comment #16: During installation, either zypp or yast have to 'install' the keys into the rpm database. This seems to be broken, if "rpm -q gpg-pubkey" reports no keys.

ZYpp does not perform key installation unless YaST tells it to do it, so please, this bug seems to be YaST related.

The log file in #13 is the chroot only. This does not give enough information about what was happening with the keys during the installation.

Stephan, do you still have y2log-1 around from that installation? Best would be to attach the logs using save_y2log.

No, I haven't.

Nevermind ;-)

A bit of analysis:
- the key is properly imported at the beginning of the installation, otherwise the import popup would be shown at the beginning already. So, YaST correctly imports the key into libzypp keyring.

- the key is not available during 2nd stage, it is not stored in the rpm database.

IMO the problem must be somewhere in the code where libzypp writes the key into the target system rpm database.

Created attachment 157399 [details]
y2logs

I cannot find a call to import the keys into rpm database.

KeyRingSignals callbacks has 2 recievers: 
* target RPM database
* pkg-bindings

This might be a problem, ask pkg-bindings are the 2nd one to be registered, thus they win.

KeyRingSignals::trustedKeyAdded() is the only way used by target to put new gpg keys into the database.

*** Bug 277117 has been marked as a duplicate of this bug. ***

I did an installation this morning and didn't hit this bug. Please feel free to reopen, in case you are still able to reproduce.

Christoph, how did you test? Which media and how did you access them?

I used /mounts/machcd2/iso/openSUSE-10.3-Beta1-GNOME-i386-Build20070820-CD1.iso -- in QEmu.

I will test it again here. 

Christoph: you better test a DVD before you burn this bug ;(

I am seeing this with the final i386 downloadable DVD.

The process was install -> test internet connection (ok) -> register (failed because connection broke down) -> finish installation -> shutdown -> boot next day -> try to register (online update registration dialog) -> warning message "Signed with untrusted key: The file /var/tmp/TmpFile.PBW0dl is digitally signed with key 'A84EDAE89C800ACA' (SuSE Package Signing Key <build@suse.de>)'. There is no trust relationship to the owner of the key." with buttons "Trust and import" and "Skip".

Created attachment 182771 [details]
y2logs

Interesting fact: The keyring of user root has the key available.
#gpg --list-sigs --with-fingerprint
/root/.gnupg/pubring.gpg
------------------------
pub   1024D/9C800ACA 2000-10-19 [expires: 2008-06-21]
      Key fingerprint = 79C1 79B2 E1C8 20C1 890F  9994 A84E DAE8 9C80 0ACA
uid                  SuSE Package Signing Key <build@suse.de>
sig 3        9C800ACA 2004-06-22  SuSE Package Signing Key <build@suse.de>
sig          000AABA4 2001-01-25  [User ID not found]
sig          3D25D3D9 2001-01-25  [User ID not found]
sub   2048g/8495160C 2000-10-19 [expires: 2008-06-21]
sig          9C800ACA 2004-06-22  SuSE Package Signing Key <build@suse.de>

pub   1024R/307E3D54 2006-03-21 [expires: 2008-06-21]
      Key fingerprint = 4E98 E675 19D9 8DC7 362A  5990 E3A5 C360 307E 3D54
uid                  SuSE Package Signing Key <build@suse.de>
sig 3        307E3D54 2006-03-21  SuSE Package Signing Key <build@suse.de>

#rpm -qa "gpg-pub*"
gpg-pubkey-0dfb3188-41ed929b
gpg-pubkey-307e3d54-44201d5d
gpg-pubkey-3d25d3d9-36e12d04
gpg-pubkey-7e2e3b05-44748aba
gpg-pubkey-9c800aca-40d8063e
gpg-pubkey-a1912208-446a0899

Steffen, do you import the key in linuxrc?

No, linuxrc does not do anything with gpg keys.

.

I haven't seen this in GM

Because the LATER and REMIND resolutions have been removed, the resolution of this bug has changed from REMIND to WONTFIX. If this bug needs to be reconsidered, reopen it and set a future "Target Milestone for Fix."