ssltest_old.c is deprecated. New tests should use ssl_test.c, and the
recipes in 80-test_ssl_new.t

Reviewed-by: Richard Levitte <levitte@openssl.org>

Require that test methods return 1 on success (not 0). This is more
customary for OpenSSL.

Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Rich Salz <rsalz@openssl.org>

Currently, SSL tests are configured via command-line switches to
ssltest.c. This results in a lot of duplication between ssltest.c and
apps, and a complex setup. ssltest.c is also simply old and needs
maintenance.

Instead, we already have a way to configure SSL servers and clients, so
we leverage that. SSL tests can now be configured from a configuration
file. Test servers and clients are configured using the standard
ssl_conf module. Additional test settings are configured via a test
configuration.

Moreover, since the CONF language involves unnecessary boilerplate, the
test conf itself is generated from a shorter Perl syntax.

The generated testcase files are checked in to the repo to make
it easier to verify that the intended test cases are in fact run; and to
simplify debugging failures.

To demonstrate the approach, min/max protocol tests are converted to the
new format. This change also fixes MinProtocol and MaxProtocol
handling. It was previously requested that an SSL_CTX ha...

... comes from c5137473

.
Fix Travis builds.

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

This reverts commit 620d540b

.
It wasn't reviewed.

Reviewed-by: Rich Salz <rsalz@openssl.org>

This reverts commit 2b0bcfaf

.
It wasn't reviewed.

Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Stephen Henson <steve@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Stephen Henson <steve@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Stephen Henson <steve@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

Issue #182

Reviewed-by: Stephen Henson <steve@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

Submitted by Michael McConville <mmcco@mykolab.com>

Reviewed-by: Rich Salz <rsalz@openssl.org>

RT#4483

[poly1305-armv4.pl: remove redundant #ifdef __thumb2__]
[poly1305-ppc*.pl: presumably more accurate benchmark results]

Reviewed-by: Richard Levitte <levitte@openssl.org>

These leaks affect 1.1.0 dev branch only; introduced around commit
f93ad22f



Found with LibFuzzer

Reviewed-by: Ben Laurie <ben@openssl.org>

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Dr. Stephen Henson <steve@openssl.org>

It was harmless in this case, but best avoid the annoying warnings.

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>

Previously, we updated the static libraries (libcrypto.a on Unix,
libcrypto.lib on Windows) with all the object files, regardless of if
they were rebuilt or not.  With this change, we only update them with
the object files were rebuilt.

NOTE: this does not apply on VMS, as the expansion of $? may be too
large for a command line.

Reviewed-by: Andy Polyakov <appro@openssl.org>

Reviewed-by: Richard Levitte <levitte@openssl.org>

Reviewed-by: Richard Levitte <levitte@openssl.org>

Reviewed-by: Dr. Stephen Henson <steve@openssl.org>

A new X509_VERIFY_PARAM_set_auth_level() function sets the
authentication security level.  For verification of SSL peers, this
is automatically set from the SSL security level.  Otherwise, for
now, the authentication security level remains at (effectively) 0
by default.

The new "-auth_level" verify(1) option is available in all the
command-line tools that support the standard verify(1) options.

New verify(1) tests added to check enforcement of chain signature
and public key security levels.  Also added new tests of enforcement
of the verify_depth limit.

Updated documentation.

Reviewed-by: Dr. Stephen Henson <steve@openssl.org>

Reviewed-by: Dr. Stephen Henson <steve@openssl.org>

Two renamed functions were forgotten in util/libcrypto.num

Reviewed-by: Matt Caswell <matt@openssl.org>

Also fixed a style issue

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Stephen Henson <steve@openssl.org>

Numerous fixups based on feedback of the DSA opacity changes.

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Stephen Henson <steve@openssl.org>

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Stephen Henson <steve@openssl.org>

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Stephen Henson <steve@openssl.org>

A number of getters/setters have been added for examining DSA objects, as
well as a whole set of functions for creating and buildingup DSA_METHODs.

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Stephen Henson <steve@openssl.org>

Move the dsa_method structure out of the public header file, and provide
getter and setter functions for creating and modifying custom DSA_METHODs.

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Stephen Henson <steve@openssl.org>

Move the dsa_st structure out of the public header file. Add some accessor
functions to enable access to the internal fields, and update all internal
usage to use the new functions.

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Stephen Henson <steve@openssl.org>

Reviewed-by: Rich Salz <rsalz@openssl.org>

Within OpenSSL::Test, all commands end up existing in two variants,
one that has redirections that are needed internally to work well
together with the test harness, and one without those redirections.

Depending on what the result is going to be used for, the caller may
want one for or the other, so we give them the possibility.

Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>