this is pretty hairy - and not really a 11.0 problem, but very likely a generic one.

libzypp keyring support delete key (but zypper nor libzypp use it), so update can be delete and add new key. Question is where allow user to do this? during refresh? or after expire fail?....so when update this key?

query rpm guru

Apart from not getting the pseudo gpg packages updated in the rpm database - are there any defects visible ? 

I suspect that the key verification engine only uses /usr/lib/rpm/gnupg/pubring.gpg - but not the pseudo gpg packages - for verification.

no, libzypp extracts the keys from the RPM db on the fly everytime, it does not use /usr/lib/rpm/gnupg/pubring.gpg

/usr/lib/rpm/gnupg/pubring.gpg is not even used in rpm4, IIRC is a rpm3 thing.

To see if a key is imported, the keyring uses the id to compare. If it is a new key, it should be offered for importing, if they have a new id, it should be handled as a completely separate key. libzypp will verify using the key used to sign the file, So I don't know what you mean by "updating".

What is your criteria to say "this is an updated key", the email address?

If you're wondering what the release is when you do 'rpm -qa gpg-pubkey', it's the key creation time. Probably this is also what should be used when to check if a key should be updated.
Another question is if the "old" key should be removed at all or just stay in the database.

I still don't understand. Same key with different timestamps is a different key. The verification should work.

I don't see why what to do with the old key is libzypp problem. If you add a repo using the old key, the key will need to be imported anyway.

The key expiration date was just extended, and only a new signature added to it.



Frankly, I would like to see the effect. We currently extract all keys
from the RPM DB in a seperate keyring and then use this to check stuff.
I guess that this export -> keyring will get all new GPG signatures and the
key extension just fine.

just try to downgrade the key in your rpm database.
yast will never really upgrade to the new one.

removing needinfo

You don't upgrade or downgrade keys in the rpm database, different versions of the keys go to different "rpm packages".

Sorry, but I don't understand what is this feature about. Please explain an story that describes what behavior are you expecting and what is the current behavior.

Wild guess: libzypp only checks if a keyid is already present in the keyring, it doesn't check the creation date like it should. So the key with the new expiry date never gets installed because libzypp thinks it's not needed.

Ok, that says something.

So, can anyone attach both keys so I can see how they are parsed by Pubkey.cc?

I know I get this:

pub:-:1024:17:A84EDAE89C800ACA:2000-10-19:2008-06-21::-:SuSE Package Signing Key <build@suse.de>:

And A84EDAE89C800ACA is the id. But I thought the timestamp was already in the id itself.

No, it's not. The creating date is printed after the id. You should use '--fixed-list-mode', so that you don't have to convert the date again. Note that gpg doesn't seem to substitute the uid in that case, though.
Also, you need the creation date from the first signature packet, not the subkey packet, because this (self-)signature packet contains the expiry date.

See /usr/lib/rpm/gnupg/dumpsigs for the ugly details.

well, info already provided.

in short:
if I have this key in my rpm-db:
 gpg-pubkey-9c800aca-40d8063e
I want it "updated" to
 gpg-pubkey-9c800aca-481f343a

the last part was what I read as sort of a release-number,
and that's why I called it an "update".

example files:
old: /mounts/schnell/CD-ARCHIVE/10.3/POOL/CD1/gpg-pubkey-9c800aca-40d8063e.asc
new: /mounts/dist/full/full-i386/gpg-pubkey-9c800aca-481f343a.asc

Any progress here? This is a shipment stopper for 11.0, as updates from older version will not get the new key, and the old one is expired.

Update: mls is trying to find out how to get the right creation date or expiration date from gpg, which seems impossible but rpm do it somehow. Then it would be a very little change to get this fixed (not updating or obsoleting old keys) but to import the new one as a new key.

fixed in 3.26.0

how difficult is this to backpoirt to 

the:
SLES10 SP1
SLES10 SP2
10.2
10.3

trees? We need it there too for bug 383544

It looks like this one is not in the 5.0 HEAD of libzypp submitted for STABLE.  Please add!

I have reasons to believe that the issue is not fixed in the prepared maintenance update for SLE10 SP1 + SP2:

