Skip to content

T
Third Party Openssl

OpenHarmony / Third Party Openssl
1 年多 前同步成功

通知 10
Star 18
Fork 1
T
Third Party Openssl
切换分支/标签
  1. 26 2月, 2019 10 次提交
  3. 23 2月, 2019 3 次提交
    • R
      Windows: Call TerminateProcess, not ExitProcess · 4af54c9b
      由 Richard Levitte 提交于 
      Ty Baen-Price explains:

> Problem and Resolution:
> The following lines of code make use of the Microsoft API ExitProcess:
>
> ```
> Apps\Speed.c line 335:	ExitProcess(ret);
> Ms\uplink.c line 22: ExitProcess(1);
> ```
>
> These function calls are made after fatal errors are detected and
> program termination is desired. ExitProcess(), however causes
> _orderly_ shutdown of a process and all its threads, i.e. it unloads
> all dlls and runs all destructors. See MSDN for details of exactly
> what happens
> (https://msdn.microsoft.com/en-us/library/windows/desktop/ms682658(v=vs.85).aspx).
> The MSDN page states that ExitProcess should never be called unless
> it is _known to be safe_ to call it. These calls should simply be
> replaced with calls to TerminateProcess(), which is what should be
> called for _disorderly_ shutdown.
>
> An example of usage:
>
> ```
> TerminateProcess(GetCurrentProcess(), exitcode);
> ```
>
> Effect of Problem:
> Because of a compilation error (wrong c++ runtime), my program
> executed the uplink.c ExitProcess() call. This caused the single
> OpenSSL thread to start executing the destructors of all my dlls,
> and their objects. Unfortunately, about 30 other threads were
> happily using those objects at that time, eventually causing a
> 0xC0000005 ACCESS_VIOLATION. Obviously an ACCESS_VIOLATION is the
> best case scenario, as I'm sure you can imagine at the consequences
> of undiscovered memory corruption, even in a terminating process.

And on the subject of `TerminateProcess()` being asynchronous:

> That is technically true, but I think it's probably synchronous
> "enough" for your purposes, since a call to TerminateProcess
> suspends execution of all threads in the target process. This means
> it's really only asynchronous if you're calling TerminateProcess one
> some _other_ process. If you're calling TerminateProcess on your own
> process, you'll never return from the TerminateProcess call.

Fixes #2489
Was originally RT-4526
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8301)

(cherry picked from commit 925795995018bddb053e863db8b5c52d2a9005d9)
      4af54c9b
    • M
      Don't restrict the number of KeyUpdate messages we can process · f6d64b51
      由 Matt Caswell 提交于 
      Prior to this commit we were keeping a count of how many KeyUpdates we
have processed and failing if we had had too many. This simplistic approach
is not sufficient for long running connections. Since many KeyUpdates
would not be a particular good DoS route anyway, the simplest solution is
to simply remove the key update count.

Fixes #8068
Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/8299)

(cherry picked from commit 3409a5ff8a44ddaf043d83ed22e657ae871be289)
      f6d64b51
    • D
      engines/dasync: add explaining comments about AES-128-CBC-HMAC-SHA1 · 4a81b8b6
      由 Dr. Matthias St. Pierre 提交于 
      Fixes #7950

It was reported that there might be a null pointer dereference in the
implementation of the dasync_aes_128_cbc_hmac_sha1() cipher, because
EVP_aes_128_cbc_hmac_sha1() can return a null pointer if AES-NI is
not available. It took some analysis to find out that this is not
an issue in practice, and these comments explain the reason to comfort
further NPD hunters.

Detected by GitHub user @wurongxin1987 using the Sourcebrella Pinpoint
static analyzer.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8305)

(cherry picked from commit a4a0a1eb43cfccd128d085932a567e0482fbfe47)
      4a81b8b6
  5. 22 2月, 2019 1 次提交
  7. 21 2月, 2019 6 次提交
  9. 20 2月, 2019 1 次提交
  11. 19 2月, 2019 4 次提交
  13. 18 2月, 2019 4 次提交
  15. 15 2月, 2019 4 次提交
    • R
      Mark generated functions unused (applies to safestack, lhash, sparse_array) · ed48d203
      由 Richard Levitte 提交于 
      safestack.h, lhash.h and sparse_array.h all define macros to generate
a full API for the containers as static inline functions.  This
potentially generates unused code, which some compilers may complain
about.

We therefore need to mark those generated functions as unused, so the
compiler knows that we know, and stops complaining about it.
Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/8246)

(cherry picked from commit 48fe4ce104df060dd5d2b4188a56eb554d94d819)
      ed48d203
    • M
      Use order not degree to calculate a buffer size in ecdsatest · 1b25dc0c
      由 Matt Caswell 提交于 
      Otherwise this can result in an incorrect calculation of the maximum
encoded integer length, meaning an insufficient buffer size is allocated.

Thanks to Billy Brumley for helping to track this down.

Fixes #8209
Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8237)

(cherry picked from commit 9fc8f18f59f4a4c853466dca64a23b8af681bf1c)
      1b25dc0c
    • M
      Fix -verify_return_error in s_client · 9c931841
      由 Matt Caswell 提交于 
      The "verify_return_error" option in s_client is documented as:

 Return verification errors instead of continuing. This will typically
 abort the handshake with a fatal error.

In practice this option was ignored unless also accompanied with the
"-verify" option. It's unclear what the original intention was. One fix
could have been to change the documentation to match the actual behaviour.
However it seems unecessarily complex and unexpected that you should need
to have both options. Instead the fix implemented here is make the option
match the documentation so that "-verify" is not also required.

Note that s_server has a similar option where "-verify" (or "-Verify") is
still required. This makes more sense because those options additionally
request a certificate from the client. Without a certificate there is no
possibility of a verification failing, and so "-verify_return_error" doing
nothing seems ok.

Fixes #8079
Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/8080)

(cherry picked from commit 78021171dbcb05ddab1b5daffbfc62504ea709a4)
      9c931841
    • M
      Don't signal SSL_CB_HANDSHAKE_START for TLSv1.3 post-handshake messages · 37857e9b
      由 Matt Caswell 提交于 
      The original 1.1.1 design was to use SSL_CB_HANDSHAKE_START and
SSL_CB_HANDSHAKE_DONE to signal start/end of a post-handshake message
exchange in TLSv1.3. Unfortunately experience has shown that this confuses
some applications who mistake it for a TLSv1.2 renegotiation. This means
that KeyUpdate messages are not handled properly.

This commit removes the use of SSL_CB_HANDSHAKE_START and
SSL_CB_HANDSHAKE_DONE to signal the start/end of a post-handshake
message exchange. Individual post-handshake messages are still signalled in
the normal way.

This is a potentially breaking change if there are any applications already
written that expect to see these TLSv1.3 events. However, without it,
KeyUpdate is not currently usable for many applications.

Fixes #8069
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8096)

(cherry picked from commit 4af5836b55442f31795eff6c8c81ea7a1b8cf94b)
      37857e9b
  17. 14 2月, 2019 3 次提交
  19. 13 2月, 2019 2 次提交
  21. 11 2月, 2019 2 次提交