[openssl] OpenSSL_1_1_1-stable update

Richard Levitte levitte at openssl.org
Tue May 5 04:39:58 UTC 2020

The branch OpenSSL_1_1_1-stable has been updated
       via  184b0f14173fd69120767d86227d1db3a4e60ec0 (commit)
      from  352933bd664e6145366b51b50821c8aefd652aa8 (commit)

- Log -----------------------------------------------------------------
commit 184b0f14173fd69120767d86227d1db3a4e60ec0
Author: Kurt Roeckx <kurt at roeckx.be>
Date:   Mon Apr 13 13:01:29 2020 +0200

    Improve SSL_shutdown documentation.
    Reviewed-by: Tomas Mraz <tmraz at fedoraproject.org>
    (Merged from https://github.com/openssl/openssl/pull/11531)
    (cherry picked from commit e307e616f25a6b7b0f343fc1e62a35b2cba888f3)


Summary of changes:
 doc/man3/SSL_shutdown.pod | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/doc/man3/SSL_shutdown.pod b/doc/man3/SSL_shutdown.pod
index 732e5ada04..30cf484619 100644
--- a/doc/man3/SSL_shutdown.pod
+++ b/doc/man3/SSL_shutdown.pod
@@ -116,6 +116,16 @@ state but not actually send the close_notify alert messages,
 see L<SSL_CTX_set_quiet_shutdown(3)>.
 When "quiet shutdown" is enabled, SSL_shutdown() will always succeed
 and return 1.
+Note that this is not standard compliant behaviour.
+It should only be done when the peer has a way to make sure all
+data has been received and doesn't wait for the close_notify alert
+message, otherwise an unexpected EOF will be reported.
+There are implementations that do not send the required close_notify alert.
+If there is a need to communicate with such an implementation, and it's clear
+that all data has been received, do not wait for the peer's close_notify alert.
+Waiting for the close_notify alert when the peer just closes the connection will
+result in an error being generated.
@@ -128,8 +138,10 @@ The following return values can occur:
 The shutdown is not yet finished: the close_notify was sent but the peer
 did not send it back yet.
 Call SSL_read() to do a bidirectional shutdown.
-The output of L<SSL_get_error(3)> may be misleading, as an
-erroneous SSL_ERROR_SYSCALL may be flagged even though no error occurred.
+Unlike most other function, returning 0 does not indicate an error.
+L<SSL_get_error(3)> should not get called, it may misleadingly
+indicate an error even though no error occurred.
 =item Z<>1

More information about the openssl-commits mailing list