- 26 5月, 2023 1 次提交
-
-
由 code4lala 提交于
Signed-off-by: Ncode4lala <fengziteng2@huawei.com> Change-Id: I5269be7d8e6c8ac399d86d9b48bfbd5cfabe0d19
-
- 12 4月, 2023 2 次提交
-
-
由 code4lala 提交于
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
-
由 code4lala 提交于
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
-
- 10 8月, 2021 1 次提交
-
-
由 HJ 提交于
Signed-off-by: NHJ <huangjun42@huawei.com>
-
- 31 3月, 2020 1 次提交
-
-
由 Matt Caswell 提交于
Reviewed-by: NPaul Dale <paul.dale@oracle.com> Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11445)
-
- 20 3月, 2020 1 次提交
-
-
由 FdaSilvaYY 提交于
Found by Coverity. Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NTim Hudson <tjh@openssl.org> Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8274) (cherry picked from commit 23dc8feba817560485da00d690d7b7b9e5b15682)
-
- 27 2月, 2020 1 次提交
-
-
由 h00416433 提交于
Description:openssl 1.1.1d used bu libhapverify Team:OTHERS Feature or Bugfix:Feature Binary Source:Yes, it is PrivateCode(Yes/No):No Change-Id: I8968f9c0f146b587da17a3e603bd04fb7b4c505b Reviewed-on: http://mgit-tm.rnd.huawei.com/7842784Tested-by: Npublic jenkins <public_jenkins@notesmail.huawei.com> Reviewed-by: Nhouyuezhou 00386575 <hou@huawei.com> Reviewed-by: Nlinyibin 00246405 <linyibin@huawei.com> Reviewed-by: Nweiping 00548480 <ping.wei@huawei.com>
-
- 28 9月, 2019 1 次提交
-
-
由 Dr. Matthias St. Pierre 提交于
Currently, there are two different directories which contain internal header files of libcrypto which are meant to be shared internally: While header files in 'include/internal' are intended to be shared between libcrypto and libssl, the files in 'crypto/include/internal' are intended to be shared inside libcrypto only. To make things complicated, the include search path is set up in such a way that the directive #include "internal/file.h" could refer to a file in either of these two directoroes. This makes it necessary in some cases to add a '_int.h' suffix to some files to resolve this ambiguity: #include "internal/file.h" # located in 'include/internal' #include "internal/file_int.h" # located in 'crypto/include/internal' This commit moves the private crypto headers from 'crypto/include/internal' to 'include/crypto' As a result, the include directives become unambiguous #include "internal/file.h" # located in 'include/internal' #include "crypto/file.h" # located in 'include/crypto' hence the superfluous '_int.h' suffixes can be stripped. The files 'store_int.h' and 'store.h' need to be treated specially; they are joined into a single file. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9681)
-
- 20 4月, 2018 1 次提交
-
-
由 Bernd Edlinger 提交于
Fixes: #5899 Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5911)
-
- 13 2月, 2018 1 次提交
-
-
由 Matt Caswell 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
- 01 2月, 2018 1 次提交
-
-
由 Benjamin Kaduk 提交于
Conceptually, this is a squashed version of: Revert "Address feedback" This reverts commit 75551e07. and Revert "Add CRYPTO_thread_glock_new" This reverts commit ed6b2c79. But there were some intervening commits that made neither revert apply cleanly, so instead do it all as one shot. The crypto global locks were an attempt to cope with the awkward POSIX semantics for pthread_atfork(); its documentation (the "RATIONALE" section) indicates that the expected usage is to have the prefork handler lock all "global" locks, and the parent and child handlers release those locks, to ensure that forking happens with a consistent (lock) state. However, the set of functions available in the child process is limited to async-signal-safe functions, and pthread_mutex_unlock() is not on the list of async-signal-safe functions! The only synchronization primitives that are async-signal-safe are the semaphore primitives, which are not really appropriate for general-purpose usage. However, the state consistency problem that the global locks were attempting to solve is not actually a serious problem, particularly for OpenSSL. That is, we can consider four cases of forking application that might use OpenSSL: (1) Single-threaded, does not call into OpenSSL in the child (e.g., the child calls exec() immediately) For this class of process, no locking is needed at all, since there is only ever a single thread of execution and the only reentrancy is due to signal handlers (which are themselves limited to async-signal-safe operation and should not be doing much work at all). (2) Single-threaded, calls into OpenSSL after fork() The application must ensure that it does not fork() with an unexpected lock held (that is, one that would get unlocked in the parent but accidentally remain locked in the child and cause deadlock). Since OpenSSL does not expose any of its internal locks to the application and the application is single-threaded, the OpenSSL internal locks will be unlocked for the fork(), and the state will be consistent. (OpenSSL will need to reseed its PRNG in the child, but that is an orthogonal issue.) If the application makes use of locks from libcrypto, proper handling for those locks is the responsibility of the application, as for any other locking primitive that is available for application programming. (3) Multi-threaded, does not call into OpenSSL after fork() As for (1), the OpenSSL state is only relevant in the parent, so no particular fork()-related handling is needed. The internal locks are relevant, but there is no interaction with the child to consider. (4) Multi-threaded, calls into OpenSSL after fork() This is the case where the pthread_atfork() hooks to ensure that all global locks are in a known state across fork() would come into play, per the above discussion. However, these "calls into OpenSSL after fork()" are still subject to the restriction to async-signal-safe functions. Since OpenSSL uses all sorts of locking and libc functions that are not on the list of safe functions (e.g., malloc()), this case is not currently usable and is unlikely to ever be usable, independently of the locking situation. So, there is no need to go through contortions to attempt to support this case in the one small area of locking interaction with fork(). In light of the above analysis (thanks @davidben and @achernya), go back to the simpler implementation that does not need to distinguish "library-global" locks or to have complicated atfork handling for locks. Reviewed-by: NKurt Roeckx <kurt@roeckx.be> Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/5089)
-
- 29 9月, 2017 1 次提交
-
-
由 Pauli 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4431)
-
- 01 9月, 2017 1 次提交
-
-
由 Rich Salz 提交于
Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/4294)
-
- 03 6月, 2017 1 次提交
-
-
由 Todd Short 提交于
Code was added in commit b3c31a65 that overwrote the last ex_data value using CRYPTO_dup_ex_data() causing a memory leak, and potentially confusing the ex_data dup() callback. In ssl_session_dup(), fix error handling (properly reference and up-ref shared data) and new-up the ex_data before calling CRYPTO_dup_ex_data(); all other structures that dup ex_data have the destination ex_data new'd before the dup. Fix up some of the ex_data documentation. Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3323)
-
- 20 3月, 2017 1 次提交
-
-
由 Bernd Edlinger 提交于
Fix a strict aliasing issue in ui_dup_method_data. Add test coverage for CRYPTO_dup_ex_data, use OPENSSL_assert. Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2988)
-
- 04 2月, 2017 1 次提交
-
-
由 Bernd Edlinger 提交于
Fixed a memory leak in ASN1_digest and ASN1_item_digest. Reworked error handling in asn1_item_embed_new. Fixed error handling in int_ctx_new and EVP_PKEY_CTX_dup. Fixed a memory leak in CRYPTO_free_ex_data. Reworked error handing in x509_name_ex_d2i, x509_name_encode and x509_name_canon. Check for null pointer in tls_process_cert_verify. Fixes #2103 #2104 #2105 #2109 #2111 #2115 Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2342)
-
- 08 9月, 2016 1 次提交
-
-
由 Matt Caswell 提交于
Certain functions are automatically called during auto-deinit in order to deallocate resources. However, if we have never entered a function which marks lib crypto as inited then they never get called. This can happen if the user only ever makes use of a small sub-set of functions that don't hit the auto-init code. This commit ensures all such resources deallocated by these functions also init libcrypto when they are initially allocated. Reviewed-by: NRichard Levitte <levitte@openssl.org> Reviewed-by: NBen Laurie <ben@openssl.org>
-
- 01 8月, 2016 1 次提交
-
-
由 Richard J. Moore 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
- 20 7月, 2016 1 次提交
-
-
由 Richard Levitte 提交于
That way, we have a way to check if the init function was successful or not. Reviewed-by: NKurt Roeckx <kurt@openssl.org>
-
- 18 5月, 2016 1 次提交
-
-
由 Rich Salz 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
- 17 5月, 2016 1 次提交
-
-
由 Viktor Dukhovni 提交于
Document thread-safe lock creation Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
- 15 4月, 2016 1 次提交
-
-
由 Matt Caswell 提交于
Travis identified a problem with freeing the ex_data locks which wasn't quite right in ff234405. Trying to fix it identified a further problem: the ex_data locks are cleaned up by OPENSSL_cleanup(), which is called explicitly by CRYPTO_mem_leaks(), but then later the BIO passed to CRYPTO_mem_leaks() is freed. An attempt is then made to use the ex_data lock already freed. Reviewed-by: NTim Hudson <tjh@openssl.org>
-
- 14 4月, 2016 1 次提交
-
-
由 Matt Caswell 提交于
Some locks were not being properly cleaned up during close down. Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
- 13 4月, 2016 3 次提交
-
-
由 Matt Caswell 提交于
There is a preference for suffixes to indicate that a function is internal rather than prefixes. Note: the suffix is only required to disambiguate internal functions and public symbols with the same name (but different case) Reviewed-by: NTim Hudson <tjh@openssl.org> Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
由 Matt Caswell 提交于
There was a lot of naming inconsistency, so we try and standardise on one form. Reviewed-by: NTim Hudson <tjh@openssl.org> Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
由 Matt Caswell 提交于
CRYPTO_cleanup_all_ex_data() should not be called expicitly - we should leave auto-deinit to clean this up instead. Reviewed-by: NTim Hudson <tjh@openssl.org> Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
- 23 3月, 2016 1 次提交
-
-
由 FdaSilvaYY 提交于
Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 13 3月, 2016 2 次提交
-
-
由 Richard Levitte 提交于
Reviewed-by: NKurt Roeckx <kurt@openssl.org>
-
由 Emilia Kasper 提交于
ENGINE_cleanup calls CRYPTO_free_ex_data and therefore, CRYPTO_cleanup_all_ex_data - which cleans up the method pointers - must run after ENGINE_cleanup. Additionally, don't needlessly initialize the EX_CALLBACKS stack during e.g. CRYPTO_free_ex_data. The only time this is actually needed is when reserving the first ex data index. Specifically, since sk_num returns -1 on NULL input, the rest of the code already handles a NULL method stack correctly. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 08 3月, 2016 1 次提交
-
-
由 Alessandro Ghedini 提交于
Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 06 2月, 2016 1 次提交
-
-
由 FdaSilvaYY 提交于
Signed-off-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NMatt Caswell <matt@openssl.org>
-
- 08 1月, 2016 2 次提交
-
-
由 Dr. Stephen Henson 提交于
Don't define stacks in C source files: it causes warnings about unused functions in some compilers. Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
由 Dr. Stephen Henson 提交于
Applications wishing to include their own stacks now just need to include DEFINE_STACK_OF(foo) in a header file. Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
- 02 12月, 2015 1 次提交
-
-
由 Rich Salz 提交于
Add CRYPTO_free_ex_index (for shared libraries) Unify and complete the documentation for all "ex_data" API's and objects. Replace xxx_get_ex_new_index functions with a macro. Added an exdata test. Renamed the ex_data internal datatypes. Reviewed-by: NMatt Caswell <matt@openssl.org>
-
- 10 11月, 2015 1 次提交
-
-
由 Matt Caswell 提交于
Continuing from previous commit ensure our style is consistent for malloc return checks. Reviewed-by: NKurt Roeckx <kurt@openssl.org>
-
- 20 7月, 2015 1 次提交
-
-
由 Rich Salz 提交于
Removed ability to set ex_data impl at runtime. This removed these three functions: const CRYPTO_EX_DATA_IMPL *CRYPTO_get_ex_data_implementation(void); int CRYPTO_set_ex_data_implementation(const CRYPTO_EX_DATA_IMPL *i); int CRYPTO_ex_data_new_class(void); It is no longer possible to change the ex_data implementation at runtime. (Luckily those functions were never documented :) Also removed the ability to add new exdata "classes." We don't believe this received much (if any) use, since you can't add it to OpenSSL objects, and there are probably better (native) methods for developers to add their own extensible data, if they really need that. Replaced the internal hash table (of per-"class" stacks) with a simple indexed array. Reserved an index for "app" application. Each API used to take the lock twice; now it only locks once. Use local stack storage for function pointers, rather than malloc, if possible (i.e., number of ex_data items is under a dozen). Make CRYPTO_EX_DATA_FUNCS opaque/internal. Also fixes RT3710; index zero is reserved. Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
- 14 5月, 2015 1 次提交
-
-
由 Richard Levitte 提交于
There are header files in crypto/ that are used by a number of crypto/ submodules. Move those to crypto/include/internal and adapt the affected source code and Makefiles. The header files that got moved are: crypto/cryptolib.h crypto/md32_common.h Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 05 5月, 2015 1 次提交
-
-
由 Rich Salz 提交于
For a local variable: TYPE *p; Allocations like this are "risky": p = OPENSSL_malloc(sizeof(TYPE)); if the type of p changes, and the malloc call isn't updated, you could get memory corruption. Instead do this: p = OPENSSL_malloc(sizeof(*p)); Also fixed a few memset() calls that I noticed while doing this. Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
- 02 5月, 2015 1 次提交
-
-
由 Rich Salz 提交于
After the finale, the "real" final part. :) Do a recursive grep with "-B1 -w [a-zA-Z0-9_]*_free" to see if any of the preceeding lines are an "if NULL" check that can be removed. Reviewed-by: NTim Hudson <tjh@openssl.org>
-
- 01 5月, 2015 1 次提交
-
-
由 Rich Salz 提交于
Don't check for NULL before calling OPENSSL_free Reviewed-by: NRichard Levitte <levitte@openssl.org>
-