kris/boringssl
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
fce7604350
boringssl/crypto/crypto.c

143 lines
4.5 KiB
C
Raw Normal View History

Add a CRYPTO_library_init and static-initializer-less build option. Chromium does not like static initializers, and the CPU logic uses one to initialize CPU bits. However, the crypto library lacks an explicit initialization function, which could complicate (no compile-time errors) porting existing code which uses crypto/, but not ssl/. Add an explicit CRYPTO_library_init function, but make it a no-op by default. It only does anything (and is required) if building with BORINGSSL_NO_STATIC_INITIALIZER. Change-Id: I6933bdc3447fb382b1f87c788e5b8142d6f3fe39 Reviewed-on: https://boringssl-review.googlesource.com/1770 Reviewed-by: Adam Langley <agl@google.com>
2014-09-12 00:11:15 +01:00
/* Copyright (c) 2014, Google Inc.
*
* Permission to use, copy, modify, and/or distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
* SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
* OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
* CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */
#include <openssl/crypto.h>
Become partially -Wmissing-variable-declarations-clean. There's a few things that will be kind of a nuisance and possibly not worth it (crypto/asn1 dumps a lot of undeclared things, etc.). But it caught some mistakes. Even without the warning, making sure to include the externs before defining a function helps catch type mismatches. Change-Id: I3dab282aaba6023e7cebc94ed7a767a5d7446b08 Reviewed-on: https://boringssl-review.googlesource.com/6484 Reviewed-by: Adam Langley <agl@google.com>
2015-11-12 05:33:18 +00:00
#include <openssl/cpu.h>
Add a CRYPTO_library_init and static-initializer-less build option. Chromium does not like static initializers, and the CPU logic uses one to initialize CPU bits. However, the crypto library lacks an explicit initialization function, which could complicate (no compile-time errors) porting existing code which uses crypto/, but not ssl/. Add an explicit CRYPTO_library_init function, but make it a no-op by default. It only does anything (and is required) if building with BORINGSSL_NO_STATIC_INITIALIZER. Change-Id: I6933bdc3447fb382b1f87c788e5b8142d6f3fe39 Reviewed-on: https://boringssl-review.googlesource.com/1770 Reviewed-by: Adam Langley <agl@google.com>
2014-09-12 00:11:15 +01:00
#include "internal.h"
aarch64 support. This is an initial cut at aarch64 support. I have only qemu to test it however—hopefully hardware will be coming soon. This also affects 32-bit ARM in that aarch64 chips can run 32-bit code and we would like to be able to take advantage of the crypto operations even in 32-bit mode. AES and GHASH should Just Work in this case: the -armx.pl files can be built for either 32- or 64-bit mode based on the flavour argument given to the Perl script. SHA-1 and SHA-256 don't work like this however because they've never support for multiple implementations, thus BoringSSL built for 32-bit won't use the SHA instructions on an aarch64 chip. No dedicated ChaCha20 or Poly1305 support yet. Change-Id: Ib275bc4894a365c8ec7c42f4e91af6dba3bd686c Reviewed-on: https://boringssl-review.googlesource.com/2801 Reviewed-by: Adam Langley <agl@google.com>
2015-01-09 23:44:37 +00:00
Allow ARM capabilities to be set at compile time. Some ARM environments don't support |getauxval| or signals and need to configure the capabilities of the chip at compile time. This change adds defines that allow them to do so. Change-Id: I4e6987f69dd13444029bc7ac7ed4dbf8fb1faa76 Reviewed-on: https://boringssl-review.googlesource.com/6280 Reviewed-by: Adam Langley <agl@google.com>
2015-10-16 23:46:46 +01:00
#if !defined(OPENSSL_NO_ASM) && !defined(OPENSSL_STATIC_ARMCAP) && \
aarch64 support. This is an initial cut at aarch64 support. I have only qemu to test it however—hopefully hardware will be coming soon. This also affects 32-bit ARM in that aarch64 chips can run 32-bit code and we would like to be able to take advantage of the crypto operations even in 32-bit mode. AES and GHASH should Just Work in this case: the -armx.pl files can be built for either 32- or 64-bit mode based on the flavour argument given to the Perl script. SHA-1 and SHA-256 don't work like this however because they've never support for multiple implementations, thus BoringSSL built for 32-bit won't use the SHA instructions on an aarch64 chip. No dedicated ChaCha20 or Poly1305 support yet. Change-Id: Ib275bc4894a365c8ec7c42f4e91af6dba3bd686c Reviewed-on: https://boringssl-review.googlesource.com/2801 Reviewed-by: Adam Langley <agl@google.com>
2015-01-09 23:44:37 +00:00
(defined(OPENSSL_X86) || defined(OPENSSL_X86_64) || \
defined(OPENSSL_ARM) || defined(OPENSSL_AARCH64))
/* x86, x86_64 and the ARMs need to record the result of a cpuid call for the
* asm to work correctly, unless compiled without asm code. */
Don't try to setup CPUID if NO_ASM. Change-Id: Idec1cda87b0a58e9350d0e10c3251a2c47ac1929 Reviewed-on: https://boringssl-review.googlesource.com/1790 Reviewed-by: Adam Langley <agl@google.com>
2014-09-19 18:15:33 +01:00
#define NEED_CPUID
Add a CRYPTO_library_init and static-initializer-less build option. Chromium does not like static initializers, and the CPU logic uses one to initialize CPU bits. However, the crypto library lacks an explicit initialization function, which could complicate (no compile-time errors) porting existing code which uses crypto/, but not ssl/. Add an explicit CRYPTO_library_init function, but make it a no-op by default. It only does anything (and is required) if building with BORINGSSL_NO_STATIC_INITIALIZER. Change-Id: I6933bdc3447fb382b1f87c788e5b8142d6f3fe39 Reviewed-on: https://boringssl-review.googlesource.com/1770 Reviewed-by: Adam Langley <agl@google.com>
2014-09-12 00:11:15 +01:00
Don't try to setup CPUID if NO_ASM. Change-Id: Idec1cda87b0a58e9350d0e10c3251a2c47ac1929 Reviewed-on: https://boringssl-review.googlesource.com/1790 Reviewed-by: Adam Langley <agl@google.com>
2014-09-19 18:15:33 +01:00
#else
/* Otherwise, don't emit a static initialiser. */
#if !defined(BORINGSSL_NO_STATIC_INITIALIZER)
Add a CRYPTO_library_init and static-initializer-less build option. Chromium does not like static initializers, and the CPU logic uses one to initialize CPU bits. However, the crypto library lacks an explicit initialization function, which could complicate (no compile-time errors) porting existing code which uses crypto/, but not ssl/. Add an explicit CRYPTO_library_init function, but make it a no-op by default. It only does anything (and is required) if building with BORINGSSL_NO_STATIC_INITIALIZER. Change-Id: I6933bdc3447fb382b1f87c788e5b8142d6f3fe39 Reviewed-on: https://boringssl-review.googlesource.com/1770 Reviewed-by: Adam Langley <agl@google.com>
2014-09-12 00:11:15 +01:00
#define BORINGSSL_NO_STATIC_INITIALIZER
#endif
aarch64 support. This is an initial cut at aarch64 support. I have only qemu to test it however—hopefully hardware will be coming soon. This also affects 32-bit ARM in that aarch64 chips can run 32-bit code and we would like to be able to take advantage of the crypto operations even in 32-bit mode. AES and GHASH should Just Work in this case: the -armx.pl files can be built for either 32- or 64-bit mode based on the flavour argument given to the Perl script. SHA-1 and SHA-256 don't work like this however because they've never support for multiple implementations, thus BoringSSL built for 32-bit won't use the SHA instructions on an aarch64 chip. No dedicated ChaCha20 or Poly1305 support yet. Change-Id: Ib275bc4894a365c8ec7c42f4e91af6dba3bd686c Reviewed-on: https://boringssl-review.googlesource.com/2801 Reviewed-by: Adam Langley <agl@google.com>
2015-01-09 23:44:37 +00:00
#endif /* !OPENSSL_NO_ASM && (OPENSSL_X86 || OPENSSL_X86_64 ||
OPENSSL_ARM || OPENSSL_AARCH64) */
/* The capability variables are defined in this file in order to work around a
* linker bug. When linking with a .a, if no symbols in a .o are referenced
* then the .o is discarded, even if it has constructor functions.
*
* This still means that any binaries that don't include some functionality
* that tests the capability values will still skip the constructor but, so
* far, the init constructor function only sets the capability variables. */
#if defined(OPENSSL_X86) || defined(OPENSSL_X86_64)
/* This value must be explicitly initialised to zero in order to work around a
* bug in libtool or the linker on OS X.
*
* If not initialised then it becomes a "common symbol". When put into an
* archive, linking on OS X will fail to resolve common symbols. By
* initialising it to zero, it becomes a "data symbol", which isn't so
* affected. */
uint32_t OPENSSL_ia32cap_P[4] = {0};
#elif defined(OPENSSL_ARM) || defined(OPENSSL_AARCH64)
Move arm_arch.h and fix up lots of include paths. arm_arch.h is included from ARM asm files, but lives in crypto/, not openssl/include/. Since the asm files are often built from a different location than their position in the source tree, relative include paths are unlikely to work so, rather than having crypto/ be a de-facto, second global include path, this change moves arm_arch.h to include/openssl/. It also removes entries from many include paths because they should be needed as relative includes are always based on the locations of the source file. Change-Id: I638ff43d641ca043a4fc06c0d901b11c6ff73542 Reviewed-on: https://boringssl-review.googlesource.com/5746 Reviewed-by: Adam Langley <agl@google.com>
2015-08-25 02:03:17 +01:00
#include <openssl/arm_arch.h>
aarch64 support. This is an initial cut at aarch64 support. I have only qemu to test it however—hopefully hardware will be coming soon. This also affects 32-bit ARM in that aarch64 chips can run 32-bit code and we would like to be able to take advantage of the crypto operations even in 32-bit mode. AES and GHASH should Just Work in this case: the -armx.pl files can be built for either 32- or 64-bit mode based on the flavour argument given to the Perl script. SHA-1 and SHA-256 don't work like this however because they've never support for multiple implementations, thus BoringSSL built for 32-bit won't use the SHA instructions on an aarch64 chip. No dedicated ChaCha20 or Poly1305 support yet. Change-Id: Ib275bc4894a365c8ec7c42f4e91af6dba3bd686c Reviewed-on: https://boringssl-review.googlesource.com/2801 Reviewed-by: Adam Langley <agl@google.com>
2015-01-09 23:44:37 +00:00
Allow ARM capabilities to be set at compile time. Some ARM environments don't support |getauxval| or signals and need to configure the capabilities of the chip at compile time. This change adds defines that allow them to do so. Change-Id: I4e6987f69dd13444029bc7ac7ed4dbf8fb1faa76 Reviewed-on: https://boringssl-review.googlesource.com/6280 Reviewed-by: Adam Langley <agl@google.com>
2015-10-16 23:46:46 +01:00
#if defined(OPENSSL_STATIC_ARMCAP)
uint32_t OPENSSL_armcap_P =
#if defined(OPENSSL_STATIC_ARMCAP_NEON) || defined(__ARM_NEON__)
ARMV7_NEON | ARMV7_NEON_FUNCTIONAL |
#endif
#if defined(OPENSSL_STATIC_ARMCAP_AES)
ARMV8_AES |
#endif
#if defined(OPENSSL_STATIC_ARMCAP_SHA1)
ARMV8_SHA1 |
#endif
#if defined(OPENSSL_STATIC_ARMCAP_SHA256)
ARMV8_SHA256 |
#endif
#if defined(OPENSSL_STATIC_ARMCAP_PMULL)
ARMV8_PMULL |
#endif
0;
#elif defined(__ARM_NEON__)
aarch64 support. This is an initial cut at aarch64 support. I have only qemu to test it however—hopefully hardware will be coming soon. This also affects 32-bit ARM in that aarch64 chips can run 32-bit code and we would like to be able to take advantage of the crypto operations even in 32-bit mode. AES and GHASH should Just Work in this case: the -armx.pl files can be built for either 32- or 64-bit mode based on the flavour argument given to the Perl script. SHA-1 and SHA-256 don't work like this however because they've never support for multiple implementations, thus BoringSSL built for 32-bit won't use the SHA instructions on an aarch64 chip. No dedicated ChaCha20 or Poly1305 support yet. Change-Id: Ib275bc4894a365c8ec7c42f4e91af6dba3bd686c Reviewed-on: https://boringssl-review.googlesource.com/2801 Reviewed-by: Adam Langley <agl@google.com>
2015-01-09 23:44:37 +00:00
uint32_t OPENSSL_armcap_P = ARMV7_NEON | ARMV7_NEON_FUNCTIONAL;
#else
uint32_t OPENSSL_armcap_P = ARMV7_NEON_FUNCTIONAL;
#endif
#endif
Don't try to setup CPUID if NO_ASM. Change-Id: Idec1cda87b0a58e9350d0e10c3251a2c47ac1929 Reviewed-on: https://boringssl-review.googlesource.com/1790 Reviewed-by: Adam Langley <agl@google.com>
2014-09-19 18:15:33 +01:00
Make CRYPTO_library_init use a CRYPTO_once_t. Initialization by multiple consumers on ARM is still problematic due to CRYPTO_set_NEON_{capable,functional}, until we reimplement that in-library, but if that is called before the first CRYPTO_library_init, this change makes it safe. BUG=556462 Change-Id: I5845d09cca909bace8293ba7adf09a3bd0d4f943 Reviewed-on: https://boringssl-review.googlesource.com/6519 Reviewed-by: Adam Langley <agl@google.com>
2015-11-19 16:39:46 +00:00
#if defined(OPENSSL_WINDOWS) && !defined(BORINGSSL_NO_STATIC_INITIALIZER)
Add a CRYPTO_library_init and static-initializer-less build option. Chromium does not like static initializers, and the CPU logic uses one to initialize CPU bits. However, the crypto library lacks an explicit initialization function, which could complicate (no compile-time errors) porting existing code which uses crypto/, but not ssl/. Add an explicit CRYPTO_library_init function, but make it a no-op by default. It only does anything (and is required) if building with BORINGSSL_NO_STATIC_INITIALIZER. Change-Id: I6933bdc3447fb382b1f87c788e5b8142d6f3fe39 Reviewed-on: https://boringssl-review.googlesource.com/1770 Reviewed-by: Adam Langley <agl@google.com>
2014-09-12 00:11:15 +01:00
#define OPENSSL_CDECL __cdecl
#else
#define OPENSSL_CDECL
#endif
Make CRYPTO_library_init use a CRYPTO_once_t. Initialization by multiple consumers on ARM is still problematic due to CRYPTO_set_NEON_{capable,functional}, until we reimplement that in-library, but if that is called before the first CRYPTO_library_init, this change makes it safe. BUG=556462 Change-Id: I5845d09cca909bace8293ba7adf09a3bd0d4f943 Reviewed-on: https://boringssl-review.googlesource.com/6519 Reviewed-by: Adam Langley <agl@google.com>
2015-11-19 16:39:46 +00:00
#if defined(BORINGSSL_NO_STATIC_INITIALIZER)
static CRYPTO_once_t once = CRYPTO_ONCE_INIT;
#elif defined(OPENSSL_WINDOWS)
Add a CRYPTO_library_init and static-initializer-less build option. Chromium does not like static initializers, and the CPU logic uses one to initialize CPU bits. However, the crypto library lacks an explicit initialization function, which could complicate (no compile-time errors) porting existing code which uses crypto/, but not ssl/. Add an explicit CRYPTO_library_init function, but make it a no-op by default. It only does anything (and is required) if building with BORINGSSL_NO_STATIC_INITIALIZER. Change-Id: I6933bdc3447fb382b1f87c788e5b8142d6f3fe39 Reviewed-on: https://boringssl-review.googlesource.com/1770 Reviewed-by: Adam Langley <agl@google.com>
2014-09-12 00:11:15 +01:00
#pragma section(".CRT$XCU", read)
static void __cdecl do_library_init(void);
__declspec(allocate(".CRT$XCU")) void(*library_init_constructor)(void) =
do_library_init;
Make CRYPTO_library_init use a CRYPTO_once_t. Initialization by multiple consumers on ARM is still problematic due to CRYPTO_set_NEON_{capable,functional}, until we reimplement that in-library, but if that is called before the first CRYPTO_library_init, this change makes it safe. BUG=556462 Change-Id: I5845d09cca909bace8293ba7adf09a3bd0d4f943 Reviewed-on: https://boringssl-review.googlesource.com/6519 Reviewed-by: Adam Langley <agl@google.com>
2015-11-19 16:39:46 +00:00
#else
static void do_library_init(void) __attribute__ ((constructor));
Add a CRYPTO_library_init and static-initializer-less build option. Chromium does not like static initializers, and the CPU logic uses one to initialize CPU bits. However, the crypto library lacks an explicit initialization function, which could complicate (no compile-time errors) porting existing code which uses crypto/, but not ssl/. Add an explicit CRYPTO_library_init function, but make it a no-op by default. It only does anything (and is required) if building with BORINGSSL_NO_STATIC_INITIALIZER. Change-Id: I6933bdc3447fb382b1f87c788e5b8142d6f3fe39 Reviewed-on: https://boringssl-review.googlesource.com/1770 Reviewed-by: Adam Langley <agl@google.com>
2014-09-12 00:11:15 +01:00
#endif
/* do_library_init is the actual initialization function. If
* BORINGSSL_NO_STATIC_INITIALIZER isn't defined, this is set as a static
* initializer. Otherwise, it is called by CRYPTO_library_init. */
static void OPENSSL_CDECL do_library_init(void) {
aarch64 support. This is an initial cut at aarch64 support. I have only qemu to test it however—hopefully hardware will be coming soon. This also affects 32-bit ARM in that aarch64 chips can run 32-bit code and we would like to be able to take advantage of the crypto operations even in 32-bit mode. AES and GHASH should Just Work in this case: the -armx.pl files can be built for either 32- or 64-bit mode based on the flavour argument given to the Perl script. SHA-1 and SHA-256 don't work like this however because they've never support for multiple implementations, thus BoringSSL built for 32-bit won't use the SHA instructions on an aarch64 chip. No dedicated ChaCha20 or Poly1305 support yet. Change-Id: Ib275bc4894a365c8ec7c42f4e91af6dba3bd686c Reviewed-on: https://boringssl-review.googlesource.com/2801 Reviewed-by: Adam Langley <agl@google.com>
2015-01-09 23:44:37 +00:00
/* WARNING: this function may only configure the capability variables. See the
* note above about the linker bug. */
Don't try to setup CPUID if NO_ASM. Change-Id: Idec1cda87b0a58e9350d0e10c3251a2c47ac1929 Reviewed-on: https://boringssl-review.googlesource.com/1790 Reviewed-by: Adam Langley <agl@google.com>
2014-09-19 18:15:33 +01:00
#if defined(NEED_CPUID)
Add a CRYPTO_library_init and static-initializer-less build option. Chromium does not like static initializers, and the CPU logic uses one to initialize CPU bits. However, the crypto library lacks an explicit initialization function, which could complicate (no compile-time errors) porting existing code which uses crypto/, but not ssl/. Add an explicit CRYPTO_library_init function, but make it a no-op by default. It only does anything (and is required) if building with BORINGSSL_NO_STATIC_INITIALIZER. Change-Id: I6933bdc3447fb382b1f87c788e5b8142d6f3fe39 Reviewed-on: https://boringssl-review.googlesource.com/1770 Reviewed-by: Adam Langley <agl@google.com>
2014-09-12 00:11:15 +01:00
OPENSSL_cpuid_setup();
#endif
}
void CRYPTO_library_init(void) {
/* TODO(davidben): It would be tidier if this build knob could be replaced
* with an internal lazy-init mechanism that would handle things correctly
Make CRYPTO_library_init use a CRYPTO_once_t. Initialization by multiple consumers on ARM is still problematic due to CRYPTO_set_NEON_{capable,functional}, until we reimplement that in-library, but if that is called before the first CRYPTO_library_init, this change makes it safe. BUG=556462 Change-Id: I5845d09cca909bace8293ba7adf09a3bd0d4f943 Reviewed-on: https://boringssl-review.googlesource.com/6519 Reviewed-by: Adam Langley <agl@google.com>
2015-11-19 16:39:46 +00:00
* in-library. https://crbug.com/542879 */
Add a CRYPTO_library_init and static-initializer-less build option. Chromium does not like static initializers, and the CPU logic uses one to initialize CPU bits. However, the crypto library lacks an explicit initialization function, which could complicate (no compile-time errors) porting existing code which uses crypto/, but not ssl/. Add an explicit CRYPTO_library_init function, but make it a no-op by default. It only does anything (and is required) if building with BORINGSSL_NO_STATIC_INITIALIZER. Change-Id: I6933bdc3447fb382b1f87c788e5b8142d6f3fe39 Reviewed-on: https://boringssl-review.googlesource.com/1770 Reviewed-by: Adam Langley <agl@google.com>
2014-09-12 00:11:15 +01:00
#if defined(BORINGSSL_NO_STATIC_INITIALIZER)
Make CRYPTO_library_init use a CRYPTO_once_t. Initialization by multiple consumers on ARM is still problematic due to CRYPTO_set_NEON_{capable,functional}, until we reimplement that in-library, but if that is called before the first CRYPTO_library_init, this change makes it safe. BUG=556462 Change-Id: I5845d09cca909bace8293ba7adf09a3bd0d4f943 Reviewed-on: https://boringssl-review.googlesource.com/6519 Reviewed-by: Adam Langley <agl@google.com>
2015-11-19 16:39:46 +00:00
CRYPTO_once(&once, do_library_init);
Add a CRYPTO_library_init and static-initializer-less build option. Chromium does not like static initializers, and the CPU logic uses one to initialize CPU bits. However, the crypto library lacks an explicit initialization function, which could complicate (no compile-time errors) porting existing code which uses crypto/, but not ssl/. Add an explicit CRYPTO_library_init function, but make it a no-op by default. It only does anything (and is required) if building with BORINGSSL_NO_STATIC_INITIALIZER. Change-Id: I6933bdc3447fb382b1f87c788e5b8142d6f3fe39 Reviewed-on: https://boringssl-review.googlesource.com/1770 Reviewed-by: Adam Langley <agl@google.com>
2014-09-12 00:11:15 +01:00
#endif
}
Compatibility changes for wpa_supplicant and OpenSSH. OpenSSH, especially, does some terrible things that mean that it needs the EVP_CIPHER structure to be exposed ☹. Damian is open to a better API to replace this, but only if OpenSSL agree too. Either way, it won't be happening soon. Change-Id: I393b7a6af6694d4d2fe9ebcccd40286eff4029bd Reviewed-on: https://boringssl-review.googlesource.com/4330 Reviewed-by: Adam Langley <agl@google.com>
2015-04-13 22:34:17 +01:00
const char *SSLeay_version(int unused) {
Fix |SSLeay|. SSLeay is a compatibility function for OpenSSL, but I got it wrong. It doesn't return a string, it returns a number. This doesn't end up making any difference, but it fixes a warning when building OpenSSH. Change-Id: I327ab4f70313c93c18f81d8804ba4acdc3bc1a4a Reviewed-on: https://boringssl-review.googlesource.com/4811 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2015-05-20 00:30:20 +01:00
return "BoringSSL";
Compatibility changes for wpa_supplicant and OpenSSH. OpenSSH, especially, does some terrible things that mean that it needs the EVP_CIPHER structure to be exposed ☹. Damian is open to a better API to replace this, but only if OpenSSL agree too. Either way, it won't be happening soon. Change-Id: I393b7a6af6694d4d2fe9ebcccd40286eff4029bd Reviewed-on: https://boringssl-review.googlesource.com/4330 Reviewed-by: Adam Langley <agl@google.com>
2015-04-13 22:34:17 +01:00
}
Fix |SSLeay|. SSLeay is a compatibility function for OpenSSL, but I got it wrong. It doesn't return a string, it returns a number. This doesn't end up making any difference, but it fixes a warning when building OpenSSH. Change-Id: I327ab4f70313c93c18f81d8804ba4acdc3bc1a4a Reviewed-on: https://boringssl-review.googlesource.com/4811 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2015-05-20 00:30:20 +01:00
unsigned long SSLeay(void) {
return OPENSSL_VERSION_NUMBER;
Compatibility changes for wpa_supplicant and OpenSSH. OpenSSH, especially, does some terrible things that mean that it needs the EVP_CIPHER structure to be exposed ☹. Damian is open to a better API to replace this, but only if OpenSSL agree too. Either way, it won't be happening soon. Change-Id: I393b7a6af6694d4d2fe9ebcccd40286eff4029bd Reviewed-on: https://boringssl-review.googlesource.com/4330 Reviewed-by: Adam Langley <agl@google.com>
2015-04-13 22:34:17 +01:00
}
Add no-op functions |CRYPTO_malloc_init| and |ENGINE_load_builtin_engines|. This reduces the impact on Netty. See https://github.com/Scottmitch/netty-tcnative/commit/904b84ce41fc44dd1d3955df69912d91906c9877#commitcomment-12159877 Change-Id: I22f9e1edaeb9e721326867ae2b4f3da2c5441437 Reviewed-on: https://boringssl-review.googlesource.com/5535 Reviewed-by: Adam Langley <alangley@gmail.com>
2015-08-02 17:35:44 +01:00
int CRYPTO_malloc_init(void) {
return 1;
}
void ENGINE_load_builtin_engines(void) {}
Add a few more no-op stubs for cURL compatibility. With these stubs, cURL should not need any BoringSSL #ifdefs at all, except for their OCSP #ifdefs (which can switch to the more generally useful OPENSSL_NO_OCSP) and the workaround for wincrypt.h macro collisions. That we intentionally leave to the consumer rather than add a partial hack that makes the build sensitive to include order. (I'll send them a patch upstream once this cycles in.) Change-Id: I815fe67e51e80e9aafa9b91ae68867ca1ff1d623 Reviewed-on: https://boringssl-review.googlesource.com/6980 Reviewed-by: Adam Langley <agl@google.com>
2016-01-26 06:09:19 +00:00
void OPENSSL_load_builtin_modules(void) {}
Reference in New Issue Copy Permalink