data2.bin 5.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188
  1. TEST DATA2
  2. Running external test suites with OpenSSL
  3. =========================================
  4. It is possible to integrate external test suites into OpenSSL's "make test".
  5. This capability is considered a developer option and does not work on all
  6. platforms.
  7. The BoringSSL test suite
  8. ========================
  9. In order to run the BoringSSL tests with OpenSSL, first checkout the BoringSSL
  10. source code into an appropriate directory. This can be done in two ways:
  11. 1) Separately from the OpenSSL checkout using:
  12. $ git clone https://boringssl.googlesource.com/boringssl boringssl
  13. The BoringSSL tests are only confirmed to work at a specific commit in the
  14. BoringSSL repository. Later commits may or may not pass the test suite:
  15. $ cd boringssl
  16. $ git checkout 490469f850e
  17. 2) Using the already configured submodule settings in OpenSSL:
  18. $ git submodule update --init
  19. Configure the OpenSSL source code to enable the external tests:
  20. $ cd ../openssl
  21. $ ./config enable-ssl3 enable-ssl3-method enable-weak-ssl-ciphers \
  22. enable-external-tests
  23. Note that using other config options than those given above may cause the tests
  24. to fail.
  25. Run the OpenSSL tests by providing the path to the BoringSSL test runner in the
  26. BORING_RUNNER_DIR environment variable:
  27. $ BORING_RUNNER_DIR=/path/to/boringssl/ssl/test/runner make test
  28. Note that the test suite may change directory while running so the path provided
  29. should be absolute and not relative to the current working directory.
  30. To see more detailed output you can run just the BoringSSL tests with the
  31. verbose option:
  32. $ VERBOSE=1 BORING_RUNNER_DIR=/path/to/boringssl/ssl/test/runner make \
  33. TESTS="test_external_boringssl" test
  34. Test failures and suppressions
  35. ------------------------------
  36. A large number of the BoringSSL tests are known to fail. A test could fail
  37. because of many possible reasons. For example:
  38. - A bug in OpenSSL
  39. - Different interpretations of standards
  40. - Assumptions about the way BoringSSL works that do not apply to OpenSSL
  41. - The test uses APIs added to BoringSSL that are not present in OpenSSL
  42. - etc
  43. In order to provide a "clean" baseline run with all the tests passing a config
  44. file has been provided that suppresses the running of tests that are known to
  45. fail. These suppressions are held in the file "test/ossl_shim/ossl_config.json"
  46. within the OpenSSL source code.
  47. The community is encouraged to contribute patches which reduce the number of
  48. suppressions that are currently present.
  49. Python PYCA/Cryptography test suite
  50. ===================================
  51. This python test suite runs cryptographic tests with a local OpenSSL build as
  52. the implementation.
  53. First checkout the PYCA/Cryptography module into ./pyca-cryptography using:
  54. $ git submodule update --init
  55. Then configure/build OpenSSL compatible with the python module:
  56. $ ./config shared enable-external-tests
  57. $ make
  58. The tests will run in a python virtual environment which requires virtualenv
  59. to be installed.
  60. $ make test VERBOSE=1 TESTS=test_external_pyca
  61. Test failures and suppressions
  62. ------------------------------
  63. Some tests target older (<=1.0.2) versions so will not run. Other tests target
  64. other crypto implementations so are not relevant. Currently no tests fail.
  65. krb5 test suite
  66. ===============
  67. Much like the PYCA/Cryptography test suite, this builds and runs the krb5
  68. tests against the local OpenSSL build.
  69. You will need a git checkout of krb5 at the top level:
  70. $ git clone https://github.com/krb5/krb5
  71. krb5's master has to pass this same CI, but a known-good version is
  72. krb5-1.15.1-final if you want to be sure.
  73. $ cd krb5
  74. $ git checkout krb5-1.15.1-final
  75. $ cd ..
  76. OpenSSL must be built with external tests enabled:
  77. $ ./config enable-external-tests
  78. $ make
  79. krb5's tests will then be run as part of the rest of the suite, or can be
  80. explicitly run (with more debugging):
  81. $ VERBOSE=1 make TESTS=test_external_krb5 test
  82. Test-failures suppressions
  83. --------------------------
  84. krb5 will automatically adapt its test suite to account for the configuration
  85. of your system. Certain tests may require more installed packages to run. No
  86. tests are expected to fail.
  87. GOST engine test suite
  88. ===============
  89. Much like the PYCA/Cryptography test suite, this builds and runs the GOST engine
  90. tests against the local OpenSSL build.
  91. You will need a git checkout of gost-engine at the top level:
  92. $ git submodule update --init
  93. Then configure/build OpenSSL enabling external tests:
  94. $ ./config shared enable-external-tests
  95. $ make
  96. GOST engine requires CMake for the build process.
  97. GOST engine tests will then be run as part of the rest of the suite, or can be
  98. explicitly run (with more debugging):
  99. $ make test VERBOSE=1 TESTS=test_external_gost_engine
  100. Updating test suites
  101. ====================
  102. To update the commit for any of the above test suites:
  103. - Make sure the submodules are cloned locally:
  104. $ git submodule update --init --recursive
  105. - Enter subdirectory and pull from the repository (use a specific branch/tag if required):
  106. $ cd <submodule-dir>
  107. $ git pull origin master
  108. - Go to root directory, there should be a new git status:
  109. $ cd ../
  110. $ git status
  111. ...
  112. # modified: <submodule-dir> (new commits)
  113. ...
  114. - Add/commit/push the update
  115. git add <submodule-dir>
  116. git commit -m "Updated <submodule> to latest commit"
  117. git push