action #178732
open
[BCI] Add openSSL 1.1 testing (binary download workaround) to 15-SP6 FIPS testing
Added by tjyrinki_suse about 2 months ago.
Updated 20 days ago.
Description
As a continuation to ticket #167683, Security Certifications team has implicated that the earlier quoted status in that ticket was incorrect, and we do no need also openSSL 1.1 FIPS testing in 15-SP6 as well (but not 15-SP7).
It was originally not done because BCI is one of the products that does have libssl1.1 binaries but not the CLI binary openssl1.1 package which provides openssl-1_1 CLI tool.
The other similar products SLED and RT (that do not have access to SLE Legacy module), have implemented a workaround, that should be recreated in BCI's Python tests as well.
Acceptance Criteria¶
- Add similar workaround to BCI that is being done at https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/lib/security/openssl_misc_utils.pm#L64 for SLED and SLE RT.
- Execute the same openSSL tests twice - once by using 'openssl' CLI binary (in 15-SP6, that is openSSL 3) and 'openssl-1_1' CLI binary.
- Do not break the other versiosn - this dual execution should only be done on 15-SP6, other versions just use what is the default.
Further Information¶
Dennis Knorr can answer questions.
- Related to action #167683: [BCI] Implement FIPS Vendor affirmation tests added
- Description updated (diff)
- Status changed from Workable to In Progress
- Assignee set to emiler
- Status changed from In Progress to Workable
- Assignee deleted (
emiler)
- Tags changed from fips, vendoraffirmation to fips, vendoraffirmation, bci
- Priority changed from Normal to High
- Status changed from Workable to In Progress
- Assignee set to pherranz
- Description updated (diff)
Fixing the description, the exact name of the command (now that I've manually tested BCI once) is "openssl-1_1".
After thinking about this, I've come to the conclusion that a good approach might be to have two different containers to test for 15-SP6:
- One with openSSL3 as it comes by default
- Another 'tweaked' one with openSSL1.1
This way the tests remain unchanged, and we perform the whole "battery" on both versions.
I'm clarifying a bit mostly since I don't see the idea of different containers, but I'm also not familiar with all the implementation details here.
The versions (3 vs 1.1) are not overlapping, both can be parallel installed and the called binary (openssl vs openssl-1_1) is different. I don't immediately see how separate containers would change any of the testing as such, but maybe the idea was more generally to test "untouched" default container vs "additional libraries and one binary CLI tool installed".
But as said, installing the libopenssl1_1 package and the openssl-1_1 CLI binary wouldn't affect anything else on the system, and the openSSL 1.1 would only be tested by calling the openssl-1_1 command directly instead of any apps using it, as the apps always use the default openSSL ie openSSL 3.
Oh nice, that simplifies the process A LOT!
In my mind I thought that both versions could not be installed along.
Thanks for clarifying @tjyrinki_suse!
@tjyrinki_suse can you help me understand if this C code we're using to test the digests is affected by the local openSSL version installed?
Maybe there's no need to run this test_openssl_binary function with openSSL1.1 and it will suffice with running openssl_fips_hashes_test_fnct one?
you could run ldd /bin/fips-test to check what it links to, but given it's compiled with libopenssl-devel installed (and not libopenssl-1_1-devel), it'd link to the default openSSL which is openSSL 3 again. So yes, openssl_fips_hashes_test_fnct with the openssl-1_1 as the command instead of openssl would suffice, and also fulfill the minimal vendor affirmation requirements.
basically making the openssl binary a variable (set to either openssl or openssl-1_1) and running openssl_fips_hashes_test_fnct twice on 15-SP6 with both binaries would work.
Also available in: Atom
PDF