- Apr 05, 2019
-
-
Richard Levitte authored
It was assumed that the config functionality returned a boolean. However, it may return a negative number on error, so we need to take that into account. Reviewed-by:
Matt Caswell <matt@openssl.org> Reviewed-by:
Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8679)
-
Richard Levitte authored
The three macros EVP_F_AESNI_XTS_INIT_KEY, EVP_F_AES_T4_XTS_INIT_KEY and EVP_F_AES_XTS_INIT_KEY are affected. Reviewed-by:
-
Pauli authored
than the update call. The means an earlier error return at the cost of some duplicated code. Reviewed-by:
Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/8625)
-
- Apr 04, 2019
-
-
Matt Caswell authored
Reviewed-by:
Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8537)
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Dr. Matthias St. Pierre authored
Fixes #8667 Reviewed-by:
-
Matt Caswell authored
There are some ciphersuites that were introduced in TLSv1.0/TLSv1.1 but are backwards compatible with SSLv3. Fixes #8655 Reviewed-by:
-
Matt Caswell authored
Fixes no-sm2 (and also no-sm3 and no-ec) Reviewed-by:
-
Richard Levitte authored
Since the macro to indicate if the test provider module is available is local to the test programs, it's better to use a name that isn't as easily confused with a library feature disabling macro that one would expect to find in opensslconf.h. Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
- Apr 03, 2019
-
-
Richard Levitte authored
The number that was used was already taken Reviewed-by:
-
Tomas Mraz authored
This prevents failure of openssl s_server socket binding to wildcard address on hosts with disabled IPv6. Reviewed-by:
Kurt Roeckx <kurt@roeckx.be> Reviewed-by:
-
Todd Short authored
Modify openssl OCSP utility to produce certIDs in responses using other hash algorithms (e.g. SHA256). Added option -rcid for this purpose. Reviewed-by:
Ben Kaduk <kaduk@mit.edu> Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Fixes #8565 Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Fixes #8613 Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
We reuse test/provider_internal_test.c and test/p_test.c, and get it loaded one more time via the configuration file test/provider_internal_test.conf To support different platform standards regarding module extensions, we generate test/provider_internal_test.conf Reviewed-by:
-
Richard Levitte authored
This configuration module supports a configuration structure pretty much like the engine configuration module, i.e. something like this: openssl_conf = openssl_init [openssl_init] providers = provider_section [provider_section] # Configure the provider named "foo" foo = foo_section # Configure the provider named "bar" bar = bar_section [foo_section] # Override name given in the provider section identity = myfoo # The exact path of the module. This is platform specific module_path = /opt/openssl/modules/foo.so # Whether it should be automatically activated. Value is unimportant activate = whatever # Anything else goes as well, and becomes parameters that the # provider can get what = 1 # sub-sections will be followed as well ever = ever_section [ever_section] cookie = monster All the configurations in a provider section and its sub-sections become parameters for the provider to get, i.e. the "foo" provider will be able to get values for the following keys (with associated values shown): identity => myfoo module_path => /opt/openssl/modules/foo.so activate => whatever what => 1 ever.cookie => monster Reviewed-by: -
Richard Levitte authored
Provider parameters are parameters set by the core that the provider can retrieve. The primary use it to support making OpenSSL configuration data available to the provider. Reviewed-by:
-
Pauli authored
Limit the number of AES blocks in a data unit to 2^20 or less. This corresponds to the mandates in IEEE Std 1619-2018 and NIST SP 800-38E. Note: that this is a change from IEEE Std 1619-2007 which only recommended this limit. Reviewed-by:
-
- Apr 02, 2019
-
-
Richard Levitte authored
I turns out that this made crypto/rand/rand_win.c to never build with BCrypt support unless the user sets _WIN32_WINNT. That wasn't the intent. This reverts commit cc8926ec . Reviewed-by:
-
Dr. Matthias St. Pierre authored
BCryptGenRandom() is available for Windows Vista and newer versions, see https://docs.microsoft.com/en-us/windows/desktop/api/bcrypt/nf-bcrypt-bcryptgenrandom Reviewed-by:
-
Richard Levitte authored
This helps decide if the BCrypt API should be used or not. Fixes #8635 Reviewed-by:
-
Richard Levitte authored
Previously, the macro OPENSSL_NO_SHARED was defined of the test/p_test module wasn't built, but the provider test programs didn't check that macro. We rename it to OPENSSL_NO_MODULE, since that name describes the situation more than OPENSSL_NO_SHARED does, and use it. Reviewed-by:
-
Richard Levitte authored
While we're at it, sort out inconsistencies with the build of modules: - not building shared libraries means not building dynamic engines. However, other modules may still be built. - not having DSO functionality doesn't mean not to build modules (even though we can't use them from apps linked with libraries that are built this way). Reviewed-by:
-
Richard Levitte authored
SHARED_SOURCE is reserved for products that are expected to come in dual shared / non-shared form, i.e. the routine libraries like libcrypto and libssl, to distinguish source that should only appear in their shared form. Modules are always shared, so there's no need for them to have this type of distinction. Reviewed-by:
-
- Apr 01, 2019
-
-
Richard Levitte authored
Removing the option entirely would break builds unnecessarily, so let's make it deprecated. Reviewed-by:
-
Boris Pismenny authored
Reviewed-by:
Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by:
-
Boris Pismenny authored
Reviewed-by:
-
Boris Pismenny authored
Add a unit-test for ktls receive side. Change-Id: I890588681d05fba419f644f6d903be6dc83c9ed5 Signed-off-by:
Boris Pismenny <borisp@mellanox.com> Reviewed-by:
-
Boris Pismenny authored
This patch adds support for the Linux TLS Rx socket option. It completes the previous patch for TLS Tx offload. If the socket option is successful, then the receive data-path of the TCP socket is implemented by the kernel. We choose to set this option at the earliest - just after CCS is complete. Change-Id: I59741e04d89dddca7fb138e88fffcc1259b30132 Signed-off-by:
-
Boris Pismenny authored
Add support for Linux TLS Rx offload in the BIO layer. Change-Id: I79924b25dd290a873d69f6c8d429e1f5bb2c3365 Signed-off-by:
-
Boris Pismenny authored
Introduce the infrastructure for supproting receive side Linux Kernel TLS data-path. Change-Id: I71864d8f9d74a701cc8b0ad5536005f3c1716c1c Signed-off-by:
-
Richard Levitte authored
'no-dso' is meaningless, as it doesn't get any macro defined. Therefore, we remove all checks of OPENSSL_NO_DSO. However, there may be some odd platforms with no DSO scheme. For those, we generate the internal macro DSO_NONE aand use it. Reviewed-by:
-
- Mar 31, 2019
-
-
x753 authored
"warning: iv not use by this cipher" -> "warning: iv not used by this cipher" CLA: trivial Reviewed-by:
Tim Hudson <tjh@openssl.org> Reviewed-by:
-
