Skip to content

T
Third Party Openssl

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

通知 9
Star 18
Fork 1
T
Third Party Openssl

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 09 6月, 2019 1 次提交
    • D
      Revert the DEVRANDOM_WAIT feature · ad416c80
      由 Dr. Matthias St. Pierre 提交于 
      The DEVRANDOM_WAIT feature added a select() call to wait for the
`/dev/random` device to become readable before reading from the
`/dev/urandom` device. It was introduced in commit 38023b87f037
in order to mitigate the fact that the `/dev/urandom` device
does not block until the initial seeding of the kernel CSPRNG
has completed, contrary to the behaviour of the `getrandom()`
system call.

It turned out that this change had negative side effects on
performance which were not acceptable. After some discussion it
was decided to revert this feature and leave it up to the OS
resp. the platform maintainer to ensure a proper initialization
during early boot time.

Fixes #9078

This partially reverts commit 38023b87f037.
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>

(cherry picked from commit a08714e18131b1998faa0113e5bd4024044654ac)

(Merged from https://github.com/openssl/openssl/pull/9118)
      ad416c80
  3. 07 6月, 2019 2 次提交
  5. 06 6月, 2019 1 次提交
  7. 04 6月, 2019 3 次提交
  9. 03 6月, 2019 3 次提交
    • M
      Write a test for receiving a KeyUpdate (update requested) while writing · c8feb103
      由 Matt Caswell 提交于 
      Reviewed-by: NBen Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/8773)

(cherry picked from commit a77b4dba237d001073d2d1c5d55c674a196c949f)
      c8feb103
    • M
      Defer sending a KeyUpdate until after pending writes are complete · 6c2f347c
      由 Matt Caswell 提交于 
      If we receive a KeyUpdate message (update requested) from the peer while
we are in the middle of a write, we should defer sending the responding
KeyUpdate message until after the current write is complete. We do this
by waiting to send the KeyUpdate until the next time we write and there is
no pending write data.

This does imply a subtle change in behaviour. Firstly the responding
KeyUpdate message won't be sent straight away as it is now. Secondly if
the peer sends multiple KeyUpdates without us doing any writing then we
will only send one response, as opposed to previously where we sent a
response for each KeyUpdate received.

Fixes #8677
Reviewed-by: NBen Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/8773)

(cherry picked from commit feb9e31c40c49de6384dd0413685e9b5a15adc99)
      6c2f347c
    • S
      Add the content type attribute to additional CMS signerinfo. · d63d841f
      由 Shane Lontis 提交于 
      Fixes #8923

Found using the openssl cms -resign option.
This uses an alternate path to do the signing which was not adding the required signed attribute
content type. The content type attribute should always exist since it is required is there are
any signed attributes.
As the signing time attribute is always added in code, the content type attribute is also required.
The CMS_si_check_attributes() method adds validity checks for signed and unsigned attributes
e.g. The message digest attribute is a signed attribute that must exist if any signed attributes
exist, it cannot be an unsigned attribute and there must only be one instance containing a single
value.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8944)

(cherry picked from commit 19e512a8244a6f527d0194339a8f9fc45468537a)
      d63d841f
  11. 01 6月, 2019 1 次提交
  13. 31 5月, 2019 3 次提交
  15. 30 5月, 2019 2 次提交
  17. 29 5月, 2019 4 次提交
  19. 28 5月, 2019 9 次提交
  21. 27 5月, 2019 3 次提交
  23. 24 5月, 2019 3 次提交
  25. 23 5月, 2019 2 次提交
  27. 22 5月, 2019 3 次提交