Project

General

Profile

action #52808

Updated by whdu almost 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 **SECTEST_DVD_SRC** is defined, then it will remove all registration and repositories, then add all available ISO images in the machine as repository (for s390x add mirror repositories instead). repository. 

 2. If **SECTEST_DVD_SRC** is NOT defined. It will check the registration status through `SUSEConnect`: 
     1. If SUSEConnect return "`Not Registered`", or SUSEConnect failed to check status because of network failure, it will record the status and then add ISO image repositories (for s390x add mirror repositories instead). repositories. 
     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. (Meanwhile, if **SECTEST_REQUIRE_WE** is defined, then register WE from SCC.) 
     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`" 

 This ticket could be worked on with poo#52805 together. More information for this proposal will be added if necessary.

Back