action #52808
Updated by whdu over 5 years ago
Now, all FIPS test cases are classified and distributed into four test suits:
* `fips_env_tests_crypt_core`
* `fips_env_tests_crypt_misc`
* `fips_env_tests_crypt_tool`
* `fips_env_tests_crypt_web`
My proposal is re-classified to following test suites:
* **fips_tests_crypt_core**
Core utilities like openssl and openSSH
```openssl_fips_alglist > openssl_fips_hash > openssl_fips_cipher > openssl_pubkey_rsa> openssl_pubkey_dsa >
openssl_alpn > openssh_fips > sshd > ssh_pubkey > ssh_cleanup```
* **fips_tests_crypt_tools**
Misc tools
```gpg > curl_fips_rc4_seed > aide_check > journald_fss > git > clamav > openvswitch_ssl```
* **fips_tests_crypt_web**
All web services related cases, eg. w3m_https, apache_ssl
```curl_https > wget_https > w3m_https > apache_ssl > apache_nssfips > libmicrohttpd```
* **fips_env_tests_crypt_kernel**
Applications only can be enabled by kernel fips mode (`fips=1`), eg, dm-crypt
All cases in other test suites should be able to run under _'sigle mode'_ by setting variable environments.
```dm_crypt > cryptsetup```
* **fips_env_tests_crypt_x11**
GUI application cases. We install WE extension here only
```x3270_ssl > firefox_nss > hexchat_ssl > seahorse_sshkey```
All cases in **fips_tests_crypt_core**, **fips_tests_crypt_tools**, **fips_tests_crypt_web** and **fips_env_tests_crypt_x11** can be run either in FIPS kernel mode or environment mode. A case **fips_setups** will be added before every cases in test suite to configure FIPS environment according to the variables.
With `FIPS_ENV_MODE=1`, it will setup the system into FIPS environment mode. For **fips_env_tests_crypt_kernel**, kernel mode is mandatory. So the code will be added to check if it currently under kernel mode, if not, then failed.
Test case **test_repo_setup** will be added before **fips_setup** to configure the registration and repositories. The logic would be:
1. If variable **SECURITY_DVD_SRC** is defined, then it will remove all registration and repositories, then add all available ISO images in the machine as repository.
2. If **SECURITY_DVD_SRC** is NOT defined. It will check the registration status through `SUSEConnect`:
1. If SUSEConnect return "`Not Registered`", it will just keep as it was and return.
2. If the system has been registered, then remove existing registration (not de-register) and register a new one with the same registration code find before.
3. If SUSEConnect return "`Invalid system credential`", (it indicate that maybe the status is not correspond with each other between system and SCC server. It is probably caused by the system has been de-registered on SCC by something else at other testing) it remove registration and register from clean system with the regcode find in variable "`SCC_REGCODE`"
4. If SUSEConnect failed to check status because of network failure, it will record the status and then add ISO image repositories.
This ticket could be worked on with poo#52805 together. More information for this proposal will be added if necessary.