ZYPP Patch No: 5382
MD5 sum: 77e54dfce946e47194bc6f7820a3c84b
SUBSWAMPID: 18314
packages: libzypp libzypp-devel

The keyring /usr/lib/rpm/gnupg/pubring.gpg is updated, but the rpm pseudo packages are not. After the update I still have:

boxer:~ # rpm -qi gpg-pubkey-9c800aca | gpg
pub  1024D/9C800ACA 2000-10-19 SuSE Package Signing Key <build@suse.de>
sub  2048g/8495160C 2000-10-19 [expires: 2008-06-21]

Attaching complete session log and YaST2 log in a minute.

Created attachment 225245 [details]
session log of installing suse-build-key with updated libzypp

Created attachment 225246 [details]
YaST2 log of updating suse-build-key with updated libzypp

The update I used to update the build keys is:

ZYPP Patch No: 5331
MD5 sum: 4913feefaf87026d0d592915b7749667
SUBSWAMPID: 17952
packages: suse-build-key

Created attachment 225829 [details]
fingerprint.patch

also check if the fingerprint matches before importing keys.

I tested it locally, it seems to work in the positive case. Did not test
a bad key though.


Please review and apply to all libzypp :/

Applied and submitted for SLES10-SP1 SLES10-SP2 11.0 10.3 10.2


(In reply to comment #29 from Heiko Rommel)
> The update I used to update the build keys is:
> 
> ZYPP Patch No: 5331
> MD5 sum: 4913feefaf87026d0d592915b7749667
> SUBSWAMPID: 17952
> packages: suse-build-key

Just updating suse-build-key does not help. AFAIK it does not put the key into the rpm database. You probably need to refresh the repo providing the updated key.

I tested the restarted maintenance update 

ZYPP Patch No: 5382
MD5 sum: 77e54dfce946e47194bc6f7820a3c84b
SUBSWAMPID: 18314
packages: libzypp libzypp-devel

today.

Just to rule out possible pilot errors here is how I tested the updated libzypp against this bug.

1) I made sure I have the correct build-keys installed:

zypp:~ # rpm -q suse-build-key
suse-build-key-1.0-685.6

zypp:~ # rpm -qa gpg-pubkey\*
gpg-pubkey-1fc2d149-485176f0
gpg-pubkey-a1912208-446a0899
gpg-pubkey-307e3d54-44201d5d
gpg-pubkey-c66b6eae-4491871e
gpg-pubkey-3d25d3d9-36e12d04
gpg-pubkey-0dfb3188-41ed929b
gpg-pubkey-a4466aa9-466db647
gpg-pubkey-9c800aca-40d8063e
gpg-pubkey-7e2e3b05-44748aba

zypp:~ # gpg --no-default-keyring --keyring /usr/lib/rpm/gnupg/pubring.gpg --list-key
/usr/lib/rpm/gnupg/pubring.gpg

pub   1024D/9C800ACA 2000-10-19 [expired: 2008-06-21]
uid                  SuSE Package Signing Key <build@suse.de>

pub   2048R/3D25D3D9 1999-03-06
uid                  SuSE Security Team <security@suse.de>

pub   1024D/0DFB3188 2005-01-18
uid                  Open Enterprise Server <support@novell.com>

pub   1024R/307E3D54 2006-03-21 [expired: 2008-06-21]
uid                  SuSE Package Signing Key <build@suse.de>

pub   4096R/A1912208 2006-05-16
uid                  Novell Provo Build (Contact security@novell.com) <novell-provo-build@novell.com>

pub   1024D/7E2E3B05 2006-05-24 [expired: 2008-05-23]
uid                  Novell Provo Build (Contact security@novell.com) <novell-provo-build@novell.com>

2) I installed the maintenance update for libzypp which updated the package to libzypp-2.32.2-0.3.1.

2) yast2 online_update restarted and I installed the current update of suse-build-key

ZYPP Patch No: 5331
MD5 sum: 4913feefaf87026d0d592915b7749667
SUBSWAMPID: 17952
packages: suse-build-key

which updated suse-build-key to suse-build-key-1.0-685.9.5

3) After that I checked if both the rpm keyring file and the rpm pseudo package has been properly updated:

