- Nov 04, 2016
-
-
Richard Levitte authored
Use the newly added "executable" function rather than "system". Also filter the output to add a prefix to every line so that the "ok" doesn't confuse Test::More Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
-
Matt Caswell authored
Don't build ossl_shim by default. Switch it on through enable-external-tests. Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Richard Levitte authored
Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
-
Matt Caswell authored
This just disables all tests that fail at the moment. Over time we will want to go over these and figure out why they are failing (and fix them if appropriate) Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
Numerous conflicts resolved. rebase was against commit 490469f850. Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
This adds a test to the OpenSSL test suite to invoke the BoringSSL test suite. It assumes you have already compiled the ossl_shim (see previous commit). It also assumes that you have an environment variable BORING_RUNNER_DIR set up to point to the ssl/test/runner directory of a checkout of BoringSSL. This has only been tested with a very old version of BoringSSL (from commit f277add6c) - since that was the last known checkout where the shim compiles successfully. Even with that version of BoringSSL this test will fail. There are lots of Boring tests that are failing for various reasons. Some might be due to bugs in OpenSSL, some might be due to features that BoringSSL has that OpenSSL doesn't, some are due to assumptions about the way BoringSSL behaves that are not true for OpenSSL etc. To get the verbose BoringSSL test output, run like this: VERBOSE=1 BORING_RUNNER_DIR=/path/to/boring/ssl/test/runner make \ TESTS="test_external" test Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
The BoringSSL test suite contains numerous tests which OpenSSL does not. The BoringSSL test runner uses a shim to launch the library and execute the tests. This is a version of the BoringSSL shim converted to compile against OpenSSL instead. This is primarily based on the work of David Benjamin from the BoringSSL project who did most of the necessary conversion. It also includes a few other tweaks for opacity changes etc. This is based on a *very* old version of BoringSSL from commit f277add6c. That was the last commit known to work with this patched shim. Later versions may also work but lots of merge conflicts occur when trying to bring it up to date. At the moment this has not been integrated into the build system. There is a very simple standalone makefile in the ossl_shim directory which should be executed directly before tyring to use the shim. Reviewed-by: Richard Levitte <levitte@openssl.org>
-
- Nov 03, 2016
-
-
Richard Levitte authored
test/shlibloadtest.c assumes all Unix style platforms use .so as shared library extension. This is not the case for Mac OS X, which uses .dylib. Instead of this, have the test recipe find out the extension from configuration data. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1844)
-
Rich Salz authored
Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1842)
-
Richard Levitte authored
Pre 1.1.0, 'make test' would set the environment variable OPENSSL_DEBUG_MEMORY to "on". This got lost when translating the old build files to the new templates. This changes reintroduces that variable. Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1840)
-
Richard Levitte authored
- Make sure to initialise SHLIB variables - Make sure to make local variables static Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1838)
-
Richard Levitte authored
gcc is kinder, it silently passes quite a few flags to ld, while clang is stricter and wants them prefixed with -Wl, Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1836)
-
Richard Levitte authored
All of these don't compile cleanly any more, probably haven't for quite some time Reviewed-by: Emilia Käsper <emilia@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1789)
-
Richard Levitte authored
Reviewed-by: Emilia Käsper <emilia@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1789)
-
Richard Levitte authored
Reviewed-by: Emilia Käsper <emilia@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1789)
-
Richard Levitte authored
Reviewed-by: Emilia Käsper <emilia@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1789)
-
Richard Levitte authored
Reviewed-by: Emilia Käsper <emilia@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1789)
-
Richard Levitte authored
Reviewed-by: Emilia Käsper <emilia@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1789)
-
Richard Levitte authored
Reviewed-by: Emilia Käsper <emilia@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1789)
-
Richard Levitte authored
The Unix and Windows linkers appear to simply ignore if any symbol is defined multiple times in different object files and libraries. The VMS linker, on the other hand, warns about it, loud and clear. It will still create the executable, but does so screaming. So we complicate things by saving the linker output, look through all the errors and warnings, and if they are only made up of %LINK-W-MULDEF, we let it pass, otherwise we output the linker output and raise the same exit code we got from the linker. Reviewed-by: Emilia Käsper <emilia@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1789)
-
Richard Levitte authored
Reviewed-by: Emilia Käsper <emilia@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1789)
-
Richard Levitte authored
Reviewed-by: Emilia Käsper <emilia@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1789)
-
Richard Levitte authored
Reviewed-by: Emilia Käsper <emilia@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1789)
-
Richard Levitte authored
Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1832)
-
Kurt Roeckx authored
Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> GH: #1828
-
- Nov 02, 2016
-
-
Matt Caswell authored
Rather than leaking a reference, just call GetModuleHandleEx and pin the module on Windows. Reviewed-by: Tim Hudson <tjh@openssl.org>
-
Matt Caswell authored
Instead of deliberately leaking a reference to ourselves, use nodelete which does this more neatly. Only for Linux at the moment. Reviewed-by: Tim Hudson <tjh@openssl.org>
-
Matt Caswell authored
This should demonstrate that the atexit() handling is working properly (or at least not crashing) on process exit. Reviewed-by: Tim Hudson <tjh@openssl.org>
-
Matt Caswell authored
Because we use atexit() to cleanup after ourselves, this will cause a problem if we have been dynamically loaded and then unloaded again: the atexit() handler may no longer be there. Most modern atexit() implementations can handle this, however there are still difficulties if libssl gets unloaded before libcrypto, because of the atexit() callback that libcrypto makes to libssl. The most robust solution seems to be to ensure that libcrypto and libssl never unload. This is done by simply deliberately leaking a dlopen() reference to them. Reviewed-by: Tim Hudson <tjh@openssl.org>
-
Matt Caswell authored
This works the same way as DSO_pathbyaddr() but instead returns a ptr to the DSO that contains the provided symbol. Reviewed-by: Tim Hudson <tjh@openssl.org>
-
Matt Caswell authored
Commit 3d8b2ec4 removed various unused functions. However now we need to use one of them! This commit resurrects DSO_pathbyaddr(). We're not going to resurrect the Windows version though because what we need to achieve can be done a different way on Windows. Reviewed-by: Tim Hudson <tjh@openssl.org>
-
Matt Caswell authored
Reviewed-by: Tim Hudson <tjh@openssl.org>
-
Matt Caswell authored
We should fail if we receive an unrecognised record type Reviewed-by: Tim Hudson <tjh@openssl.org>
-
Matt Caswell authored
TLS1.0 and TLS1.1 say you SHOULD ignore unrecognised record types, but TLS 1.2 says you MUST send an unexpected message alert. We swap to the TLS 1.2 behaviour for all protocol versions to prevent issues where no progress is being made and the peer continually sends unrecognised record types, using up resources processing them. Issue reported by 郭志攀 Reviewed-by: Tim Hudson <tjh@openssl.org>
-
Richard Levitte authored
Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1815)
-
Sergey Bronnikov authored
CLA: trivial Reviewed-by: Kurt Roeckx <kurt@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1801)
-
Matt Caswell authored
This test checks that read_ahead works correctly when dealing with large records. Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
The function ssl3_read_n() takes a parameter |clearold| which, if set, causes any old data in the read buffer to be forgotten, and any unread data to be moved to the start of the buffer. This is supposed to happen when we first read the record header. However, the data move was only taking place if there was not already sufficient data in the buffer to satisfy the request. If read_ahead is set then the record header could be in the buffer already from when we read the preceding record. So with read_ahead we can get into a situation where even though |clearold| is set, the data does not get moved to the start of the read buffer when we read the record header. This means there is insufficient room in the read buffer to consume the rest of the record body, resulting in an internal error. This commit moves the |clearold| processing to earlier in ssl3_read_n() to ensure that it always takes place. Reviewed-by: Richard Levitte <levitte@openssl.org>
-
David Woodhouse authored
Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
-