[Bug 906589] New: multiple repos repeatedly/frequently reporting "signed with an unknown key"
http://bugzilla.opensuse.org/show_bug.cgi?id=906589 Bug ID: 906589 Summary: multiple repos repeatedly/frequently reporting "signed with an unknown key" Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: All OS: All Status: NEW Severity: Normal Priority: P5 - None Component: Infrastructure Assignee: mrueckert@suse.com Reporter: grantksupport@operamail.com QA Contact: lrupp@suse.com Found By: --- Blocker: --- We've upgraded all our opensuse instances to 13.2; currently several hundred across multiple sites. As we're doing post-upgrade cleanups, etc, on `zypper *` we're seeing LOTS of 'unknown key' messages for/from repositories, for example, @ refresh, zypper -v ref Verbosity: 1 Initializing Target Specified repositories: Checking whether to refresh metadata for Backup Retrieving: repomd.xml ................................................................................................................................................................................................................[done] Repository 'Backup' is up to date. Checking whether to refresh metadata for BaseSystem 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 'BaseSystem' is signed with an unknown key '88EB5D66E2C0098C'. Continue? [yes/no] (no): That ^^^ is just ONE example; most, if not yet all, enabled repos have returned this error at least once recently -- typically more often. This is NEW/CHANGED behavior. We're not alone -- we're hearing about this from multiple clients, and are bumping into similar issues/comments/questions online, in IRC, etc. This is happening for a broad variety of repos -- home: repos, 'semi-official' repos, *AND* official release/distribution repos. In any one run, there can be none-to-many repos that return the "signed with an unknown key" And, it's happening repeatedly & frequently. If I force clean up zypper clean --all rpm -qa | grep gpg-pubkey | xargs rpm -e zypper -vvv --gpg-auto-import-keys --no-gpg-checks ref --force then, an IMMEDIATELY subsequent `ref` or `dup`, of course, has no issues with unknown keys -- until "some time later". After a seemingly random amount of time -- just minutes to hours -- re-exec of the zypper cmd gets another mix of "unknown key" reports. For the example above, cat /etc/zypp/repos.d/BaseSystem.repo [BaseSystem] name=BaseSystem enabled=1 autorefresh=1 baseurl=http://download.opensuse.org/repositories/Base:/System/openSUSE_13.2 gpgcheck=1 keeppackages=0 priority=30 type=rpm-md Checking @ http://download.opensuse.org/repositories/Base:/System/openSUSE_13.2/repodat... Index of /repositories/Base:/System/openSUSE_13.2/repodata Icon Name Last modified Size [DIR] Parent Directory - [ ] 0ebcac183295ce4d1fde2c8f614bbe0fc481804c7948418a9ac0613ad16a5efe-primary.xml.gz 20-Nov-2014 14:48 23K Details [ ] 488fb3091c6e475a247d1b10a6035dafb05519f9fbd6ddaa5265c2826517b5d0-other.xml.gz 20-Nov-2014 14:48 25K Details [ ] d5fc3d48a3aa46cf156ac47421ec3d979ba0d7849fc503437701384455726e4b-filelists.xml.gz 20-Nov-2014 14:48 47K Details [TXT] repomd.xml 20-Nov-2014 14:48 1.6K Details [ ] repomd.xml.asc 20-Nov-2014 14:48 481 Details [ ] repomd.xml.key 20-Nov-2014 14:48 1.1K Details Apache/2.2.12 (Linux/SUSE) Server at download.opensuse.org Port 80 MirrorBrain powered by Apache it's clear there's a recent "Last Modified" change to the repodata ... I do not yet know if there ae ACTUAL changes, or only timestamps are changing. At first glance, it appears that with each change to the repo's content -- specifically the filelists -- the ENTIRE file content of the /repodata dir is being re-timestamped. Including the repomd.xml.key ... which would be ONE cause of the "unkonwn key" issue. It's *possible* that multiple repos have been compromised, and that blackhats are changing keys at will -- but I *seriously* doubt it; pls correct me if I'm wrong. (1) Why are multiple repos' keys changing so frequently -- even for the same repo, sometimes multiple times within a day or so? (2) There appears to be no mechanism/source for VALIDATING the new/updated keys from within a zypper command -- That's a potential security issue. How are keys to be validated? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=906589 --- Comment #1 from grant k <grantksupport@operamail.com> --- 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/r... ..........................................................................................[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/re... ...........................................................................................[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/r... ..........................................................................................[done] Retrieving: http://download.opensuse.org/repositories/server:/monitoring/openSUSE_13.2/r... ..........................................................................................[done] Retrieving: http://download.opensuse.org/repositories/server:/monitoring/openSUSE_13.2/r... ......................................................................................[done] Retrieving: http://download.opensuse.org/repositories/server:/monitoring/openSUSE_13.2/r... ......................................................................................[done] Retrieving: http://download.opensuse.org/repositories/server:/monitoring/openSUSE_13.2/r... ..........................................................................................[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/r... .......[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/re... ...........................................................................................[done] Retrieving: http://download.opensuse.org/repositories/systemsmanagement/openSUSE_13.2/re... ...........................................................................................[done] Retrieving: http://download.opensuse.org/repositories/systemsmanagement/openSUSE_13.2/re... .......................................................................................[done] Retrieving: http://download.opensuse.org/repositories/systemsmanagement/openSUSE_13.2/re... .......................................................................................[done] Retrieving: http://download.opensuse.org/repositories/systemsmanagement/openSUSE_13.2/re... ...........................................................................................[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/re... ......................[done] Retrieving repository 'SystemsMgmt' metadata ..........................................................................................................................................................................................[done] Building repository 'SystemsMgmt' cache ...............................................................................................................................................................................................[done] ... note that the re-retreived KeyIDs are the *same* -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=906589 --- Comment #2 from grant k <grantksupport@operamail.com> --- 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): ... -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=906589 Marcus Rückert <mrueckert@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |coolo@suse.com, | |hvogel@suse.com, | |mls@suse.com, ro@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=906589 grant k <grantksupport@operamail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mrueckert@suse.com Flags| |needinfo?(mrueckert@suse.co | |m) --- Comment #3 from grant k <grantksupport@operamail.com> --- 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? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=906589 --- Comment #4 from Marcus Rückert <mrueckert@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=906589 Marcus Rückert <mrueckert@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(mrueckert@suse.co | |m) | -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=906589 --- Comment #5 from grant k <grantksupport@operamail.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=906589 grant k <grantksupport@operamail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(mrueckert@suse.co | |m) --- Comment #6 from grant k <grantksupport@operamail.com> --- 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? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=906589 grant k <grantksupport@operamail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dmueller@suse.com, | |dvaleev@suse.com Flags| |needinfo?(dvaleev@suse.com) | |, | |needinfo?(dmueller@suse.com | |) --- Comment #7 from grant k <grantksupport@operamail.com> --- 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? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=906589 --- Comment #8 from grant k <grantksupport@operamail.com> --- 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 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=906589 --- Comment #9 from grant k <grantksupport@operamail.com> --- 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 :-/ -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=906589 --- Comment #10 from grant k <grantksupport@operamail.com> ---
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? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=906589 Michael Andres <ma@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ma@suse.com --- Comment #11 from Michael Andres <ma@suse.com> --- 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 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=906589 Marcus Meissner <meissner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |meissner@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=906589 --- Comment #12 from grant k <grantksupport@operamail.com> --- Created attachment 614736 --> http://bugzilla.opensuse.org/attachment.cgi?id=614736&action=edit 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" -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=906589 --- Comment #13 from grant k <grantksupport@operamail.com> --- 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 ... -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=906589 --- Comment #14 from grant k <grantksupport@operamail.com> --- 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 ... -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=906589 --- Comment #15 from Michael Andres <ma@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=906589 --- Comment #16 from grant k <grantksupport@operamail.com> --- Created attachment 614922 --> http://bugzilla.opensuse.org/attachment.cgi?id=614922&action=edit 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 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=906589 --- Comment #17 from Michael Andres <ma@suse.com> --- 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 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=906589 --- Comment #18 from grant k <grantksupport@operamail.com> ---
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/repodat... ............................................................................................[done] Retrieving: http://download.opensuse.org/repositories/devel:/tools/openSUSE_13.2/repodat... ............................................................................................[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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=906589 --- Comment #19 from Michael Andres <ma@suse.com> --- 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... -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=906589 --- Comment #20 from grant k <grantksupport@operamail.com> --- 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 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=906589 --- Comment #21 from grant k <grantksupport@operamail.com> --- 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? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=906589 --- Comment #22 from Michael Andres <ma@suse.com> --- (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... -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=906589 --- Comment #23 from grant k <grantksupport@operamail.com> ---
or you accidentally used the sed-patched libzypp with gpg-2.0.x
yep. PEBKAC. my bad :-/ -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=906589 Michael Andres <ma@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #24 from Michael Andres <ma@suse.com> --- . *** This bug has been marked as a duplicate of bug 908135 *** -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com