*Richard Levitte*
- * The main project documents (README, NEWS, CHANGES, INSTALL, SUPPORT)
+ * Project text documents not yet having a proper file name extension
+ (HACKING, LICENSE, NOTES*, README*, VERSION) have been renamed to *.md
+ as far as reasonable, else to *.txt, for better use with file managers.
+
+ *David von Oheimb*
+
+* The main project documents (README, NEWS, CHANGES, INSTALL, SUPPORT)
have been converted to Markdown with the goal to produce documents
which not only look pretty when viewed online in the browser, but
remain well readable inside a plain text editor.
* State machine rewrite. The state machine code has been significantly
refactored in order to remove much duplication of code and solve issues
- with the old code (see ssl/statem/README for further details). This change
- does have some associated API changes. Notably the SSL_state() function
- has been removed and replaced by SSL_get_state which now returns an
- "OSSL_HANDSHAKE_STATE" instead of an int. SSL_set_state() has been removed
- altogether. The previous handshake states defined in ssl.h and ssl3.h have
- also been removed.
+ with the old code (see [ssl/statem/README.md](ssl/statem/README.md) for
+ further details). This change does have some associated API changes.
+ Notably the SSL_state() function has been removed and replaced by
+ SSL_get_state which now returns an "OSSL_HANDSHAKE_STATE" instead of an int.
+ SSL_set_state() has been removed altogether. The previous handshake states
+ defined in ssl.h and ssl3.h have also been removed.
*Matt Caswell*
of specific crypto interfaces. This change also introduces integrated
support for symmetric ciphers and digest implementations - so ENGINEs
can now accelerate these by providing EVP_CIPHER and EVP_MD
- implementations of their own. This is detailed in crypto/engine/README
+ implementations of their own. This is detailed in
+ [crypto/engine/README.md](crypto/engine/README.md)
as it couldn't be adequately described here. However, there are a few
API changes worth noting - some RSA, DSA, DH, and RAND functions that
were changed in the original introduction of ENGINE code have now
makes them more flexible to be built both as statically-linked ENGINEs
and self-contained shared-libraries loadable via the "dynamic" ENGINE.
Also, add stub code to each that makes building them as self-contained
- shared-libraries easier (see README.ENGINE).
+ shared-libraries easier (see [README-Engine.md](README-Engine.md)).
*Geoff Thorpe*
self-contained shared-libraries. The "dynamic" ENGINE exposes control
commands that can be used to configure what shared-library to load and
to control aspects of the way it is handled. Also, made an update to
- the README.ENGINE file that brings its information up-to-date and
+ the [README-Engine.md](README-Engine.md) file
+ that brings its information up-to-date and
provides some information and instructions on the "dynamic" ENGINE
(ie. how to use it, how to build "dynamic"-loadable ENGINEs, etc).
5. When at all possible, patches should include tests. These can
either be added to an existing test, or completely new. Please see
- test/README for information on the test framework.
+ test/README.md for information on the test framework.
6. New features or changed functionality must include
documentation. Please look at the "pod" files in doc/man[1357] for
#### Android...
#
-# See NOTES.ANDROID for details, and don't miss platform-specific
+# See NOTES-Android.md for details, and don't miss platform-specific
# comments below...
{
my %version = ();
collect_information(
- collect_from_file(catfile($srcdir,'VERSION')),
+ collect_from_file(catfile($srcdir,'VERSION.dat')),
qr/\s*(\w+)\s*=\s*(.*?)\s*$/ =>
sub {
# Only define it if there is a value at all
}
},
"OTHERWISE" =>
- sub { die "Something wrong with this line:\n$_\nin $srcdir/VERSION" },
+ sub { die "Something wrong with this line:\n$_\nin $srcdir/VERSION.dat" },
);
$config{major} = $version{MAJOR} // 'unknown';
$config{version} = "$config{major}.$config{minor}.$config{patch}";
$config{full_version} = "$config{version}$config{prerelease}$config{build_metadata}";
-die "erroneous version information in VERSION: ",
+die "erroneous version information in VERSION.dat: ",
"$config{version}, $config{shlib_version}\n"
unless (defined $version{MAJOR}
&& defined $version{MINOR}
- Python PYCA/Cryptography test suite
- krb5 test suite
-See the file [test/README.external](test/README.external) for further details.
+See the file [test/README-external.md](test/README-external.md)
+for further details.
### no-filenames
If your system isn't listed, you will have to create a configuration
file named `Configurations/{{ something }}.conf` and add the correct
configuration for your system. See the available configs as examples
-and read [Configurations/README](Configurations/README)
-and [Configurations/README.design](Configurations/README.design)
+and read [Configurations/README.md](Configurations/README.md) and
+[Configurations/README-design.md](Configurations/README-design.md)
for more information.
The generic configurations `cc` or `gcc` should usually work on 32 bit
**Warning:** you MUST run the tests from an unprivileged account (or disable
your privileges temporarily if your platform allows it).
-See the file [test/README.md](test/README.md) for further details.
+See [test/README.md](test/README.md) for further details how run tests.
+
+See [test/README-dev.md](test/README-dev.md) for guidelines on adding tests.
Install OpenSSL
---------------
Use a different build file name than the platform default
("Makefile" on Unix-like platforms, "makefile" on native Windows,
"descrip.mms" on OpenVMS). This requires that there is a
- corresponding build file template. See Configurations/README
+ corresponding build file template.
+ See [Configurations/README.md](Configurations/README.md)
for further information.
CC
templates for those platforms. The database is comprised of
".conf" files in the Configurations directory. The build
file templates reside there as well as ".tmpl" files. See the
- file Configurations/README for further information about the
- format of ".conf" files as well as information on the ".tmpl"
- files.
+ file [Configurations/README.md](Configurations/README.md)
+ for further information about the format of ".conf" files
+ as well as information on the ".tmpl" files.
In addition to the standard ".conf" and ".tmpl" files, it is
- possible to create your own ".conf" and ".tmpl" files and store
- them locally, outside the OpenSSL source tree. This environment
- variable can be set to the directory where these files are held
- and will be considered by Configure before it looks in the
- standard directories.
+ possible to create your own ".conf" and ".tmpl" files and
+ store them locally, outside the OpenSSL source tree.
+ This environment variable can be set to the directory where
+ these files are held and will be considered by Configure
+ before it looks in the standard directories.
PERL
The name of the Perl executable to use when building OpenSSL.
The directory contains two README files, which explain the general syntax and
design of the configuration files.
- - [Configurations/README](Configurations/README)
- - [Configurations/README.design](Configurations/README.design)
+ - [Configurations/README.md](Configurations/README.md)
+ - [Configurations/README-design.md](Configurations/README-design.md)
If you need further help, try to search the [openssl-users][] mailing list
or the [GitHub Issues][] for existing solutions. If you don't find anything,
* Enhanced EVP interface.
[1] The support for external crypto devices is currently a separate
- distribution. See the file README.ENGINE.
+ distribution. See the file README-Engine.md.
### Major changes between OpenSSL 0.9.5 and OpenSSL 0.9.5a [1 Apr 2000]
you are free to get and use it for commercial and non-commercial
purposes as long as you fulfill its conditions.
-See the [LICENSE](LICENSE) file for more details.
+See the [LICENSE.txt](LICENSE.txt) file for more details.
Support
=======
--- /dev/null
+MAJOR=3
+MINOR=0
+PATCH=0
+PRE_RELEASE_TAG=alpha4-dev
+BUILD_METADATA=
+RELEASE_DATE=""
+SHLIB_VERSION=3
-h This help.
Any other text will be passed to the Configure perl script.
-See INSTALL for instructions.
+See INSTALL.md for instructions.
$ EOD
$ ENDIF
NOTE: Don't expect any of these programs to work with current
OpenSSL releases, or even with later SSLeay releases.
-Original README:
+Original README.md:
=============================================================================
Some demo programs sent to me by various people
The client-conf, server-conf, client-arg and client-conf include examples
of how to use the SSL_CONF API for configuration file or command line
processing.
-
The script ocspquery.sh queries the status of the certificates using the
test responder.
-
-
-
# OpenSSL source directory as value.
get_version () {
- eval $(git cat-file blob HEAD:VERSION)
+ eval $(git cat-file blob HEAD:VERSION.dat)
VERSION="$MAJOR.$MINOR.$PATCH"
SERIES="$MAJOR.$MINOR"
TYPE=$( echo "$PRE_RELEASE_TAG" \
PRE_RELEASE_TAG="$PRE_LABEL$PRE_NUM"
;;
esac
- cat > "$SOURCEDIR/VERSION" <<EOF
+ cat > "$SOURCEDIR/VERSION.dat" <<EOF
MAJOR=$MAJOR
MINOR=$MINOR
PATCH=$PATCH
=head1 VERSION AND STATE
With OpenSSL 3.0, all the version and state information is in the file
-F<VERSION>, where the following variables are used and changed:
+F<VERSION.dat>, where the following variables are used and changed:
=over 4
-README This file
+README.md This file
fingerprints.txt
PGP fingerprints of authorised release signers
+Guidelines for test developers
+==============================
+
How to add recipes
-==================
+------------------
For any test that you want to perform, you write a script located in
-test/recipes/, named {nn}-test_{name}.t, where {nn} is a two digit number and
-{name} is a unique name of your choice.
+`test/recipes/`, named `{nn}-test_{name}.t`,
+where `{nn}` is a two digit number and
+`{name}` is a unique name of your choice.
Please note that if a test involves a new testing executable, you will need to
-do some additions in test/build.info. Please refer to the section "Changes to
-test/build.info" below.
-
+do some additions in test/build.info. Please refer to the section
+["Changes to test/build.info"](README.md#changes-to-testbuildinfo) below.
Naming conventions
-=================
-
-A test executable is named test/{name}test.c
-
-A test recipe is named test/recipes/{nn}-test_{name}.t, where {nn} is a two
-digit number and {name} is a unique name of your choice.
-
-The number {nn} is (somewhat loosely) grouped as follows:
-
-00-04 sanity, internal and essential API tests
-05-09 individual symmetric cipher algorithms
-10-14 math (bignum)
-15-19 individual asymmetric cipher algorithms
-20-24 openssl commands (some otherwise not tested)
-25-29 certificate forms, generation and verification
-30-35 engine and evp
-60-79 APIs:
- 60 X509 subsystem
- 61 BIO subsystem
- 65 CMP subsystem
- 70 PACKET layer
-80-89 "larger" protocols (CA, CMS, OCSP, SSL, TSA)
-90-98 misc
-99 most time consuming tests [such as test_fuzz]
-
+------------------
+
+A test executable is named `test/{name}test.c`
+
+A test recipe is named `test/recipes/{nn}-test_{name}.t`, where `{nn}` is a two
+digit number and `{name}` is a unique name of your choice.
+
+The number `{nn}` is (somewhat loosely) grouped as follows:
+
+ 00-04 sanity, internal and essential API tests
+ 05-09 individual symmetric cipher algorithms
+ 10-14 math (bignum)
+ 15-19 individual asymmetric cipher algorithms
+ 20-24 openssl commands (some otherwise not tested)
+ 25-29 certificate forms, generation and verification
+ 30-35 engine and evp
+ 60-79 APIs:
+ 60 X509 subsystem
+ 61 BIO subsystem
+ 65 CMP subsystem
+ 70 PACKET layer
+ 80-89 "larger" protocols (CA, CMS, OCSP, SSL, TSA)
+ 90-98 misc
+ 99 most time consuming tests [such as test_fuzz]
A recipe that just runs a test executable
-=========================================
+-----------------------------------------
A script that just runs a program looks like this:
simple_test("test_{name}", "{name}test", "{name}");
-{name} is the unique name you have chosen for your test.
-
-The second argument to `simple_test' is the test executable, and `simple_test'
-expects it to be located in test/
+`{name}` is the unique name you have chosen for your test.
-For documentation on OpenSSL::Test::Simple, do
-`perldoc util/perl/OpenSSL/Test/Simple.pm'.
+The second argument to `simple_test` is the test executable, and `simple_test`
+expects it to be located in `test/`
+For documentation on `OpenSSL::Test::Simple`,
+do `perldoc util/perl/OpenSSL/Test/Simple.pm`.
A recipe that runs a more complex test
-======================================
+--------------------------------------
For more complex tests, you will need to read up on Test::More and
-OpenSSL::Test. Test::More is normally preinstalled, do `man Test::More' for
-documentation. For OpenSSL::Test, do `perldoc util/perl/OpenSSL/Test.pm'.
+OpenSSL::Test. Test::More is normally preinstalled, do `man Test::More` for
+documentation. For OpenSSL::Test, do `perldoc util/perl/OpenSSL/Test.pm`.
A script to start from could be this:
# test feature 2
}
-
Changes to test/build.info
-==========================
+--------------------------
Whenever a new test involves a new test executable you need to do the
following (at all times, replace {NAME} and {name} with the name of your
test):
-* add {name} to the list of programs under PROGRAMS_NO_INST
+ * add `{name}` to the list of programs under `PROGRAMS_NO_INST`
-* create a three line description of how to build the test, you will have
-to modify the include paths and source files if you don't want to use the
-basic test framework:
+ * create a three line description of how to build the test, you will have
+ to modify the include paths and source files if you don't want to use the
+ basic test framework:
- SOURCE[{name}]={name}.c
- INCLUDE[{name}]=.. ../include ../apps/include
- DEPEND[{name}]=../libcrypto libtestutil.a
+ SOURCE[{name}]={name}.c
+ INCLUDE[{name}]=.. ../include ../apps/include
+ DEPEND[{name}]=../libcrypto libtestutil.a
Generic form of C test executables
-==================================
+----------------------------------
#include "testutil.h"
return 1; /* Indicate success */
}
-You should use the TEST_xxx macros provided by testutil.h to test all failure
+You should use the `TEST_xxx` macros provided by `testutil.h` to test all failure
conditions. These macros produce an error message in a standard format if the
condition is not met (and nothing if the condition is met). Additional
-information can be presented with the TEST_info macro that takes a printf
-format string and arguments. TEST_error is useful for complicated conditions,
-it also takes a printf format string and argument. In all cases the TEST_xxx
+information can be presented with the `TEST_info` macro that takes a `printf`
+format string and arguments. `TEST_error` is useful for complicated conditions,
+it also takes a `printf` format string and argument. In all cases the `TEST_xxx`
macros are guaranteed to evaluate their arguments exactly once. This means
that expressions with side effects are allowed as parameters. Thus,
The former produces a more meaningful message on failure than the latter.
Note that the test infrastructure automatically sets up all required environment
-variables (such as OPENSSL_MODULES, OPENSSL_CONF etc) for the tests. Individual
-tests may choose to override the default settings as required.
-
+variables (such as `OPENSSL_MODULES`, `OPENSSL_CONF`, etc.) for the tests.
+Individual tests may choose to override the default settings as required.
-Test OpenSSL
-============
+Using OpenSSL Tests
+===================
After a successful build, and before installing, the libraries should be tested.
Run:
--- /dev/null
+TEST DATA
+
+Please note that if a test involves a new testing executable,
+you will need to do some additions in test/build.info.
--- /dev/null
+TEST DATA2
+
+Running external test suites with OpenSSL
+=========================================
+
+It is possible to integrate external test suites into OpenSSL's "make test".
+This capability is considered a developer option and does not work on all
+platforms.
+
+
+
+The BoringSSL test suite
+========================
+
+In order to run the BoringSSL tests with OpenSSL, first checkout the BoringSSL
+source code into an appropriate directory. This can be done in two ways:
+
+1) Separately from the OpenSSL checkout using:
+
+ $ git clone https://boringssl.googlesource.com/boringssl boringssl
+
+ The BoringSSL tests are only confirmed to work at a specific commit in the
+ BoringSSL repository. Later commits may or may not pass the test suite:
+
+ $ cd boringssl
+ $ git checkout 490469f850e
+
+2) Using the already configured submodule settings in OpenSSL:
+
+ $ git submodule update --init
+
+Configure the OpenSSL source code to enable the external tests:
+
+$ cd ../openssl
+$ ./config enable-ssl3 enable-ssl3-method enable-weak-ssl-ciphers \
+ enable-external-tests
+
+Note that using other config options than those given above may cause the tests
+to fail.
+
+Run the OpenSSL tests by providing the path to the BoringSSL test runner in the
+BORING_RUNNER_DIR environment variable:
+
+$ BORING_RUNNER_DIR=/path/to/boringssl/ssl/test/runner make test
+
+Note that the test suite may change directory while running so the path provided
+should be absolute and not relative to the current working directory.
+
+To see more detailed output you can run just the BoringSSL tests with the
+verbose option:
+
+$ VERBOSE=1 BORING_RUNNER_DIR=/path/to/boringssl/ssl/test/runner make \
+ TESTS="test_external_boringssl" test
+
+
+Test failures and suppressions
+------------------------------
+
+A large number of the BoringSSL tests are known to fail. A test could fail
+because of many possible reasons. For example:
+
+- A bug in OpenSSL
+- Different interpretations of standards
+- Assumptions about the way BoringSSL works that do not apply to OpenSSL
+- The test uses APIs added to BoringSSL that are not present in OpenSSL
+- etc
+
+In order to provide a "clean" baseline run with all the tests passing a config
+file has been provided that suppresses the running of tests that are known to
+fail. These suppressions are held in the file "test/ossl_shim/ossl_config.json"
+within the OpenSSL source code.
+
+The community is encouraged to contribute patches which reduce the number of
+suppressions that are currently present.
+
+
+Python PYCA/Cryptography test suite
+===================================
+
+This python test suite runs cryptographic tests with a local OpenSSL build as
+the implementation.
+
+First checkout the PYCA/Cryptography module into ./pyca-cryptography using:
+
+$ git submodule update --init
+
+Then configure/build OpenSSL compatible with the python module:
+
+$ ./config shared enable-external-tests
+$ make
+
+The tests will run in a python virtual environment which requires virtualenv
+to be installed.
+
+$ make test VERBOSE=1 TESTS=test_external_pyca
+
+Test failures and suppressions
+------------------------------
+
+Some tests target older (<=1.0.2) versions so will not run. Other tests target
+other crypto implementations so are not relevant. Currently no tests fail.
+
+
+krb5 test suite
+===============
+
+Much like the PYCA/Cryptography test suite, this builds and runs the krb5
+tests against the local OpenSSL build.
+
+You will need a git checkout of krb5 at the top level:
+
+$ git clone https://github.com/krb5/krb5
+
+krb5's master has to pass this same CI, but a known-good version is
+krb5-1.15.1-final if you want to be sure.
+
+$ cd krb5
+$ git checkout krb5-1.15.1-final
+$ cd ..
+
+OpenSSL must be built with external tests enabled:
+
+$ ./config enable-external-tests
+$ make
+
+krb5's tests will then be run as part of the rest of the suite, or can be
+explicitly run (with more debugging):
+
+$ VERBOSE=1 make TESTS=test_external_krb5 test
+
+Test-failures suppressions
+--------------------------
+
+krb5 will automatically adapt its test suite to account for the configuration
+of your system. Certain tests may require more installed packages to run. No
+tests are expected to fail.
+
+
+GOST engine test suite
+===============
+
+Much like the PYCA/Cryptography test suite, this builds and runs the GOST engine
+tests against the local OpenSSL build.
+
+You will need a git checkout of gost-engine at the top level:
+
+$ git submodule update --init
+
+Then configure/build OpenSSL enabling external tests:
+
+$ ./config shared enable-external-tests
+$ make
+
+GOST engine requires CMake for the build process.
+
+GOST engine tests will then be run as part of the rest of the suite, or can be
+explicitly run (with more debugging):
+
+$ make test VERBOSE=1 TESTS=test_external_gost_engine
+
+Updating test suites
+====================
+
+To update the commit for any of the above test suites:
+
+- Make sure the submodules are cloned locally:
+
+ $ git submodule update --init --recursive
+
+- Enter subdirectory and pull from the repository (use a specific branch/tag if required):
+
+ $ cd <submodule-dir>
+ $ git pull origin master
+
+- Go to root directory, there should be a new git status:
+
+ $ cd ../
+ $ git status
+ ...
+ # modified: <submodule-dir> (new commits)
+ ...
+
+- Add/commit/push the update
+
+ git add <submodule-dir>
+ git commit -m "Updated <submodule> to latest commit"
+ git push
+
my $privkey = shift;
my $pubkey = shift;
- my $data_to_sign = srctop_file('test', 'README');
- my $other_data = srctop_file('test', 'README.external');
+ my $data_to_sign = srctop_file('test', 'data.txt');
+ my $other_data = srctop_file('test', 'data2.txt');
my $sigfile = basename($privkey, '.pem') . '.sig';
plan tests => 4;
my $pubkey = shift;
my @extraopts = @_;
- my $data_to_sign = srctop_file('test', 'README');
- my $other_data = srctop_file('test', 'README.external');
+ my $data_to_sign = srctop_file('test', 'data.txt');
+ my $other_data = srctop_file('test', 'data2.txt');
my $sigfile = basename($privkey, '.pem') . '.sig';
my @args = ();
plan skip_all => "No external tests in this configuration"
if disabled("external-tests");
plan skip_all => "krb5 not available"
- if ! -f srctop_file("krb5", "README");
+ if ! -f srctop_file("krb5", "data.txt");
plan tests => 1;
projects / openssl.git / commitdiff