Summary: | emerge: long delay during refreshing keys over IPv6 | ||
---|---|---|---|
Product: | Mirrors | Reporter: | Anton Bolshakov <anton.bugs> |
Component: | Server Problem | Assignee: | Mirror Admins <mirror-admin> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | andy.dalton, bob.deblier, creideiki+gentoo-bugzilla, dev-portage, email, gentoo, leonchik1976, mirage, sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://dev.gnupg.org/T4729 https://github.com/projg2/gemato/issues/25 https://github.com/projg2/gemato/issues/26 https://bugs.gentoo.org/show_bug.cgi?id=873133 https://bugs.gentoo.org/show_bug.cgi?id=691666 https://bugs.gentoo.org/show_bug.cgi?id=647696 https://bugs.gentoo.org/show_bug.cgi?id=646194 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Anton Bolshakov
2021-04-02 01:15:37 UTC
there is also a problem with retrieving gpg key: bash$ gpg --debug all --auto-key-locate wkd -vvvvv --locate-keys developer@gentoo.org gpg: DBG: chan_5 <- OK Dirmngr 2.2.27 at your service gpg: DBG: connection to the dirmngr established gpg: DBG: chan_5 -> GETINFO version gpg: DBG: chan_5 <- D 2.2.27 gpg: DBG: chan_5 <- OK gpg: DBG: chan_5 -> WKD_GET -- developer@gentoo.org gpg: DBG: chan_5 <- S SOURCE https://gentoo.org gpg: DBG: chan_5 <- S PROGRESS tick ? 0 0 gpg: DBG: chan_5 <- S WARNING http_redirect_cleanup 0 changed from 'https://gentoo.org/.well-known/openpgpkey/hu/8ssm33j13uke6j94cmw3gbu58o49bf8z?l=developer' to 'https://www.gentoo.org/.well-known/openpgpkey/hu/8ssm33j13uke6j94cmw3gbu58o49bf8z?l=developer' gpg: WARNING: unacceptable HTTP redirect from server was cleaned up gpg: (further info: changed from 'https://gentoo.org/.well-known/openpgpkey/hu/8ssm33j13uke6j94cmw3gbu58o49bf8z?l=developer' to 'https://www.gentoo.org/.well-known/openpgpkey/hu/8ssm33j13uke6j94cmw3gbu58o49bf8z?l=developer') gpg: DBG: chan_5 <- S PROGRESS tick ? 0 0 gpg: DBG: chan_5 <- ERR 167772218 No data <Dirmngr> gpg: error retrieving 'developer@gentoo.org' via WKD: No data gpg: error reading key: No data gpg: DBG: chan_5 -> BYE I get same issue Same for me (In reply to Anton Bolshakov from comment #1) > there is also a problem with retrieving gpg key: > bash$ gpg --debug all --auto-key-locate wkd -vvvvv --locate-keys > developer@gentoo.org > I think you need to escape the @ somehow. Searching by name works, joe will retrieve my key. Are you still affected by this? (In reply to Alexey Shvetsov from comment #2) > I get same issue With what version? 2.2 branch alone has had numerous fixes that could have resolved these issues. From 2.2.35: * dirmngr: Make WKD lookups work for resolvers not handling SRV records. [T4729] The report on this specifically involves gentoo: https://dev.gnupg.org/T4729 From 2.2.34: dirmngr: Avoid initial delay on the first keyserver access in presence of --no-use-tor. [rGdde88897e2] I have gpg 2.2.41 and have this problem as well. # gpg --debug all --auto-key-locate wkd -vvvvv --locate-keys developer@gentoo.org gpg: reading options from '[cmdline]' gpg: using character set 'utf-8' gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog gpg: enabled compatibility flags: gpg: DBG: [not enabled in the source] start gpg: directory '/root/.gnupg' created gpg: DBG: fd_cache_invalidate (/root/.gnupg/pubring.kbx) gpg: DBG: iobuf-1.0: open '/root/.gnupg/pubring.kbx' desc=file_filter(fd) fd=3 gpg: DBG: iobuf-1.0: close 'file_filter(fd)' gpg: DBG: /root/.gnupg/pubring.kbx: close fd/handle 3 gpg: DBG: fd_cache_close (/root/.gnupg/pubring.kbx) new slot created gpg: DBG: iobuf-*.*: ioctl '/root/.gnupg/pubring.kbx' invalidate gpg: DBG: fd_cache_invalidate (/root/.gnupg/pubring.kbx) gpg: DBG: did (/root/.gnupg/pubring.kbx) gpg: keybox '/root/.gnupg/pubring.kbx' created gpg: /root/.gnupg/trustdb.gpg: trustdb created gpg: using pgp trust model gpg: DBG: [not enabled in the source] keydb_new gpg: DBG: [not enabled in the source] keydb_search enter gpg: DBG: keydb_search: 1 search descriptions: gpg: DBG: keydb_search 0: SUBSTR: 'developer@gentoo.org' gpg: DBG: keydb_search: searching keybox (resource 0 of 1) gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => EOF gpg: DBG: [not enabled in the source] keydb_search leave (not found) gpg: no running Dirmngr - starting '/usr/bin/dirmngr' gpg: waiting for the dirmngr to come up ... (5s) gpg: DBG: chan_5 <- # Home: /root/.gnupg gpg: DBG: chan_5 <- # Config: /root/.gnupg/dirmngr.conf gpg: DBG: chan_5 <- OK Dirmngr 2.2.41 at your service gpg: connection to dirmngr established gpg: DBG: chan_5 -> GETINFO version gpg: DBG: chan_5 <- D 2.2.41 gpg: DBG: chan_5 <- OK gpg: DBG: chan_5 -> WKD_GET -- developer@gentoo.org gpg: DBG: chan_5 <- S SOURCE https://openpgpkey.gentoo.org gpg: DBG: chan_5 <- ERR 167772218 No data <Dirmngr> gpg: error retrieving 'developer@gentoo.org' via WKD: No data gpg: error reading key: No data gpg: DBG: chan_5 -> BYE gpg: DBG: [not enabled in the source] stop gpg: keydb: handles=1 locks=0 parse=0 get=0 gpg: build=0 update=0 insert=0 delete=0 gpg: reset=0 found=0 not=1 cache=0 not=0 gpg: kid_not_found_cache: count=0 peak=0 flushes=0 gpg: sig_cache: total=0 cached=0 good=0 bad=0 gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 gpg: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0 gpg: secmem usage: 0/65536 bytes in 0 blocks Nothing helpful from gpg, though. Is there any way to set a timeout? Also, I noticed that `traceroute openpgpkey.gentoo.org` works while `traceroute6 openpgpkey.gentoo.org` doesn't: $ traceroute openpgpkey.gentoo.org traceroute to openpgpkey.gentoo.org (89.16.167.134), 30 hops max, 60 byte packets [...nodes omitted...] 18 te0-0-0-2.cr4.yrk.bytemark.co.uk (130.180.202.57) 157.861 ms 141.308 ms 140.387 ms 19 po1.ar2.dc1.yo26.yrk.bytemark.co.uk (91.223.58.33) 140.495 ms 140.481 ms 141.127 ms 20 * www.gentoo.org (89.16.167.134) 139.547 ms * $ traceroute6 openpgpkey.gentoo.org traceroute to openpgpkey.gentoo.org (2001:41c8:0:936::136), 30 hops max, 80 byte packets [...nodes omitted...] 14 te0-0-0-2.cr4.yrk.bytemark.co.uk (2001:41c8:0:10c::1) 138.821 ms 140.788 ms 139.801 ms 15 po1.ar2.dc1.yo26.yrk.bytemark.co.uk (2001:41c8:0:110::2) 133.374 ms 134.327 ms 134.405 ms 16 * * * [..."* * *" omitted...] 30 * * * Hit by this bug this morning as well: * Refreshing keys via WKD ... [ ok ] >>> Starting rsync with rsync://[2a00:1828:a00d:ffff::6]/gentoo-portage... >>> Checking server timestamp ... timed out rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(713) [Receiver=3.2.7] >>> Retrying... >>> Starting retry 1 of 3 with rsync://[2a01:90:200:10::1a]/gentoo-portage >>> Checking server timestamp ... timed out rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(713) [Receiver=3.2.7] >>> Retrying... >>> Starting retry 2 of 3 with rsync://89.238.71.6/gentoo-portage >>> Checking server timestamp ... Welcome to turnstone.gentoo.org / rsync.gentoo.org (In reply to Bob Deblier from comment #6) > Hit by this bug this morning as well: This sounds like a different problem - it's not do with refreshing keys hanging. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=9268a92b9666eaaf263999b18220c0d56d8c476c commit 9268a92b9666eaaf263999b18220c0d56d8c476c Author: Sam James <sam@gentoo.org> AuthorDate: 2023-08-13 04:36:04 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-08-17 06:52:55 +0000 sync: rsync, git: respect --debug for gemato Respect --debug and pass it down to gemato so we get nice debugging output when e.g. 'refreshing keys' is stuck. Bug: https://bugs.gentoo.org/646194 Bug: https://bugs.gentoo.org/647696 Bug: https://bugs.gentoo.org/691666 Bug: https://bugs.gentoo.org/779766 Bug: https://bugs.gentoo.org/873133 Bug: https://bugs.gentoo.org/906875 Bug: https://github.com/projg2/gemato/issues/7 Bug: https://github.com/projg2/gemato/issues/25 Signed-off-by: Sam James <sam@gentoo.org> lib/portage/sync/modules/git/git.py | 15 +++++++++++++-- lib/portage/sync/modules/rsync/rsync.py | 11 +++++++++-- lib/portage/sync/syncbase.py | 12 ++++++++---- 3 files changed, 30 insertions(+), 8 deletions(-) same here, works only after uncommenting "precedence ::ffff:0:0/96 100" in /etc/gai.conf |