|
Bugzilla – Full Text Bug Listing |
| Summary: | multiple repos repeatedly/frequently reporting "signed with an unknown key" | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE.org | Reporter: | Forgotten User dBpEIsMMD7 <forgotten_dBpEIsMMD7> |
| Component: | Infrastructure | Assignee: | Marcus Rückert <mrueckert> |
| Status: | RESOLVED DUPLICATE | QA Contact: | Lars Vogdt <lars.vogdt> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | coolo, dmueller, dvaleev, hvogel, ma, meissner, mls, mrueckert, ro |
| Version: | unspecified | Flags: | forgotten_dBpEIsMMD7:
needinfo?
(mrueckert) forgotten_dBpEIsMMD7: needinfo? (dvaleev) |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
zypper.log tail for test case
zypper log tail for test case w/ == yes |
||
|
Description
Forgotten User dBpEIsMMD7
2014-11-21 13:54:33 UTC
output from a forced refresh on an add'l-repo-loaded dev machine: timestamp of exec date Thu Nov 20 07:52:12 PST 2014 noting the key intake(s), zypper -vvv --gpg-auto-import-keys --no-gpg-checks ref --force 2>&1 out.txt grep -i warning out.txt -A0 -B1 Entering 'no-gpg-checks' mode. ... -- Retrieving: http://download.opensuse.org/repositories/server:/monitoring/openSUSE_13.2/repodata/repomd.xml ..........................................................................................[done] Warning: Accepting file 'repomd.xml' from repository 'SvrMonitor' signed with an unknown key 'A5C23697EE454F98'. -- Retrieving: http://download.opensuse.org/repositories/systemsmanagement/openSUSE_13.2/repodata/repomd.xml ...........................................................................................[done] Warning: Accepting file 'repomd.xml' from repository 'SystemsMgmt' signed with an unknown key '2ABFA143A0E46E11'. -- ... then, < 1 hr later, date Thu Nov 20 08:36:13 PST 2014 zypper -vvv ref ... Checking whether to refresh metadata for SvrMonitor Retrieving: http://download.opensuse.org/repositories/server:/monitoring/openSUSE_13.2/repodata/repomd.xml ..........................................................................................[done] Retrieving: http://download.opensuse.org/repositories/server:/monitoring/openSUSE_13.2/repodata/repomd.xml ..........................................................................................[done] Retrieving: http://download.opensuse.org/repositories/server:/monitoring/openSUSE_13.2/repodata/repomd.xml.asc ......................................................................................[done] Retrieving: http://download.opensuse.org/repositories/server:/monitoring/openSUSE_13.2/repodata/repomd.xml.key ......................................................................................[done] Retrieving: http://download.opensuse.org/repositories/server:/monitoring/openSUSE_13.2/repodata/repomd.xml ..........................................................................................[done] File 'repomd.xml' from repository 'SvrMonitor' is signed with an unknown key 'A5C23697EE454F98'. Continue? [yes/no] (no): y Retrieving: http://download.opensuse.org/repositories/server:/monitoring/openSUSE_13.2/repodata/740353b95c3ed8066c80e50837a5a59aca91b0beb11a1f0c357041ac91571863-primary.xml.gz .......[done (188.7 KiB/s)] Retrieving repository 'SvrMonitor' metadata ...........................................................................................................................................................................................[done] Building repository 'SvrMonitor' cache ................................................................................................................................................................................................[done] Checking whether to refresh metadata for SystemsMgmt Retrieving: http://download.opensuse.org/repositories/systemsmanagement/openSUSE_13.2/repodata/repomd.xml ...........................................................................................[done] Retrieving: http://download.opensuse.org/repositories/systemsmanagement/openSUSE_13.2/repodata/repomd.xml ...........................................................................................[done] Retrieving: http://download.opensuse.org/repositories/systemsmanagement/openSUSE_13.2/repodata/repomd.xml.asc .......................................................................................[done] Retrieving: http://download.opensuse.org/repositories/systemsmanagement/openSUSE_13.2/repodata/repomd.xml.key .......................................................................................[done] Retrieving: http://download.opensuse.org/repositories/systemsmanagement/openSUSE_13.2/repodata/repomd.xml ...........................................................................................[done] File 'repomd.xml' from repository 'SystemsMgmt' is signed with an unknown key '2ABFA143A0E46E11'. Continue? [yes/no] (no): y Retrieving: http://download.opensuse.org/repositories/systemsmanagement/openSUSE_13.2/repodata/14fd48eec25bab337b095c7d09d43b0fd9484e91eabf13f374f514de1d22c8e5-primary.xml.gz ......................[done] Retrieving repository 'SystemsMgmt' metadata ..........................................................................................................................................................................................[done] Building repository 'SystemsMgmt' cache ...............................................................................................................................................................................................[done] ... note that the re-retreived KeyIDs are the *same* NOT restricted to non-official repos, ... Checking whether to refresh metadata for OS13-update Retrieving: repomd.xml ........................................................................................[done] Retrieving: repomd.xml ........................................................................................[done] Retrieving: repomd.xml.asc ....................................................................................[done] Retrieving: repomd.xml.key ....................................................................................[done] Retrieving: repomd.xml ........................................................................................[done] File 'repomd.xml' from repository 'OS13-update' is signed with an unknown key 'B88B2FD43DBDC284'. Continue? [yes/no] (no): ... fwiw, rather than changing Severity/Priority, a comment -- this has escalated into a CustSvc nightmare, generating hundreds of contacts/inquiries -- ironically, after training users to never blindly accept such notices/upgrades, they are doing exactly what they've been asked to do. a trivial issue, with a mounting $cost. We're temporarily resolving it by imposing a global ban of zypper actions until we get this calmed down. It's entirely possible that we've a globally-consitent misconfiguration somewhere, but, I suspect it's not on our end. SOME comment would be appreciated -- ideas? I checked a most of the key IDs from your error messages. and they all match the repositories keys. how did you install those systems? it seems your auto import keys is not functioning. hi > how did you install those systems? The vast majority of systems in place are recent upgrades from 13.1 -> 13.2 Some are upgrades directly from 12.3 -> 13.2 A very few are new 13.2 installs. I'm seeing this repo mis-behavior across the entire sample set, above. > it seems your auto import keys is not functioning. If that were the case, then this zypper clean --all rpm -qa | grep gpg-pubkey | xargs rpm -e zypper -vvv --gpg-auto-import-keys --no-gpg-checks ref --force zypper -vvv ref would immediately fail for each & every repo, no? Atm, it does not. After "Some Time" passes, only some repos fail. It cursorily appears that those that fail have seen a recent update of repo file content -- with corresponding new timestamps -- and that the keys themseleves are similarly, new-timestamped. I'll dig around to see if/how I can provie to myself that the auto-import is/isn't failing. testing an example cat /etc/zypp/repos.d/OS13-update.repo [OS13-update] enabled=1 name=OS13-update baseurl=http://download.opensuse.org/update/13.2 autorefresh=1 gpgcheck=1 keeppackages=0 priority=90 type=rpm-md 1st, it's up to date zypper -vvv --gpg-auto-import-keys --no-gpg-checks ref --force zypper -v ref OS13-update Verbosity: 1 Non-option program arguments: 'OS13-update' Initializing Target Specified repositories: OS13-update Checking whether to refresh metadata for OS13-update Retrieving: repomd.xml ........................................................................................[done] Repository 'OS13-update' is up to date. Specified repositories have been refreshed. cleaning triggers the re-get zypper clean --all OS13-update Specified repositories have been cleaned up. zypper -v ref OS13-update Verbosity: 1 Non-option program arguments: 'OS13-update' Initializing Target Specified repositories: OS13-update Checking whether to refresh metadata for OS13-update Retrieving: repomd.xml.asc ....................................................................................[done] Retrieving: repomd.xml.key ....................................................................................[done] Retrieving: repomd.xml ........................................................................................[done] File 'repomd.xml' from repository 'OS13-update' is signed with an unknown key 'B88B2FD43DBDC284'. Continue? [yes/no] (no): yes Retrieving: d98c78f2f551c4920ee214f795fdd446098784ae450fa206245a2fc241fa8dc8-updateinfo.xml.gz ................[done] Retrieving: 0ce8d8a4080d4d92b7c56d7a9ec7b91b1fe4fb578d118c9594fa3949dec52946-primary.xml.gz ......[done (86.8 KiB/s)] Retrieving: 7da6924f039f480ef9542e1670c452ad305a76cff9aa09781c91d80b17df3b17-deltainfo.xml.gz .................[done] Retrieving repository 'OS13-update' metadata ..................................................................[done] Building repository 'OS13-update' cache .......................................................................[done] Specified repositories have been refreshed. brute-force clean of gpg data killall gpg-agent cd /root/.gnupg rm -rf \ secring.gpg \ private-keys-v1.d/ \ agent.info \ .gpg-v21-migrated \ pubring.gpg \ trustdb.gpg \ crls.d/ re-init gpg --list-keys gpg: keybox '/root/.gnupg/pubring.kbx' created gpg: /root/.gnupg/trustdb.gpg: trustdb created check after re-init ls -al total 40K drwx------ 4 root root 4.0K Nov 21 13:13 ./ drwx------ 112 root root 12K Nov 21 13:03 ../ drwx------ 2 root root 4.0K Nov 18 05:38 crls.d/ -rw-rw-rw-+ 1 root root 471 Nov 20 21:58 gpg-agent.conf -rw-rw-rw- 1 root root 1.7K Nov 20 21:16 gpg.conf drwxrwxrwx 2 root root 4.0K Feb 15 2011 private-keys-v1.d/ -rw------- 1 root root 32 Nov 21 13:13 pubring.kbx srwxrwxr-x 1 root root 0 Nov 18 05:38 S.dirmngr= srwxr-xr-x 1 root root 0 Nov 21 13:08 S.gpg-agent= -rw------- 1 root root 40 Nov 21 13:13 trustdb.gpg NOTE the change: pubring.gpg -> pubring.kbx force a refresh, supposedly with auto-import ON, zypper -vvv --gpg-auto-import-keys --no-gpg-checks ref --force all keys are re-retrieved ... no interaction, or errors recheck ls -al /root/.gnupg total 40K drwx------ 4 root root 4.0K Nov 21 13:13 ./ drwx------ 112 root root 12K Nov 21 13:03 ../ drwx------ 2 root root 4.0K Nov 18 05:38 crls.d/ -rw-rw-rw-+ 1 root root 471 Nov 20 21:58 gpg-agent.conf -rw-rw-rw- 1 root root 1.7K Nov 20 21:16 gpg.conf drwxrwxrwx 2 root root 4.0K Feb 15 2011 private-keys-v1.d/ -rw------- 1 root root 32 Nov 21 13:13 pubring.kbx srwxrwxr-x 1 root root 0 Nov 18 05:38 S.dirmngr= srwxr-xr-x 1 root root 0 Nov 21 13:08 S.gpg-agent= -rw------- 1 root root 40 Nov 21 13:13 trustdb.gpg there's NO changes in any gpg data. that seems wrong. fwiw, kbxutil -vvv pubring.kbx BEGIN-RECORD: 0 Length: 32 Type: Header Version: 1 Flags: 0002 (openpgp) created-at: 1416604432 last-maint: 1416604432 END-RECORD kbxutil --stats pubring.kbx Total number of blobs: 1 header: 1 empty: 0 openpgp: 0 x509: 0 non flagged: 0 secret flagged: 0 ephemeral flagged: 0 > prove to myself that the auto-import is/isn't failing I haven't managed that, but I am a bit confused by the above. Is there a specific test that'd answer the question -- does zypper's key auto-import work correctly? clean a single repo
zypper clean --all OS13-update
tracing its' refresh
strace zypper -v ref OS13-update
the grep'ing the output, I note a couple of lines
grep -i key tmp.txt
open("/lib64/libkeyutils.so.1", O_RDONLY|O_CLOEXEC) = 3
lstat("/var/cache/zypp/raw/OS13-update3BEeJF/repodata/repomd.xml.key", {st_mode=S_IFREG|0644, st_size=988, ...}) = 0
unlink("/var/cache/zypp/raw/OS13-update3BEeJF/repodata/repomd.xml.key") = 0
??? openat(AT_FDCWD, "/var/lib/rpm/pubkeys", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
??? openat(AT_FDCWD, "/var/lib/rpm/pubkeys", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/var/cache/zypp/raw/OS13-update7VOndN/repodata/repomd.xml.key", 0x7fff967c53e8) = -1 ENOENT (No such file or directory)
...
stat("/var/cache/zypp/raw/OS13-update/repodata/repomd.xml.key", 0x7fff967c5488) = -1 ENOENT (No such file or directory)
...
open("/var/cache/zypp/raw/repo-update-non-oss/repodata/repomd.xml.key", O_RDONLY) = 4
open("/var/adm/mount/AP_0xwjFA7t/repodata/repomd.xml.key.new.zypp.xaOotT", O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0600) = 4
stat("/var/adm/mount/AP_0xwjFA7t/repodata/repomd.xml.key", 0x7fff967c4908) = -1 ENOENT (No such file or directory)
write(1, "Retrieving: repomd.xml.key [", 28) = 28
write(4, "-----BEGIN PGP PUBLIC KEY BLOCK-"..., 988) = 988
pread(4, "-----BEGIN PGP PUBLIC KEY BLOCK-"..., 255, 0) = 255
open("/var/adm/mount/AP_0xwjFA7t/repodata/repomd.xml.key.new.zypp.xaOotT", O_RDONLY|O_CLOEXEC) = 6
pread(6, "-----BEGIN PGP PUBLIC KEY BLOCK-"..., 255, 0) = 255
rename("/var/adm/mount/AP_0xwjFA7t/repodata/repomd.xml.key.new.zypp.xaOotT", "/var/adm/mount/AP_0xwjFA7t/repodata/repomd.xml.key") = 0
stat("/var/adm/mount/AP_0xwjFA7t/repodata/repomd.xml.key", {st_mode=S_IFREG|0644, st_size=988, ...}) = 0
Retrieving: repomd.xml.key [..done]
lstat("/var/adm/mount/AP_0xwjFA7t/repodata/repomd.xml.key", {st_mode=S_IFREG|0644, st_size=988, ...}) = 0
lstat("/var/cache/zypp/raw/OS13-update7VOndN/repodata/repomd.xml.key", 0x7fff967c5498) = -1 ENOENT (No such file or directory)
??? link("/var/adm/mount/AP_0xwjFA7t/repodata/repomd.xml.key", "/var/cache/zypp/raw/OS13-update7VOndN/repodata/repomd.xml.key") = -1 EXDEV (Invalid cross-device link)
stat("/var/adm/mount/AP_0xwjFA7t/repodata/repomd.xml.key", {st_mode=S_IFREG|0644, st_size=988, ...}) = 0
stat("/var/cache/zypp/raw/OS13-update7VOndN/repodata/repomd.xml.key", 0x7fff967c5378) = -1 ENOENT (No such file or directory)
stat("/var/adm/mount/AP_0xwjFA7t/repodata/repomd.xml.key", {st_mode=S_IFREG|0644, st_size=988, ...}) = 0
unlink("/var/adm/mount/AP_0xwjFA7t/repodata/repomd.xml.key") = 0
stat("/var/cache/zypp/raw/OS13-update7VOndN/repodata/repomd.xml.key", {st_mode=S_IFREG|0644, st_size=988, ...}) = 0
stat("/var/cache/zypp/raw/OS13-update7VOndN/repodata/repomd.xml.key", {st_mode=S_IFREG|0644, st_size=988, ...}) = 0
stat("/var/cache/zypp/raw/OS13-update7VOndN/repodata/repomd.xml.key", {st_mode=S_IFREG|0644, st_size=988, ...}) = 0
stat("/var/cache/zypp/raw/OS13-update7VOndN/repodata/repomd.xml.key", {st_mode=S_IFREG|0644, st_size=988, ...}) = 0
open("/var/cache/zypp/raw/OS13-update7VOndN/repodata/repomd.xml.key", O_RDONLY) = 4
read(4, "-----BEGIN PGP PUBLIC KEY BLOCK-"..., 8191) = 988
lstat("/var/cache/zypp/raw/OS13-update7VOndN/repodata/repomd.xml.key", {st_mode=S_IFREG|0644, st_size=988, ...}) = 0
??? link("/var/cache/zypp/raw/OS13-update7VOndN/repodata/repomd.xml.key", "/var/tmp/TmpFile.IxTfvC") = -1 EXDEV (Invalid cross-device link)
stat("/var/cache/zypp/raw/OS13-update7VOndN/repodata/repomd.xml.key", {st_mode=S_IFREG|0644, st_size=988, ...}) = 0
read(4, "-----BEGIN PGP PUBLIC KEY BLOCK-"..., 8191) = 988
mkdir("/var/tmp/zypp.0sJZDK/fake-keyringGpXehV", 0700) = 0
lstat("/var/tmp/zypp.0sJZDK/fake-keyringGpXehV", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
stat("/var/tmp/zypp.0sJZDK/fake-keyringGpXehV", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
openat(AT_FDCWD, "/var/tmp/zypp.0sJZDK/fake-keyringGpXehV", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4
lstat("/var/tmp/zypp.0sJZDK/fake-keyringGpXehV/pubring.kbx", {st_mode=S_IFREG|0600, st_size=32, ...}) = 0
unlink("/var/tmp/zypp.0sJZDK/fake-keyringGpXehV/pubring.kbx") = 0
rmdir("/var/tmp/zypp.0sJZDK/fake-keyringGpXehV") = 0
...
digging around,
ls -al /var/lib/rpm/pubkeys
ls: cannot access /var/lib/rpm/pubkeys: No such file or directory
but there IS, noting the case difference,
ls -al /var/lib/rpm/*ubkeys
-rw-r--r-- 1 root root 12K Nov 28 2011 /var/lib/rpm/Pubkeys
also,
link("/var/cache/zypp/raw/OS13-update7VOndN/repodata/repomd.xml.key", "/var/tmp/TmpFile.IxTfvC") = -1 EXDEV (Invalid cross-device link)
not sure whether that's causal. but on our machines, /var/cache is always on a separate mount
mount | egrep "/var/cache"
/dev/mapper/VG1-VARCACHE on /var/cache type ext4 (rw,noatime,nobarrier,stripe=512,data=ordered)
iiuc, hardlinks cannot be created between different partitions, only symlinks can
if that link is being created by zypper as a HARD link, then that's a possible problem. is it?
reading http://www.gnu.org/software/libc/manual/html_node/Hard-Links.html http://www.gnu.org/software/libc/manual/html_node/Symbolic-Links.html link() does, in fact, hard-link whereas the alternative symlink() would provide the symbolic link, viable across devices testing on a machine with NO separate partition for /var/cache, (1) there are NO more "Invalid cross-device link" errors in the strace output (2) the key re-DL'ing issue continues as originally reported above. stumped until I hear from others :-/ > NOTE the change: pubring.gpg -> pubring.kbx exploring that change -- incl 'why' and what effect is has on this ^^^ issue ... reading https://www.gnupg.org/documentation/manuals/gnupg/kbxutil.html "... 11.1.1 Scrutinizing a keybox file A keybox is a file format used to store public keys along with meta information and indices. The commonly used one is the file pubring.kbx in the .gnupg directory. It contains all X.509 certificates as well as OpenPGP keys[1]. ... Footnotes [1] Well, OpenPGP keys are not implemented, gpg still used the keyring file pubring.gpg ..." I'm simply confused by that info. Is/isn't pubring.gpg expected/required -- by GnuPG &.or by zypper? And is the apparent lack of a pubring.gpg, with only a pubring.kbx present, a problem? Please attach the zypper logfile /var/log/zypper.log (or an older and compressed /var/log/zypper.log-YYYYMMDD.xz or .bz2) that shows the reported behavior. To see the execution dates and zypper commands included in a logfile you can install the zypper-log package (available since zypper-1.6.11) and execute:
zypper-log -l <logfile>
NOTE: zypper-log prior to 1.8.1 is not able to read lzma compressed logfiles (.xz). In this case you can use `xzgrep` to find the execution dates and zypper commands:
grep main.cc /var/log/zypper.log
xzgrep main.cc /var/log/zypper.log-*.xz
bzgrep main.cc /var/log/zypper.log-*.bz2
zgrep main.cc /var/log/zypper.log-*.gz
Created attachment 614736 [details]
zypper.log tail for test case
for a simple test case with 2 repos -- 'OS13-update' & 'Tools' -- current requiring key re-DL, where
ls -1 /etc/zypp/repos.d/*
/etc/zypp/repos.d/OS13-update.repo
/etc/zypp/repos.d/Tools.repo
where, currently,
Index of /update/13.2/repodata
Icon Name Last modified Size [DIR] Parent Directory -
[ ] 0cb96c112dff58d3bf6071855a05d54da3445c914367f8f49af9e992bbe2a116-deltainfo.xml.gz 24-Nov-2014 11:26 48K Details
[ ] 435c89d7c55b2b992133ccbf272eb09c3f0646e2663e2313b9f73338f18920a1-filelists.xml.gz 24-Nov-2014 11:25 848K Details
[ ] 3213a721e93ae15c3c468e5d98c62a578a277358dfa9c48791b5b5cd737b06dc-updateinfo.xml.gz 24-Nov-2014 11:25 48K Details
[ ] c8f2c224601f29527f4f51788ac8dec83de10e9736898818d44d94f4758707d3-suseinfo.xml.gz 24-Nov-2014 11:26 102 Details
[ ] de2a082b081a8595574fce5fb1a1778be530a5183678e6d37c0d00fe36a627ad-primary.xml.gz 24-Nov-2014 11:25 257K Details
[ ] f8df4e5565e2a46df2ba01dcf262ab136b1b6c0325d85956d19f11cd34ef34ec-other.xml.gz 24-Nov-2014 11:25 484K Details
[TXT] repomd.xml 24-Nov-2014 11:26 2.8K Details
[ ] repomd.xml.asc 24-Nov-2014 11:26 481 Details
[ ] repomd.xml.key 24-Nov-2014 11:26 1.0K Details
Apache/2.2.12 (Linux/SUSE) Server at download.opensuse.org Port 80
MirrorBrain powered by Apache
and
Index of /repositories/devel:/tools/openSUSE_13.2/repodata
Icon Name Last modified Size [DIR] Parent Directory -
[ ] 0d504e355ec2c27215598d909b8caa433b3a4ab61ad00c44d6a3fa4cd473e910-filelists.xml.gz 24-Nov-2014 14:23 208K Details
[ ] 0efdcf158dc96f2eb7d3604dd56de43468b2dec716284bad9e0aa6394de772f6-other.xml.gz 24-Nov-2014 14:23 150K Details
[ ] 973f85d826768f2c58b04dade487947c38d961ea2e49bb152cdd6391c8daea76-primary.xml.gz 24-Nov-2014 14:23 137K Details
[TXT] repomd.xml 24-Nov-2014 14:23 1.6K Details
[ ] repomd.xml.asc 24-Nov-2014 14:23 189 Details
[ ] repomd.xml.key 24-Nov-2014 14:23 1.0K Details
Apache/2.2.12 (Linux/SUSE) Server at download.opensuse.org Port 80
MirrorBrain powered by Apache
log tail from
zypper -vvv ref OS13-update Tools
answering 'no' to both
"Continue? [yes/no]"
is attached as "test.zypper.log"
I believe this _may_ be due to our use of GPG release v2.1.0. We've apparently switched to (now) full/official release for a number of client-required issues -- two of note are access to the new modular architecture, and, most importantly (here) ECC support for local and inter-/intra-company file signing, encryption, etc. Whether local install is (1) src build from gnupg upstream 2.1.0 release tarball (2) local rpm build from tumbleweed/factory Base:System's gpg srpm (3) rpm install from obs-build of branched tumbleweed/factory Base:System the issue, is present and consistently mis-behaves as reported above for GPG 2.1.x use OTHER than zypper, it's been very robust, to date afaict, there's NO 'official' opensuse pkg'ing of v2.1.0 although there's no indication of a gpg error that I've noticed in the zypper.log tail I'd attached, on a test machine, downgrading back to rpm -qa | grep -i gpg2 gpg2-2.0.26-13.1.x86_64 gpg2-lang-2.0.26-13.1.noarch in my first few -- not exhaustive -- tests, with the 2.0.x release, when a repos' contents change, the existing gpg key is NOT re-dl'd. With 2.1.x, as above, when those contents change, the gpg key IS re-DL'd, after being recognized as 'unknown' If this proves to be the cause, with GPG 2.1.0 in full/productuib release, 2.1.1 on its way "real soon now", and ~2.2.2 becoming the new 'stable' GPG @ upstream, ,ight be time to start fussing about this 'officially' ... before it hits the fan more broadly. talking @ gpg IRC with devs, tools 'should be' gpg-version agnostic. it appears that zypper use isn't completely ... yet. still poking around ... downgraded a test group of 10 machines to gpg 2.0.x, opensuse pkg'd. none are misbehaving after a couple of hours have passed ... it the same time, with the same repos, the gpg 2.1.x machines ARE having issues. note, that on the 2.1.x boxes, after a zypper clean --all a zypper ref required each & every repos' gpg key to be re-DL'd, with interactive approval (yes/no) whereas after the same cmd exec on a 2.0.x box, no such problem: zypper clean --all All repositories have been cleaned up. zypper -v ref Verbosity: 1 Initializing Target Specified repositories: Checking whether to refresh metadata for Backup Retrieving: repomd.xml.asc ....................................................................................[done] Retrieving: repomd.xml.key ....................................................................................[done] Retrieving: repomd.xml ........................................................................................[done] Repository: Backup Key Name: Archiving OBS Project <Archiving@build.opensuse.org> Key Fingerprint: F532523A DE4BBF1C BFF6523F 6B7485DB 725A0C43 Key Created: Thu 11 Oct 2012 08:22:15 AM PDT Key Expires: Sat 20 Dec 2014 07:22:15 AM PST (expires in 25 days) Rpm Name: gpg-pubkey-725a0c43-5076e427 Retrieving: 5f6b14d6c6f7ea50cf3dc91375181fe1ee591fe03182d5dcfee07aa3811c75a2-primary.xml.gz ...................[done] Retrieving repository 'Backup' metadata .......................................................................[done] Building repository 'Backup' cache ............................................................................[done] Checking whether to refresh metadata for BaseSystem Retrieving: repomd.xml.asc ....................................................................................[done] Retrieving: repomd.xml.key ....................................................................................[done] Retrieving: repomd.xml ........................................................................................[done] Repository: BaseSystem Key Name: Base:System OBS Project <Base:System@build.opensuse.org> Key Fingerprint: 9B76956C 9465B30D 7364090D 88EB5D66 E2C0098C Key Created: Tue 05 Feb 2013 05:40:55 AM PST Key Expires: Thu 16 Apr 2015 06:40:55 AM PDT Rpm Name: gpg-pubkey-e2c0098c-51110be7 ... Looking at the log from comment#12 there are no errors so far. > $ grep Key test.zypper.log > 2014-11-24 05:58:56 <1> gk1(21113) [zypp::KeyRing] KeyRing.cc(Impl):176 Current KeyRing::DefaultAccept: 0000000000 > 2014-11-24 05:58:56 <1> gk1(21113) [zypp] RpmDb.cc(syncTrustedKeys):965 Going to sync trusted keys... > 2014-11-24 05:58:56 <1> gk1(21113) [zypp] RpmDb.cc(syncTrustedKeys):969 Rpm keys to export into zypp trusted keyring: 0 > 2014-11-24 05:58:56 <1> gk1(21113) [zypp] RpmDb.cc(syncTrustedKeys):970 Zypp trusted keys to import into rpm database: 0 > 2014-11-24 05:58:56 <1> gk1(21113) [zypp] RpmDb.cc(syncTrustedKeys):1019 Trusted keys synced. It looks like there are no trusted keys stored in the rpm database (check with rpm -qa 'gpg-pubkey*'). > 2014-11-24 05:58:58 <1> gk1(21113) [zypp] PublicKey.cc(Impl):307 Taking pubkey from /var/cache/zypp/raw/OS13-updateLjSa8t/repodata/repomd.xml.key of size 988 and sha1 f7a25091290faa78bd47849f4b5238e4ee648236 > 2014-11-24 05:58:58 <1> gk1(21113) [zypp] PublicKey.cc(readFromFile):347 Reading pubkey from /var/tmp/TmpFile.UUPtIw of size 988 and sha1 f7a25091290faa78bd47849f4b5238e4ee648236 > 2014-11-24 05:58:58 <1> gk1(21113) [zypp] PublicKey.cc(readFromFile):397 Read pubkey from /var/tmp/TmpFile.UUPtIw: [B88B2FD43DBDC284-53674dd4] [openSUSE Project Signing Key <opensuse@opensuse.org>] [22C07BA534178CD02EFE22AAB88B2FD43DBDC284] [TTL 3446] > 2014-11-24 05:58:59 <1> gk1(21113) [zypp::KeyRing] KeyRing.cc(verifyFileSignatureWorkflow):373 Going to verify signature for repomd.xml ( /var/cache/zypp/raw/OS13-updateLjSa8t/repodata/repomd.xml ) with /var/cache/zypp/raw/OS13-updateLjSa8t/repodata/repomd.xml.asc > 2014-11-24 05:58:59 <1> gk1(21113) [zypp::KeyRing] KeyRing.cc(readSignatureKeyId):567 Determining key id if signature /var/cache/zypp/raw/OS13-updateLjSa8t/repodata/repomd.xml.asc > 2014-11-24 05:58:59 <1> gk1(21113) [zypp::KeyRing] KeyRing.cc(readSignatureKeyId):612 Determined key id [B88B2FD43DBDC284] for signature /var/cache/zypp/raw/OS13-updateLjSa8t/repodata/repomd.xml.asc > 2014-11-24 05:58:59 <1> gk1(21113) [zypp::KeyRing] KeyRing.cc(publicKeyExists):301 Searching key [B88B2FD43DBDC284] in keyring /var/tmp/zypp.8YO46w/zypp-trusted-krhw1kNd > 2014-11-24 05:58:59 <1> gk1(21113) [zypp::KeyRing] KeyRing.cc(publicKeyExists):301 Searching key [B88B2FD43DBDC284] in keyring /var/tmp/zypp.8YO46w/zypp-general-krtrsBtU > 2014-11-24 05:58:59 <1> gk1(21113) [zypp::KeyRing] KeyRing.cc(verifyFileSignatureWorkflow):477 File [/var/cache/zypp/raw/OS13-updateLjSa8t/repodata/repomd.xml] ( repomd.xml ) signed with unknown key [B88B2FD43DBDC284] > 2014-11-24 05:59:04 <1> gk1(21113) [zypp::KeyRing] KeyRing.cc(verifyFileSignatureWorkflow):485 User does not want to accept unknown key B88B2FD43DBDC284 Trusted keys from the rpm database would have been imported into the 'zypp-trusted' keyring. Keys you temporarily accept would go to the 'zypp-general' keyring. Both keyrings are empty, so the key is unknown and needs to be confirmed. > 2014-11-24 05:59:05 <1> gk1(21113) [zypp] PublicKey.cc(Impl):307 Taking pubkey from /var/cache/zypp/raw/ToolswnzCDp/repodata/repomd.xml.key of size 1003 and sha1 123d8c16811bd1cc3c68a467c3a92b2c8d2e3386 > 2014-11-24 05:59:05 <1> gk1(21113) [zypp] PublicKey.cc(readFromFile):347 Reading pubkey from /var/tmp/TmpFile.rhP5DU of size 1003 and sha1 123d8c16811bd1cc3c68a467c3a92b2c8d2e3386 > 2014-11-24 05:59:05 <1> gk1(21113) [zypp] PublicKey.cc(readFromFile):397 Read pubkey from /var/tmp/TmpFile.rhP5DU: [868EA2EB32567F38-50757861] [devel:tools OBS Project <devel:tools@build.opensuse.org>] [8BE2DD6EBB28D2578A36828C868EA2EB32567F38] [TTL 24] > ... > 2014-11-24 05:59:10 <1> gk1(21113) [zypp::KeyRing] KeyRing.cc(verifyFileSignatureWorkflow):485 User does not want to accept unknown key 868EA2EB32567F38 Same for 868EA2EB32567F38. Now it would be interesting to have a log where you permanently accept a key and we can see whether it's actually imported into the rpmdb. Or a log where the trusted key was in the rpmdb and you nevertheless were asked to accept it. If such logs are available, please attach them. Created attachment 614922 [details] zypper log tail for test case w/ == yes returning to gpg --version gpg (GnuPG) 2.1.0 libgcrypt 1.6.2 after having downgraded to gpg 2.0.x, > Now it would be interesting to have a log where you permanently accept a key and we can see whether it's actually imported into the rpmdb. this ^^ , atm, I have repeating the test, forcing a clean, but accepting the 'Continue' <-- yes zypper clean --all zypper -v log output tail -f zypper.log is attached as test2.zypper.log > Or a log where the trusted key was in the rpmdb and you nevertheless were asked to accept it. if still needed, will have to let some time pass Thanks, I think I've got it, it's indeed (pubring.gpg -> pubring.kbx). Key cache refresh is waiting for a change in pubring.gpg. If you're brave, a test/workaround could be: - Backup /usr/lib64/libzypp.so.1306.4.4 (your .so.version is probably differernt) - `strings /usr/lib64/libzypp.so.1306 | grep pubring` should show a single 'pubring.gpg' - `sed -i 's/pubring\.gpg/pubring.kbx/' /usr/lib64/libzypp.so.1306 > a test/workaround could be: I've v1429 ls -al /usr/lib64/libzypp* lrwxrwxrwx 1 root root 15 Nov 9 18:02 /usr/lib64/libzypp.so -> libzypp.so.1429* lrwxrwxrwx 1 root root 19 Nov 9 17:50 /usr/lib64/libzypp.so.1429 -> libzypp.so.1429.0.4* -rwxr-xr-x 1 root root 4.8M Oct 15 11:18 /usr/lib64/libzypp.so.1429.0.4* one instance strings /usr/lib64/libzypp.so.1429.0.4 | grep pubring pubring.gpg changed sed -i 's/pubring\.gpg/pubring.kbx/' /usr/lib64/libzypp.so.1429.0.4 strings /usr/lib64/libzypp.so.1429.0.4 | grep pubring pubring.kbx repeating with 2-repo test gpg --version gpg (GnuPG) 2.1.0 libgcrypt 1.6.2 ... zypper clean --all zypper -vvv ref Verbosity: 3 Initializing Target Specified repositories: Checking whether to refresh metadata for OS13-update Retrieving: http://download.opensuse.org/update/13.2/repodata/repomd.xml.asc ........................................................................................................................[done] Retrieving: http://download.opensuse.org/update/13.2/repodata/repomd.xml.key ........................................................................................................................[done] Retrieving repository 'OS13-update' metadata .........................................................................................................................................................................................[error] Repository 'OS13-update' is invalid. [OS13-update|http://download.opensuse.org/update/13.2] Valid metadata not found at specified URL History: - File /var/tmp/TmpFile.F05fw7 doesn't contain public key data Please check if the URIs defined for this repository are pointing to a valid repository. Skipping repository 'OS13-update' because of the above error. Checking whether to refresh metadata for Tools Retrieving: http://download.opensuse.org/repositories/devel:/tools/openSUSE_13.2/repodata/repomd.xml.asc ............................................................................................[done] Retrieving: http://download.opensuse.org/repositories/devel:/tools/openSUSE_13.2/repodata/repomd.xml.key ............................................................................................[done] Retrieving repository 'Tools' metadata ...............................................................................................................................................................................................[error] Repository 'Tools' is invalid. [Tools|http://download.opensuse.org/repositories/devel:/tools/openSUSE_13.2] Valid metadata not found at specified URL History: - File /var/tmp/TmpFile.kJT0BC doesn't contain public key data Please check if the URIs defined for this repository are pointing to a valid repository. Skipping repository 'Tools' because of the above error. Could not refresh the repositories because of errors. Good news is that the cache is now working. But it looks like there are some more changes in 2.1.0... I need to get a new gpg package... fyi, for now, this works https://build.opensuse.org/package/show?project=home%3Apgnd%3Agpg2&package=gpg2 it simply branches Base:System's gpg2 for 13.2 fyi, even with gpg --version gpg (GnuPG) 2.0.26 libgcrypt 1.6.2 I notice, e.g. zypper -v dup ... Checking whether to refresh metadata for MediaApps Retrieving: repomd.xml ................................................................................................................................................................................................................[done] Retrieving: repomd.xml ................................................................................................................................................................................................................[done] Retrieving: repomd.xml.asc ............................................................................................................................................................................................................[done] Retrieving: repomd.xml.key ............................................................................................................................................................................................................[done] Retrieving: repomd.xml ................................................................................................................................................................................................................[done] New repository or package signing key received: Repository: MediaApps Key Name: multimedia OBS Project <multimedia@build.opensuse.org> Key Fingerprint: 01FB54D4 EAF87B0F 5624266B 5F3D540F 3A802234 Key Created: Wed 21 May 2014 02:04:08 PM PDT Key Expires: Fri 29 Jul 2016 02:04:08 PM PDT Rpm Name: gpg-pubkey-3a802234-537d14c8 Do you want to reject the key, trust temporarily, or trust always? [r/t/a/? shows all options] (r): ... so, WHY is that repo getting a "New repository or package signing key" ? Checking, both the 'main' repo, Index of /repositories/multimedia:/apps/openSUSE_13.2/repodata Icon Name Last modified Size [DIR] Parent Directory - [ ] 3e49d56308b8b1bc86e6959810784dd05212edf72309161edd2dca817935d43a-app-icons.tar.gz 27-Nov-2014 20:26 22K Details [ ] 12b6d5e97ce334c91153af0eb61fafebcc3356018dd035cd388e987bf14ab050-filelists.xml.gz 27-Nov-2014 20:26 717K Details [ ] 176dec0bb9018624afece974d116af178bb39b9afb90879890109811d2d27ad6-primary.xml.gz 27-Nov-2014 20:26 247K Details [ ] 7339fbd3c2685f39a3d7907e1cdff121f0b5882546bc1aeb17a20cef4f4f8588-appdata.xml.gz 27-Nov-2014 20:26 4.4K Details [ ] abd1ce2e154a61067d510611ae274f5182d449292887880f0f9b8d1d321897f9-other.xml.gz 27-Nov-2014 20:26 370K Details [TXT] repomd.xml 27-Nov-2014 20:26 2.4K Details [ ] repomd.xml.asc 27-Nov-2014 20:26 189 Details [ ] repomd.xml.key 27-Nov-2014 20:26 1.0K Details Apache/2.2.12 (Linux/SUSE) Server at download.opensuse.org Port 80 MirrorBrain powered by Apache and an arbitrarily selected mirror, Index of /mirrors/download.opensuse.org/repositories/multimedia:/apps/openSUSE_13.2/repodata Icon Name Last modified Size Description[DIR] Parent Directory - [ ] 3e49d56308b8b1bc86e6959810784dd05212edf72309161edd2dca817935d43a-app-icons.tar.gz 27-Nov-2014 19:26 22K [ ] 12b6d5e97ce334c91153af0eb61fafebcc3356018dd035cd388e987bf14ab050-filelists.xml.gz 27-Nov-2014 19:26 717K [ ] 176dec0bb9018624afece974d116af178bb39b9afb90879890109811d2d27ad6-primary.xml.gz 27-Nov-2014 19:26 247K [ ] 7339fbd3c2685f39a3d7907e1cdff121f0b5882546bc1aeb17a20cef4f4f8588-appdata.xml.gz 27-Nov-2014 19:26 4.4K [ ] abd1ce2e154a61067d510611ae274f5182d449292887880f0f9b8d1d321897f9-other.xml.gz 27-Nov-2014 19:26 370K [TXT] repomd.xml 27-Nov-2014 19:26 2.4K [TXT] repomd.xml.asc 27-Nov-2014 19:26 189 [TXT] repomd.xml.key 27-Nov-2014 19:26 1.0K Apache/2.2.12 (Linux/SUSE) Server at anorien.csc.warwick.ac.uk Port 80 have the same key data ... recently timestamped, if not changed. Why is this (or any such ...) repo getting 'new' keys? Is it intended, or is it a bug? (In reply to grant k from comment #21) > so, WHY is that repo getting a "New repository or package signing key" ? Authority for trusted keys on your system is the rpm databbase, namely the gpg-pubkey (pseudo) packages. (rpm -qai gpg-pubkey) > New repository or package signing key received: > Repository: MediaApps > Key Name: multimedia OBS Project .... > Key Fingerprint: 01FB54D4 EAF87B0F 5624266B 5F3D540F 3A802234 > Key Created: Wed 21 May 2014 02:04:08 PM PDT > Key Expires: Fri 29 Jul 2016 02:04:08 PM PDT > Rpm Name: gpg-pubkey-3a802234-537d14c8 The fingerprints last 8 byte make the gpg-pubkey packages version. The key is known and trusted if we have gpg-pubkey-3a802234 in the rpm database. If the rpm data base does not contain gpg-pubkey-3a802234, the key is NEW and you are asked to confirm it. If you accept the key it is imported into the rpm database. After this, gpg-pubkey-3a802234 is present and you don't have to confirm it again, until it is removed from the rpm database (rpm -e gpg-pubkey-3a802234). If the server side did not change, the key was most probably not in the rpm database (or you accidentally used the sed-patched libzypp with gpg-2.0.x). A zypper.log could tell... > or you accidentally used the sed-patched libzypp with gpg-2.0.x
yep. PEBKAC. my bad :-/
. *** This bug has been marked as a duplicate of bug 908135 *** |