Hide Forgot
Description of problem: In our CI we have noticed that when we update nettle one of our libraries fails. Version-Release number of selected component (if applicable): Update nettle to 3.8-1.fc36 How reproducible: gnutls_certificate_credentials_t creds = NULL; int r = gnutls_certificate_allocate_credentials (&creds); assert (r == GNUTLS_E_SUCCESS); The assert fails.
Could you provide a complete reproducer? I cannot reproduce the issue with: [root@164e77eefd44 ~]# rpm -qa nettle gnutls nettle-3.8-1.fc36.x86_64 gnutls-3.7.6-1.fc36.x86_64 [root@164e77eefd44 ~]# cat test.c #include <gnutls/gnutls.h> #include <assert.h> int main (void) { gnutls_certificate_credentials_t creds = NULL; int r = gnutls_certificate_allocate_credentials(&creds); assert(r == GNUTLS_E_SUCCESS); return 0; } [root@164e77eefd44 ~]# gcc -o test test.c `pkg-config gnutls --cflags --libs` [root@164e77eefd44 ~]# ./test ; echo $? 0
Matej: This failure happens in our crypto-policies tests -- possibly you need to set a particular policy, or even enable FIPS?
> This failure happens in our crypto-policies tests -- possibly you need to set a particular policy, or even enable FIPS? That sounds plausible; while gnutls_certificate_allocate_credentials merely calls out malloc/calloc functions, it can return error if the library is already in an unusable state, e.g., when FIPS self-tests are failed. In any case it would be helpful to collect debug logs with GNUTLS_DEBUG_LEVEL as described in: https://www.gnutls.org/manual/html_node/Debugging-and-auditing.html#Debugging-and-auditing
Ah, I think I found the cause: gnutls recently switched the FIPS library integrity calculation to including all dependent libraries (including nettle), which is stored at: /usr/lib64/.gnutls.hmac: https://gitlab.com/gnutls/gnutls/-/issues/1338 After installing a newer nettle (or gmp), without updating the file there will be a mismatch. I don't think we have a proper way to fix it other than rebuilding gnutls, but a workaround would be to set the GNUTLS_SKIP_FIPS_INTEGRITY_CHECKS envvar to 1.
FEDORA-2022-b5e4fe1515 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-b5e4fe1515
FEDORA-2022-b5e4fe1515 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-b5e4fe1515` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-b5e4fe1515 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
*** Bug 2100400 has been marked as a duplicate of this bug. ***
Can't you create gating tests for nettle, gnutls etc. which just executes GNUTLS_FORCE_FIPS_MODE=1 certtool Then you would detect issues earlier ...
Tried to follow https://docs.fedoraproject.org/en-US/ci/gating with https://src.fedoraproject.org/rpms/nettle/pull-request/6
FEDORA-2022-b5e4fe1515 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
Indeed it was in FIPS mode. Just removing mine needsinfo. Thank you for fixing it!