QA » openQA Project » openQA Tests

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).

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).
   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.