Bugzilla – Bug 1213636
[SLES15SP4][SECURITY][FIPS][Build 191.4] openQA test core dumps in gpg in FIPS mode
Last modified: 2023-09-07 08:26:56 UTC
openQA test in scenario sle-15-SP4-Online-QR-x86_64-fips_env_mode_tests_crypt_tool@64bit fails in [gpg](https://openqa.suse.de/tests/11657280/modules/gpg/steps/54) with "gpg: Ohhhh jeeee: ... this is a bug (seskey.c:50:make_session_key)" Fails since Build [191.4](https://openqa.suse.de/tests/11607682) Last good: [190.2](https://openqa.suse.de/tests/11052114) Always latest result in this scenario: https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=Online-QR&machine=64bit&test=fips_env_mode_tests_crypt_tool&version=15-SP4 This is when using the QU3.1 the candidate installer, and does not happen when running standard GA installation + maintenance updates. The failure happens both in FIPS environment mode (linked) and kernel mode (see eg https://openqa.suse.de/tests/11608572#step/gpg/50) As of this time, we've not been able to manually to reproduce the problem locally (zypper in -t pattern fips, add fips=1 to boot params, try the steps manually). Parsing the test module, it does approximately these steps: 0. (enable FIPS kernel mode, or in the case of this linked report, set environment variables OPENSSL_FIPS=1 and OPENSSL_FORCE_FIPS_MODE=1) 1. Create 'egg' file with following contents: Key-Type: RSA Key-Length: 2048 Subkey-Type: RSA Subkey-Length: 2048 Name-Real: SUSE Tester 2048 Name-Email: user@suse.de Expire-Date: 0 2. gpg2 -vv --batch --full-generate-key egg 3. echo 'foo test content' > foo.txt 4. gpg2 -r user@suse.de -e foo.txt But the problem can be reproduced it via remote connection to openQA worker and we can provide access to that.
you would need to set the libgcrypt overrides. export LIBGCRYPT_FORCE_FIPS_MODE=1 however i cant reproduce on a local SP4 machine either.
Yes, that libcrypt env var of course is the correct one.
I've tested it now that gpg2-2.2.27-1.2.x86_64 is affected, upgrading to gpg2-2.2.27-150300.3.5.1.x86_64 fixes the issue. Is there anything to still investigate regarding this or should the bug be closed?
The latest version in gpg2-2.2.27-150300.3.5.1.x86_64, I'm not sure where the gpg2-2.2.27-1.2.x86_64 version comes from. Is that an old version? TIA
gpg2-2.2.27-1.2.x86_64 is comming from sle-module-basesystem:15-SP4::pool: brian:~ # zypper search -s gpg2 Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository ---+-----------+------------+---------------------+--------+------------------------------------- i+ | gpg2 | package | 2.2.27-150300.3.5.1 | x86_64 | sle-module-basesystem:15-SP4::update v | gpg2 | package | 2.2.27-1.2 | x86_64 | sle-module-basesystem:15-SP4::pool | gpg2 | srcpackage | 2.2.27-150300.3.5.1 | noarch | sle-module-basesystem:15-SP4::update i+ | gpg2-lang | package | 2.2.27-150300.3.5.1 | noarch | sle-module-basesystem:15-SP4::update v | gpg2-lang | package | 2.2.27-1.2 | noarch | sle-module-basesystem:15-SP4::pool
OK. Looks like repo issues then, nothing I can do from packaging.