Bugzilla – Bug 1205789
[Build 20221127] openQA test fails in dirmngr_daemon (fips)
Last modified: 2022-11-30 13:56:27 UTC
## Observation dirmngr[2199.0]: trusted certificate '/etc/gnupg/trusted-certs/root-ca.crt.der' loaded dirmngr[2199.0]: permanently loaded certificates: 142 dirmngr[2199.0]: runtime cached certificates: 0 dirmngr[2199.0]: trusted certificates: 142 (141,1,0,0) dirmngr[2199.0]: failed to open cache dir file '/root/.gnupg/crls.d/DIR.txt': No such file or directory dirmngr[2199.0]: creating directory '/root/.gnupg/crls.d' dirmngr[2199.0]: new cache dir file '/root/.gnupg/crls.d/DIR.txt' created dirmngr[2199.0]: error setting up MD5 hash context: Invalid digest algorithm 5B5dD-1- openQA test in scenario opensuse-Tumbleweed-JeOS-for-kvm-and-xen-x86_64-jeos-fips@64bit_virtio fails in [dirmngr_daemon](https://openqa.opensuse.org/tests/2910602/modules/dirmngr_daemon/steps/21) ## Test suite description ## Reproducible Fails since (at least) Build [20221127](https://openqa.opensuse.org/tests/2910314) ## Expected result Last good: [20221126](https://openqa.opensuse.org/tests/2908533) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&flavor=JeOS-for-kvm-and-xen&machine=64bit_virtio&test=jeos-fips&version=Tumbleweed)
Yes, MD5 is not FIPS an approved hash algorithm, its non-FIPS compliant. I understand that these set of tests are run in FIPS mode, right? If that's the case, these test should be adapted to not use MD5. I could reproduced it, see the debug output for this: > dirmngr[24224.0]: gcry_md_open for algorithm 1 failed: Invalid digest algorithm > dirmngr[24224.0]: crl_parse_insert failed: Invalid digest algorithm
OK, I'm answering myself, so the bug title also mentions FIPS ;) I'm adding @Marcus in CC.
(In reply to Pedro Monreal Gonzalez from comment #1) > Yes, MD5 is not FIPS an approved hash algorithm, its non-FIPS compliant. I > understand that these set of tests are run in FIPS mode, right? If that's > the case, these test should be adapted to not use MD5. Keep in mind: the test did not change in quite some time and passed (so either it wrongly accepted MD5 in fips mode or some code change is responsible) The snapshot first showing the error was the one where libgcrypt was updated to 1.10.1 (sr#1038228)
(In reply to Dominique Leuenberger from comment #3) > (In reply to Pedro Monreal Gonzalez from comment #1) > > Yes, MD5 is not FIPS an approved hash algorithm, its non-FIPS compliant. I > > understand that these set of tests are run in FIPS mode, right? If that's > > the case, these test should be adapted to not use MD5. > > Keep in mind: the test did not change in quite some time and passed (so > either it wrongly accepted MD5 in fips mode or some code change is > responsible) > > The snapshot first showing the error was the one where libgcrypt was updated > to 1.10.1 (sr#1038228) Yes, MD5 has been marked as non approved in FIPS mode for 1.10.x. This has been done in the context of the FIPS 140-3 adaption of the code. For reference, here is the upstream commit: * https://dev.gnupg.org/rCce1cbe16992a7340edcf8e6576973e3508267640 I'm not sure who to assign the bug for further adaption in QA testing script.
The previous reference was on hold until 1.10.x, see also the upstream taks for 140-3 in https://dev.gnupg.org/T5244
Created attachment 863169 [details] tar ball extracted from SUT
Thanks, Dominique. I could finally reproduce it. The issue is that libgcrypt has disabled MD5 in FIPS mode and dirmngr fails setting the CRL cache record as it needs to calculate the MD5 sum of the cache file in dirmngr/crlcache.c:hash_dbfile(). It fails when trying to set up the MD5 hash context. I'll open a bug report upstream.
Reported upstream: https://dev.gnupg.org/T6291
Upstream has partially adapted gnupg2 to the MD5 FIPS deprecation in libgcrypt, see [0,1,2]. Note that, MD5 is only used for fingerprints and not for cryptographic relevant use but there are still a couple of places in the code where MD5 is used and could lead to unexpected failures in FIPS mode. I'm not sure why upstream has closed the reported bug [3] as wontfix since they have committed to disable it in FIPS mode for libgcrypt. I can compose a patch to fix this in our side or we can enable in FIPS mode for now. [0] https://dev.gnupg.org/rGc4436ebfa58f219190f1244928001b4293293343 [1] https://dev.gnupg.org/rG1f0651dbfbabb80adf5685da0049f15da97f6175 [2] https://dev.gnupg.org/rG310b064f5271fe8566ebc996702ea1422875f425 [3] https://dev.gnupg.org/T6291