Skip to content

T
Third Party Openssl

OpenHarmony / Third Party Openssl
10 个月 前同步成功

通知 8
Star 18
Fork 1
T
Third Party Openssl

前往新版Gitcode，体验更适合开发者的 AI 搜索 >>

切换分支/标签
  1. 08 6月, 2018 1 次提交
  3. 04 6月, 2018 1 次提交
  5. 30 5月, 2018 1 次提交
  7. 29 5月, 2018 4 次提交
  9. 27 5月, 2018 1 次提交
  11. 18 5月, 2018 1 次提交
  13. 01 5月, 2018 1 次提交
  15. 05 4月, 2018 1 次提交
    • M
      Move the loading of the ssl_conf module to libcrypto · d8f031e8
      由 Matt Caswell 提交于 
      The GOST engine needs to be loaded before we initialise libssl. Otherwise
the GOST ciphersuites are not enabled. However the SSL conf module must
be loaded before we initialise libcrypto. Otherwise we will fail to read
the SSL config from a config file properly.

Another problem is that an application may make use of both libcrypto and
libssl. If it performs libcrypto stuff first and OPENSSL_init_crypto()
is called and loads a config file it will fail if that config file has
any libssl stuff in it.

This commit separates out the loading of the SSL conf module from the
interpretation of its contents. The loading piece doesn't know anything
about SSL so this can be moved to libcrypto. The interpretation of what it
means remains in libssl. This means we can load the SSL conf data before
libssl is there and interpret it when it later becomes available.

Fixes #5809
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5818)
      d8f031e8
  17. 20 3月, 2018 1 次提交
  19. 19 3月, 2018 2 次提交
  21. 17 3月, 2018 1 次提交
  23. 16 3月, 2018 1 次提交
  25. 15 3月, 2018 4 次提交
  27. 10 3月, 2018 1 次提交
    • D
      RAND_DRBG: add a function for setting the reseeding defaults · 4917e911
      由 Dr. Matthias St. Pierre 提交于 
      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: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5576)
      4917e911
  29. 23 2月, 2018 2 次提交
  31. 20 2月, 2018 2 次提交
  33. 15 2月, 2018 2 次提交
  35. 14 2月, 2018 2 次提交
  37. 10 2月, 2018 1 次提交
  39. 01 2月, 2018 1 次提交
    • B
      Revert the crypto "global lock" implementation · 63ab5ea1
      由 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)
      63ab5ea1
  41. 29 1月, 2018 1 次提交
  43. 25 1月, 2018 1 次提交
    • D
      Add -rsigopt option to ocsp command · b4dd21a7
      由 David Cooper 提交于 
      Add a -rsigopt option to the ocsp command that allows signature parameters to be provided for the signing of OCSP responses. The parameters that may be provided to -rsigopt are the same as may be provided to -sigopt in the ca, req, and x509 commands.

This PR also defines a OCSP_basic_sign_ctx() function, which functions in the same way as OCSP_basic_sign(), except that it accepts a EVP_MD_CTX rather than a key and digest. The OCSP_basic_sign_ctx() function is used to implement the -rsigopt option in the ocsp command.
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4190)
      b4dd21a7
  45. 24 1月, 2018 1 次提交
  47. 23 1月, 2018 1 次提交
  49. 18 12月, 2017 2 次提交
  51. 21 11月, 2017 1 次提交
    • P
      Support multi-prime RSA (RFC 8017) · 665d899f
      由 Paul Yang 提交于 
      * Introduce RSA_generate_multi_prime_key to generate multi-prime
  RSA private key. As well as the following functions:
    RSA_get_multi_prime_extra_count
    RSA_get0_multi_prime_factors
    RSA_get0_multi_prime_crt_params
    RSA_set0_multi_prime_params
    RSA_get_version
* Support EVP operations for multi-prime RSA
* Support ASN.1 operations for multi-prime RSA
* Support multi-prime check in RSA_check_key_ex
* Support multi-prime RSA in apps/genrsa and apps/speed
* Support multi-prime RSA manipulation functions
* Test cases and documentation are added
* CHANGES is updated
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/4241)
      665d899f
  53. 20 11月, 2017 1 次提交
  55. 12 11月, 2017 1 次提交