Bug 1213636

Summary: [SLES15SP4][SECURITY][FIPS][Build 191.4] openQA test core dumps in gpg in FIPS mode
Product: [openSUSE] PUBLIC SUSE Linux Enterprise Server 15 SP4 Reporter: Timo Jyrinki <tjyrinki>
Component: Security CertificationsAssignee: Certification Bugs <certification-bugs>
Status: NEW --- QA Contact:
Severity: Normal    
Priority: P5 - None CC: felice.maccaro, heiko.rommel, pmonrealgonzalez
Version: SLES15SP4-MaintUpd   
Target Milestone: ---   
Hardware: Other   
OS: Other   
URL: https://openqa.suse.de/tests/11657280/modules/gpg/steps/54
Whiteboard: FIPS
Found By: openQA Services Priority:
Business Priority: Blocker: Yes
Marketing QA Status: --- IT Deployment: ---

Description Timo Jyrinki 2023-07-25 10:50:35 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.
Comment 1 Marcus Meissner 2023-07-25 14:08:36 UTC 
you would need to set the libgcrypt overrides.

export LIBGCRYPT_FORCE_FIPS_MODE=1

however i cant reproduce on a local SP4 machine either.
Comment 2 Timo Jyrinki 2023-08-01 05:41:59 UTC 
Yes, that libcrypt env var of course is the correct one.
Comment 3 Timo Jyrinki 2023-08-01 06:34:28 UTC 
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?
Comment 5 Pedro Monreal Gonzalez 2023-08-01 08:29:27 UTC 
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
Comment 6 Heiko Rommel 2023-08-03 07:54:14 UTC 
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
Comment 7 Pedro Monreal Gonzalez 2023-09-07 08:26:56 UTC 
OK. Looks like repo issues then, nothing I can do from packaging.