Bug 998207

Summary: Repo key extended - zypper keeps warning about old expiration date
Product: [openSUSE] openSUSE Tumbleweed Reporter: Dominique Leuenberger <dimstar>
Component: libzyppAssignee: E-mail List <zypp-maintainers>
Status: RESOLVED DUPLICATE QA Contact: E-mail List <qa-bugs>
Severity: Major    
Priority: P5 - None CC: dimstar, forgotten_l5HDYKT_qR, zaitor
Version: Current   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Dominique Leuenberger 2016-09-09 16:53:34 UTC
There is something fishy with the way zypp handles key changes inside a repo.

Example, GNOME:Next (published at http://download.opensuse.org/repositories/GNOME:/Next/openSUSE_Factory

while zypper is refreshing the repo, it claims:

Retrieving repository 'GNOME:Next' metadata -------------------------------------------------------------------------------------------------------[\]
The gpg key signing file 'repomd.xml' will expire in 14 days.
  Repository:       GNOME:Next                                        
  Key Name:         GNOME OBS Project <GNOME@build.opensuse.org>      
  Key Fingerprint:  D3CAF513 5D0A8F97 AB539ED3 65A86F31 629FF0C2      
  Key Created:      Tue 22 Jan 2008 21:46:00 CET                      
  Key Expires:      Fri 23 Sep 2016 23:47:08 CEST (expires in 14 days)
  Rpm Name:         gpg-pubkey-629ff0c2-47965608              

That is 'sort of' correct: this is the old key that WAS in the repo

but even what currently lies in zypp's cache does not match this info:
cat /var/cache/zypp/raw/GNOME:Next/repodata/repomd.xml.key | gpg
pub   dsa1024 2008-01-22 [SC] [expires: 2018-09-27]
      D3CAF5135D0A8F97AB539ED365A86F31629FF0C2
uid           GNOME OBS Project <GNOME@build.opensuse.org>

The KEY ID did not change, but the key validity has been extended

So in fact, everything should be normal and zypp should just accept the new fact (not changed fingerprints, not changed IDs

It just appears as zypp relies only on the rpm DB in this case which already contains this key (from an earlier import, as I'm using this repo for a long time already) 

The whole thing is confusing users and there was a thread on the -factory list not too long ago about the same effects in a different project (but I could not find the bug report for it)

All tests done on Tumbleweed
* libzypp-16.2.2-1.1.x86_64
* zypper-1.13.9-1.1.x86_64
Comment 1 Michael Andres 2016-09-12 08:15:54 UTC
Could you please check bug #993324, comment #4.

It looks like the latest gpg2 embeds garbage(?) lines in the output which disturbs the parser. Does the same happen on you system?
Comment 2 Dominique Leuenberger 2016-09-12 08:26:42 UTC
That seems indeed to be the case:

> /usr/bin/gpg2 --import --homedir /tmp/XXXXX --no-default-keyring --quiet --no-tty --no-greeting --no-permission-warning --status-fd 1 /var/cache/zypp/raw/GNOME\:Next/repodata/repomd.xml.key 
[GNUPG:] KEY_CONSIDERED D3CAF5135D0A8F97AB539ED365A86F31629FF0C2 0
[GNUPG:] IMPORTED 65A86F31629FF0C2 GNOME OBS Project <GNOME@build.opensuse.org>
[GNUPG:] IMPORT_OK 1 D3CAF5135D0A8F97AB539ED365A86F31629FF0C2
[GNUPG:] IMPORT_RES 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0
> /usr/bin/gpg2 --list-public-keys --homedir /tmp/XXXXX --no-default-keyring --quiet --with-colons --fixed-list-mode --with-fingerprint --with-sig-list --no-tty --no-greeting --batch --status-fd 1 
gpg: WARNING: unsafe permissions on homedir '/tmp/XXXXX'
tru::1:1473668728:0:3:1:5
pub:-:1024:17:65A86F31629FF0C2:1201034760:1538041187::-:::scSC:::::::
fpr:::::::::D3CAF5135D0A8F97AB539ED365A86F31629FF0C2:
uid:-::::1468921187::FD55A51127FF73B973E78F02E74A6F7591BF972F::GNOME OBS Project <GNOME@build.opensuse.org>:::::::::
sig:::17:65A86F31629FF0C2:1468921187::::[GNUPG:] KEY_CONSIDERED D3CAF5135D0A8F97AB539ED365A86F31629FF0C2 0
GNOME OBS Project <GNOME@build.opensuse.org>:13x:::::2:
sig:::17:3B3011B76B9D6523:1201034760::::[User ID not found]:13x:::::2:
Comment 3 Dominique Leuenberger 2016-09-12 08:30:02 UTC
KEY_CONSIDERED was introduced with gpg 2.1.13:
  * gpg: New status lines KEY_CONSIDERED and NOTATION_FLAGS.
Comment 4 Michael Andres 2016-09-12 08:51:03 UTC
But within --with-colons output?
Comment 5 Michael Andres 2016-09-12 09:49:40 UTC
.

*** This bug has been marked as a duplicate of bug 993324 ***