zypp:~ # rpm -qi gpg-pubkey-9c800aca | gpg
pub  1024D/9C800ACA 2000-10-19 SuSE Package Signing Key <build@suse.de>
sub  2048g/8495160C 2000-10-19 [expires: 2008-06-21]

zypp:~ # gpg --no-default-keyring --keyring /usr/lib/rpm/gnupg/pubring.gpg --list-key
/usr/lib/rpm/gnupg/pubring.gpg

pub   1024D/9C800ACA 2000-10-19 [expires: 2010-05-05]
uid                  SuSE Package Signing Key <build@suse.de>
sub   2048g/8495160C 2000-10-19 [expires: 2010-05-05]

pub   2048R/3D25D3D9 1999-03-06
uid                  SuSE Security Team <security@suse.de>

pub   1024D/0DFB3188 2005-01-18
uid                  Open Enterprise Server <support@novell.com>

pub   1024R/307E3D54 2006-03-21 [expires: 2010-05-05]
uid                  SuSE Package Signing Key <build@suse.de>

pub   4096R/A1912208 2006-05-16
uid                  Novell Provo Build (Contact security@novell.com) <novell-provo-build@novell.com>

pub   1024D/7E2E3B05 2006-05-24 [expires: 2010-05-24]
uid                  Novell Provo Build (Contact security@novell.com) <novell-provo-build@novell.com>

-> FAILED, the rpm pseudo package is just the same but the rpm keyring file has been updated

Created attachment 226117 [details]
yast2 log when installing suse-build-key with update libzypp

these log files are with starting yast2 after

export Y2SLOG_DEBUG=1
export ZYPP_FULLLOG=1
export Y2MAXLOGSIZE=1073741824
export Y2MAXLOGNUM=20

Regarding Comment #32:

There seems to be no automatic refresh happening in 4 out of 7 cases:

sled10sp1-i386 (goodfellow.suse.de):    FAILED
sled10sp1-x86_64 (zypp.suse.de):        FAILED
sles10sp1-i386 (dax.suse.de):           PASSED
sles10sp1-ia64 (miracle.suse.de):       PASSED
sles10sp1-ppc (morgenrot.suse.de):      FAILED
sles10sp1-s390x (s390t11.suse.de):      FAILED
sles10sp1-x86_64 (fallada.suse.de):     PASSED

Using yast2 inst_source I verified that the update sources are using "Refresh=On" in all cases. Even restarting yast2 or rebooting did not help.

I tried to use the "Source Settings -> Refresh Now" but that didn't help either.

we need the other y2log-* files too, the one ion #c34 has not everything.



What i suspect however is that the repos are up-to-date during the update.
since they are up to date, they will not refresh after the libzypp update
and so not try to verify the new key.

I just logged into morgenrot (the machine the logs came from). I checked the repositories in use, and found the old key 

  KEY SHA1 30726e9a2959dbe9cace5765edd038e0538878ad
           gpg-pubkey-9c800aca-40d8063e.asc

on 

  SUSE Linux Enterprise Software Development Kit 10 SP1
  ftp://schnell.suse.de/CD-ARCHIVE/SLES10/SLE-10-SP1/SLE-10-SP1-SDK-GM/ppc/DVD1

  SUSE Linux Enterprise Server 10 SP1
  ftp://schnell.suse.de/CD-ARCHIVE/SLES10/SLE-10-SP1/SLES-10-SP1-GM/ppc/DVD1 

Both repositories do _NOT_ contain the updated key remote. So how should the key be updated, if no repository provides it?


(did you consider to use a patch script together with the suse-build-key patch, that introduces the key into the rpmdb?)

Its supposed to come from the update repository (nu.novell.com or you.suse.de in this case).

As we discussed on friday, it is not taken from the system GPG keyring at all, so suse-build-key is unrelated (but could be made to inject the key into the RPM DB).

Marcus and I just verified on morgenrot that 'zypper ref' and 'rug ref' import the new key, if the remote source actually changed and new metadata were downloaded.

So after updating libzypp one has to wait until one of the update repos changes again, or must manually delete the update repos cache directory below /var/lib/zypp/cache/ to trigger the download.

released

again released