Skip to content

T
Third Party Openssl

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

通知 10
Star 18
Fork 1
T
Third Party Openssl
切换分支/标签
  1. 31 3月, 2020 1 次提交
  3. 25 3月, 2020 1 次提交
  5. 23 3月, 2020 1 次提交
  7. 17 3月, 2020 1 次提交
  9. 08 3月, 2020 1 次提交
  11. 27 2月, 2020 1 次提交
  13. 12 2月, 2020 1 次提交
  15. 25 1月, 2020 1 次提交
    • K
      Replace apps/server.pem with certificate with a sha256 signature. · 2dbcdb69
      由 Kurt Roeckx 提交于 
      It replaces apps/server.pem that used a sha1 signature with a copy of
test/certs/servercert.pem that is uses sha256.

This caused the dtlstest to start failing. It's testing connection
sbetween a dtls client and server. In particular it was checking that if
we drop a record that the handshake recovers and still completes
successfully. The test iterates a number of times. The first time
through it drops the first record. The second time it drops the second
one, and so on. In order to do this it has a hard-coded value for the
expected number of records it should see in a handshake. That's ok
because we completely control both sides of the handshake and know what
records we expect to see. Small changes in message size would be
tolerated because that is unlikely to have an impact on the number of
records. Larger changes in message size however could increase or
decrease the number of records and hence cause the test to fail.

This particular test uses a mem bio which doesn't have all the CTRLs
that the dgram BIO has. When we are using a dgram BIO we query that BIO
to determine the MTU size. The smaller the MTU the more fragmented
handshakes become. Since the mem BIO doesn't report an MTU we use a
rather small default value and get quite a lot of records in our
handshake. This has the tendency to increase the likelihood of the
number of records changing in the test if the message size changes.

It so happens that the new server certificate is smaller than the old
one. AFAICT this is probably because the DNs for the Subject and Issuer
are significantly shorter than previously. The result is that the number
of records used to transmit the Certificate message is one less than it
was before. This actually has a knock on impact for subsequent messages
and how we fragment them resulting in one less ServerKeyExchange record
too (the actual size of the ServerKeyExchange message hasn't changed,
but where in that message it gets fragmented has). In total the number
of records used in the handshake has decreased by 2 with the new
server.pem file.
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
GH: #10784
(cherry picked from commit 5fd72d96a592c3c4ef28ff11c6ef334a856b0cd1)
      2dbcdb69
  17. 08 1月, 2020 1 次提交
  19. 05 1月, 2020 1 次提交
  21. 26 12月, 2019 1 次提交
  23. 19 12月, 2019 1 次提交
  25. 18 12月, 2019 1 次提交
  27. 16 12月, 2019 1 次提交
  29. 13 12月, 2019 1 次提交
  31. 12 12月, 2019 1 次提交
  33. 29 11月, 2019 1 次提交
  35. 22 11月, 2019 1 次提交
  37. 30 10月, 2019 1 次提交
  39. 28 10月, 2019 2 次提交
  41. 23 10月, 2019 1 次提交
  43. 15 10月, 2019 1 次提交
  45. 12 10月, 2019 1 次提交
  47. 30 9月, 2019 2 次提交
  49. 28 9月, 2019 1 次提交
  51. 17 9月, 2019 1 次提交
  53. 10 9月, 2019 1 次提交
  55. 04 9月, 2019 1 次提交
  57. 22 8月, 2019 1 次提交
    • R
      openssl dgst, openssl enc: check for end of input · 8be96f23
      由 Richard Levitte 提交于 
      The input reading loop in 'openssl dgst' and 'openssl enc' doesn't
check for end of input, and because of the way BIO works, it thereby
won't detect that the end is reached before the read is an error.
With the FILE BIO, an error occurs when trying to read past EOF, which
is fairly much ok, except when the command is used interactively, at
least on Unix.  The result in that case is that the user has to press
Ctrl-D twice for the command to terminate.

The issue is further complicated because both these commands use
filter BIOs on top of the FILE BIO, so a naïve attempt to check
BIO_eof() doesn't quite solve it, since that only checks the state of
the source/sink BIO, and the filter BIO may have some buffered data
that still needs to be read.  Fortunately, there's BIO_pending() that
checks exactly that, if any filter BIO has pending data that needs to
be processed.

We end up having to check both BIO_pending() and BIO_eof().

Thanks to Zsigmond Lőrinczy for the initial effort and inspiration.

Fixes #9355
Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/9668)

(cherry picked from commit 8ed7bbb411d2a9e0edef928958ad955e0be3d6dd)
      8be96f23
  59. 01 8月, 2019 1 次提交
  61. 24 7月, 2019 1 次提交
  63. 16 7月, 2019 1 次提交
  65. 08 7月, 2019 1 次提交
  67. 01 7月, 2019 1 次提交
  69. 11 6月, 2019 1 次提交
  71. 28 5月, 2019 1 次提交
  73. 23 5月, 2019 1 次提交
  75. 03 5月, 2019 1 次提交