- Mar 12, 2018
-
-
Andy Polyakov authored
Reviewed-by:Rich Salz <rsalz@openssl.org>
-
- Mar 11, 2018
-
-
Kurt Roeckx authored
Reviewed-by:Andy Polyakov <appro@openssl.org> GH: #5582
-
- Mar 10, 2018
-
-
Alex Gaynor authored
Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5574)
-
Andy Polyakov authored
So far assembly modules were built as .pl->.S->.s followed by .s->.o. This posed a problem in build_all_generated rule if it was executed on another computer. So we change rule sequence to .pl->.S and then .S->.s->.o. Reviewed-by:
-
Richard Levitte authored
A missing parenthesis here, a missing comma there... Reviewed-by:
-
Richard Levitte authored
There are things depending on configdata.pm. However, it's perfectly possible that there is one in the source directory from a previous build, and that might disrupt an out of source build. To avoid this conflict, make sure never to use the source tree configdata.pm in that case, i.e. make the hard assumption that it's a generated file in the build tree, which it is. Reviewed-by:
Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5546)
-
Richard Levitte authored
When generating the correct inclusion directory for DEPEND, we mangled it to be relative to the build or the source directory. However, the value we handle already come with a correct directory, so we only need to use it as is. Fixes #5543 Reviewed-by:
-
- Mar 09, 2018
-
-
Dr. Matthias St. Pierre authored
The introduction of thread local public and private DRBG instances (#5547) makes it very cumbersome to change the reseeding (time) intervals for those instances. This commit provides a function to set the default values for all subsequently created DRBG instances. int RAND_DRBG_set_reseed_defaults( unsigned int master_reseed_interval, unsigned int slave_reseed_interval, time_t master_reseed_time_interval, time_t slave_reseed_time_interval ); The function is intended only to be used during application initialization, before any threads are created and before any random bytes are generated. Reviewed-by: -
Ben Kaduk authored
Commit abe256e7 changed the config target element from 'cxx' to 'CXX'; catch up accordingly. Also use a space to offset the template boundary, per convention. [extended tests] Reviewed-by:
-
Benjamin Kaduk authored
X509_STORE_set_verify_cb_func.pod has documentation for various callbacks and function pointers that can be set and retrieved, but neither it nor X509_STORE_new has much documentation for the actual purpose and usage of X509_STORE objects. Remedy this disparity with new documentation for adding certificates and CRLs, expected usage, and for modifying the default verifification behavior. Reviewed-by:
Viktor Dukhovni <viktor@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3958)
-
Ben Kaduk authored
Remove a space from a whitespace-only line. Reviewed-by:
-
Benjamin Kaduk authored
At the core of things is the concept that each extension is only defined in certain context(s) -- the ClientHello, EncryptedExtensions, etc., and sometimes only for a specific protocol or protocol range; we want to enforce that we only parse or generate extensions in the context(s) for which they are defined. There is some subtlety here, in that the protocol version in use is not known when generating the ClientHello (but it is known when the ClientHello extensions are being parsed!), so the SSL_IS_TLS13() macro must be used with caution. Nonetheless, by making assertions about whether we are acting in a server role and whether the current context is (not) a ClientHello, we can consolidate almost all of the logic for determining whether an extension is permitted in a given protocol message, whether we are generating or parsing that message. The only logic that remains separate relates to generating the ClientHello, as it depends on an external factor (the maximum permitted TLS version) that is not defined in the parsing context. Reviewed-by:
Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2945)
-
Benjamin Kaduk authored
The get_name() helper was using a variable of type size_t to hold the result of BIO_gets(), but BIO_gets() returns int and makes use of negative values to indicate error conditions. Change the type of the local variable to match, and propagate that through to other places in the file to avoid -Wsign-compare issues. Reviewed-by:
-
Todd Short authored
Add functions that will do the work of assigning certificate, privatekey and chain certs to an SSL or SSL_CTX. If no privatekey is given, use the publickey. This will permit the keys to pass validation for both ECDSA and RSA. If a private key has already been set for the certificate, it is discarded. A real private key can be set later. This is an all-or-nothing setting of these parameters. Unlike the SSL/SSL_CTX_use_certificate() and SSL/SSL_CTX_use_PrivateKey() functions, the existing cert or privatekey is not modified (i.e. parameters copied). This permits the existing cert/privatekey to be replaced. It replaces the sequence of: * SSL_use_certificate() * SSL_use_privatekey() * SSL_set1_chain() And may actually be faster, as multiple checks are consolidated. The private key can be NULL, if so an ENGINE module needs to contain the actual private key that is to be used. Note that ECDH (using the certificate's ECDSA key) ciphers do not work without the private key being present, based on how the private key is used in ECDH. ECDH does not offer PFS; ECDHE ciphers should be used instead. Reviewed-by:
Ben Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/1130)
-
Andy Polyakov authored
This includes even ARM targets. Reviewed-by:
-
Andy Polyakov authored
$target{build_scheme} consists of fixed number of elements with 3rd element denoting VC install-path "flavour", i.e. where to install things. Instead of looking at 3rd, let's look at last. This allows to override flavour from template in a simple way. Configurations/10-main.conf: define generic "flavour" in VC-common template. Since VC-W32 was the only recognized "flavour", remove "flavour" definitions from all targets/templates, but VC-WIN32. And rename VC-W32 to VC-WOW. Reviewed-by: -
Andy Polyakov authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
We're currently using the attributes 'defines', 'cppflags', 'cflags' etc quite liberally, with no regard for where that ends up. Quite a few of those flags are actually only relevant for the libraries (mostly libcrypto), so it's safe to say that those could be applied to the libraries only. So, we move some of those flags to 'lib_defines', 'lib_cppflags', 'lib_cflags', etc. Reviewed-by:
-
Steven Noonan authored
CLA: trivial Signed-off-by:
Steven Noonan <steven@uplinklabs.net> Reviewed-by:
-
Alex Gaynor authored
Reviewed-by:
-
Matt Caswell authored
Allow users to distinguish between an error occurring and an HRR being issued. Fixes #5549 Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
We also default to SHA256 as per the spec if we do not have an explicit digest defined. Reviewed-by:
-
- Mar 08, 2018
-
-
Viktor Dukhovni authored
Reviewed-by: -
Richard Levitte authored
Reviewed-by:
-
Michael Richardson authored
Travis-ci log output is huge and overflows internal travis-ci view, which makes it hard to find errors. Redirect some output to a file and dump it only if it fails. Remove "v" option from tar that builds and extracts the srcdist. While running the tests manually, some non-POSIX (bashisms) with == vs = came to light. Reviewed-by:
-
Richard Levitte authored
The check to detect if env / make variables conflicted with compiler / linker flags on the configure command line went a little too far, and would stop the configuration process if any such command line flag was given, with no regard for the env / make variables at all. This change refines the check so the stop only gets triggered if any such flags were given AND any of the corresponding variables are set. Reviewed-by:
-
Richard Levitte authored
Fixes #5310 Reviewed-by:
-
Richard Levitte authored
Note that this might give surprising results if someone forgets an environment variable that has been set previously. Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Passing flags "discovered" by 'config' on the command line to 'Configure' mixes them up with flags given by the user. That is contrary to their intention, so they need to be passed in a different manner. Enter the environment variables __CNF_CPPDEFINES, __CNF_CPPINCLUDES, __CNF_CPPFLAGS, __CNF_CFLAGS, __CNF_CXXFLAGS, __CNF_LDFLAGS, and __CNF_LDLIBS, initialised by 'config', and then used by Configure to initialise these %config values: defines, includes, cppflags, cflags, cxxflags, lflags, and ex_libs. Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
With the support of "make variables" comes the possibility for the user to override them. However, we need to make a difference between defaults that we use (and that should be overridable by the user) and flags that are crucial for building OpenSSL (should not be overridable). Typically, overridable flags are those setting optimization levels, warnings levels, that kind of thing, while non-overridable flags are, for example, macros that indicate aspects of how the config target should be treated, such as L_ENDIAN and B_ENDIAN. We do that differentiation by allowing upper case attributes in the config targets, named exactly like the "make variables" we support, and reserving the lower case attributes for non-overridable project flags. Reviewed-by:
-
