Bug 1725437
| Summary: | dirmngr endlessly receives service unavailable 503 error | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Stan King <stanley.king> | ||||
| Component: | gnupg2 | Assignee: | Red Hat Crypto Team <crypto-team> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 29 | CC: | bcl, crypto-team, tmraz, tmz | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | gnupg2-2.2.17-1.fc30 gnupg2-2.2.17-1.fc29 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2019-07-18 17:56:11 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Stan King
2019-06-30 15:56:35 UTC
Do you have the keys.fedoraproject.org specified in .gnupg/dirmngr.conf? In general I would recommend filling a bug in the upstream issue tracker at https://dev.gnupg.org/ as that would speed up the investigation and fix. Unless I am able to reproduce the problem locally I would be just a messenger. Tomas, I do not specify keys in .gnupg/dirmngr.conf. It's using the default value. keys.fedoraproject.org is resolving to CNAME keys01.fedoraproject.org., A 140.211.169.207, which is the host returning error 503. The whois command reports this IP range belongs to Network for Education and Research in Oregon (NERO), Eugene, OR. Contact information is provided there also. Aside from that element of the fedoraproject.org infrastructure providing an error code, the second problem is that dirmngr immediately retrying the operation that's doomed to fail, rather than delaying or trying another keys host. The CNAME of keys01.fedoraproject.org makes me think there was an intention to also have keys02, keys03, etc. and rotate among them as is done with pool.ntp.org, but that was not done. keys02.fedoraproject.org resolves to another IP within the same range as keys01. There is no keys03.fedoraproject.org. It seems strange that there's a dependency on a single IP range within the state of Oregon, given the international user base of Fedora. My logfile indicates that it's receiving commands from an instance of /usr/bin/gpg2 that seems to have been started by thunderbird, in the middle of the night. It is possible to run it manually from the command line. Just type "dirmngr", and after producing some output ending in "OK Dirmngr 2.2.13 at your service", it will await commands. The two commands you need to reproduce the behavior are KEYSERVER --clear hkps://keys.fedoraproject.org:443 and KS_GET -- 0x8657980D9AB51E50 after which you should see the effects of its retry loop. OK, I've created the upstream issue: https://dev.gnupg.org/T4600 Thank you, Tomas. I'm sure those who use dirmngr will appreciate it. Will you let the server continue to generate 503 until the software is fixed? Otherwise, how will we know if the problem is repaired? Do you have a test server than can provide error 503 on demand? Again, thank you for reporting this problem upstream. I'm just looking forward to verifying it when it comes downstream. Unfortunately I do not manage the broken keyserver. I suppose the gnupg upstream will test the fix appropriately. It looks like the dirmngr issue was fixed in the recently released gnupg-2.2.17. As far as keys.fedoraproject.org, it seems likely that the service will be discontinued, so anyone who has configured it in either gpg.conf or dirmngr.conf will need to adjust their configurations. References: https://pagure.io/fedora-infrastructure/issue/7988 (keys.fp.o is down?) https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/thread/G4WTK5J6VU6HVOSCNSVKL54GYU7IKZNE/ (Retire keys.fedoraproject.org?) FEDORA-2019-28a3675529 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-28a3675529 FEDORA-2019-2f259a6c0a has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-2f259a6c0a gnupg2-2.2.17-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-2f259a6c0a gnupg2-2.2.17-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-28a3675529 Unfortunately, I don't have an arrangement that can generate a 503 error to test this properly. gnupg2-2.2.17-1.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report. gnupg2-2.2.17-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report. |