"Those who would give up essential liberty to purchase a little temporary safety,
deserve neither liberty nor safety."
- Ben Franklin https://www.news.admin.ch/it/nsb?id=103968
I rather think that the problem is elsewhere.
If hkps://keys.gentoo.org was down for a week it would be all over the forum, bugzillia, the mailing lists ... and its not.
Are you able to fetch any keys at all from other key servers?
Try mine. 0x565FD335AADCE709 or any of the developers public keys.
Newer developers may not have their keys on public keyservers to avoid key poisoning but you will get a different error to No keyserver available.
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
My key is is useful to check that you can actually reach a keyserver and fetch the key.
Once you have it, you can verify that things I have signed have not been tampered with.
You can also use it to send me encrypted email, if you ever want to.
More tenuously, if you trust the people who have signed my key, you have an assurance that I am who I say I am.
My key is not useful for verifying the portage repo, but if you have it, it proves that hkps:// works for you.
This eliminates several elements of the puzzle.
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
I intermittently see similar key verification problems on my
machine. Most recently gpg has reported "Server indicated a failure"
rather than "No keyserver available", in otherwise-similar output.
WORKAROUND: I've found the best (most likely to eventually work)
general workaround to key sync problems is to restart my local DNS
server (/etc/init.d/named restart) and then try to "emerge --sync"
again. I may need to do this a few times before it works,
but usually it eventually works to iterate between these
steps.
Simply retrying "emerge --sync" does not usually work, nor does
the automatic retry it does if you just let it retry on its own.
This suggests that there is something about how DNS responses are sometimes
cached that doesn't interact well with gpg trying to validate keys.
Speculation: Perhap a combination of:
1. One or more of the matching IP addresses of the keyserver is
offline, unreachable, or misconfigured.
2. Cached DNS results return the same IP address first.
3. New uncached DNS results may re-order the list of IP
addresses semi-randomly.
4. If gpg tries to contact the bad IP address(es) first, it isn't
smart enough to try to fallback on other IP addresses from
the results list. Each retry will just retry the same bad IP
address until the list itself is re-ordered.
I don't know if this is the actual problem, but it matches the
high-level symptoms I've seen.
If it is the problem, then a real fix would be to have the key
sync code automatically try alternative IP addresses from the
hostname lookup, in sequence until something works.
Or a more complicated fix would be to implement the happy
eyeballs algorithm (see RFC 8305 or RFC 6555). Probably significantly
more complicated unless the application is already designed around
non-blocking I/O techniques and infrastructure, but it isn't strictly
needed either: Without happy eyeballs, a "try addresses in
sequence" algorithm ought to still work, even if the fallback cases
are annoyingly slow.
----------
I did make an attempt to try to valididate the above speculation,
but it quickly ballooned into a much deeper research project than I
was really interested in, and I did not actually validate it.
The following mostly-unorganized notes
from this effort might not be very useful, but just in case, I'll
write them up here:
1. Every "emerge --sync" attempt seems to start new process instances
of both "gpg-agent" and "dirmngr". I can killall both, but that doesn't
seem to affect later sync attempts either way.
2. When I try to capture actual DNS and sync traffic using wireshark,
it does not seem to be looking up "keys.gentoo.org" at all. I see it
recursively looking up parts of things like "openpgpkey.gentoo.org",
"_openpgpkey._tcp.gentoo.org", etc. Sometimes a "SRV" record rather
than "AAAA" or "A", for some reason. In a quick glance, I haven't
seen any immediately obvious differences between successfull and
unsuccessful attempts to sync keys.
- Is "hkps://keys.gentoo.org" a stale no-longer-correct message or
something?
3. The key sync problem seemed to grow a little more common when I
enabled IPv6 locally a few months ago. In my case this involved hacking
an additional service exectuable and scripts onto my router to handle the
relevant IPv6-PD (prefix delegation) requests and forwarding to the
route advertisement deamon. Someday I should document this.
But (1) everything else IPv6 related seems to work fine (IPv6 test
websites, pings, web browser default when connecting to dual stack
servers, etc), (2) even if my hack was broken, I would expect the
key sync to (eventually) fallback on an IPv4 address, even if it
was slow to fallback.
- If IPv6 is completely unavailable, the functions that do
hostname lookup will intentionally de-prioritize or eliminate IPv6
addresses from the results. But if IPv6 only seems to be available,
IPv6 may be early in the results, and it becomes the higher-level
application's responsibility to to try other addresses if IPv6
fails.
4. I'm not even sure exactly what is actually doing the key sync.
I would assume it might be some kind of invocation of "gpg" given
the repeating error message, but I don't see "gpg" in a "ps -aef"
listing: In pstree when gpg is repeating the failed message,
I see two "emerge -b /usr/lib/python-exec/python3.6/emerge --sync"
processes, one a child of the other, and I see "gpg-agent ..."
and "dirmngr ..." as children of "init", but I don't see "gpg".
- It would be nice to at least know how to run it "directly" for
unit testing and debugging, but I don't know how.
5. DNSSEC? I don't know if it is related ("Server indicated a failure",
not some kind of host lookup failure), but sometimes the "dig" program
returns no IP addresses for a lot of hosts, including keys.gentoo.org
google.com, etc, especially if already cached (i.e, I already looked
it up since restarting named). But "host", "nslookup", "ping",
firefox, etc, all work even if "dig" isn't working. It seems to be
correlated with key sync, but I haven't run enough tests to be
sure: dig works iff "emerge --sync" works. I don't know why. Maybe
it has something to do with DNSSEC, but if so, why does it sometimes
work, and everything else always works? I've never tries to figure
out how to setup DNSSEC-related settings in bind.
6. There are periodic forum posts about problems with syncing keys in
the forums, but very little about how to self-diagnose and fix
such problems. It seems insanely difficult to actually understand and
debug problems.
- Especially how to run it "directly", as mentioned above.
- I'm vaguely aware a new version of gnutls was needed a few
months ago, but I appear to be up-to-date. I tried re-emerging it
again just now, and initially it seemed to have helped the first
few attempts to reproduce the error by restarting named, but
ultimately some of the restarts are still in a broken state. The
intermittent nature of this problem is extremely annoying.
- If it was reliably failing instead of just intermittent, maybe
it would be a little easier to track down problems. But all the above
things suggest it still wouldn't be easy.
tuxbox /libbak/modules # unset http_proxy
tuxbox /libbak/modules # emerge --sync
>>> Syncing repository 'gentoo' into '/usr/portage'...
* Using keys from /usr/share/openpgp-keys/gentoo-release.asc
* Refreshing keys via WKD ... [ ok ]
>>> Starting rsync with rsync://160.116.15.34/gentoo-portage...
timed out
rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(642) [Receiver=3.1.3]
>>> Retrying...
>>> Starting retry 1 of 5 with rsync://81.91.253.252/gentoo-portage
^C
Exiting on signal Signals.SIGINT
