Convert libssl manpages from pod to mdoc(7).

libcrypto has not been started yet.

ok schwarze@ miod@

1 files changed, 0 insertions, 125 deletions

diff --git a/src/lib/libssl/src/doc/ssl/SSL_shutdown.pod b/src/lib/libssl/src/doc/ssl/SSL_shutdown.pod
deleted file mode 100644
index 50f47c20d7..0000000000
--- a/src/lib/libssl/src/doc/ssl/SSL_shutdown.pod
+++ /dev/null
@@ -1,125 +0,0 @@
-=pod
-
-=head1 NAME
-
-SSL_shutdown - shut down a TLS/SSL connection
-
-=head1 SYNOPSIS
-
- #include <openssl/ssl.h>
-
- int SSL_shutdown(SSL *ssl);
-
-=head1 DESCRIPTION
-
-SSL_shutdown() shuts down an active TLS/SSL connection. It sends the
-"close notify" shutdown alert to the peer.
-
-=head1 NOTES
-
-SSL_shutdown() tries to send the "close notify" shutdown alert to the peer.
-Whether the operation succeeds or not, the SSL_SENT_SHUTDOWN flag is set and
-a currently open session is considered closed and good and will be kept in the
-session cache for further reuse.
-
-The shutdown procedure consists of 2 steps: the sending of the "close notify"
-shutdown alert and the reception of the peer's "close notify" shutdown
-alert. According to the TLS standard, it is acceptable for an application
-to only send its shutdown alert and then close the underlying connection
-without waiting for the peer's response (this way resources can be saved,
-as the process can already terminate or serve another connection).
-When the underlying connection shall be used for more communications, the
-complete shutdown procedure (bidirectional "close notify" alerts) must be
-performed, so that the peers stay synchronized.
-
-SSL_shutdown() supports both uni- and bidirectional shutdown by its 2 step
-behaviour.
-
-=over 4
-
-=item When the application is the first party to send the "close notify"
-alert, SSL_shutdown() will only send the alert and then set the
-SSL_SENT_SHUTDOWN flag (so that the session is considered good and will
-be kept in cache). SSL_shutdown() will then return with 0. If a unidirectional
-shutdown is enough (the underlying connection shall be closed anyway), this
-first call to SSL_shutdown() is sufficient. In order to complete the
-bidirectional shutdown handshake, SSL_shutdown() must be called again.
-The second call will make SSL_shutdown() wait for the peer's "close notify"
-shutdown alert. On success, the second call to SSL_shutdown() will return
-with 1.
-
-=item If the peer already sent the "close notify" alert B<and> it was
-already processed implicitly inside another function
-(L<SSL_read(3)|SSL_read(3)>), the SSL_RECEIVED_SHUTDOWN flag is set.
-SSL_shutdown() will send the "close notify" alert, set the SSL_SENT_SHUTDOWN
-flag and will immediately return with 1.
-Whether SSL_RECEIVED_SHUTDOWN is already set can be checked using the
-SSL_get_shutdown() (see also L<SSL_set_shutdown(3)|SSL_set_shutdown(3)> call.
-
-=back
-
-It is therefore recommended, to check the return value of SSL_shutdown()
-and call SSL_shutdown() again, if the bidirectional shutdown is not yet
-complete (return value of the first call is 0). As the shutdown is not
-specially handled in the SSLv2 protocol, SSL_shutdown() will succeed on
-the first call.
-
-The behaviour of SSL_shutdown() additionally depends on the underlying BIO.
-
-If the underlying BIO is B<blocking>, SSL_shutdown() will only return once the
-handshake step has been finished or an error occurred.
-
-If the underlying BIO is B<non-blocking>, SSL_shutdown() will also return
-when the underlying BIO could not satisfy the needs of SSL_shutdown()
-to continue the handshake. In this case a call to SSL_get_error() with the
-return value of SSL_shutdown() will yield B<SSL_ERROR_WANT_READ> or
-B<SSL_ERROR_WANT_WRITE>. The calling process then must repeat the call after
-taking appropriate action to satisfy the needs of SSL_shutdown().
-The action depends on the underlying BIO. When using a non-blocking socket,
-nothing is to be done, but select() can be used to check for the required
-condition. When using a buffering BIO, like a BIO pair, data must be written
-into or retrieved out of the BIO before being able to continue.
-
-SSL_shutdown() can be modified to only set the connection to "shutdown"
-state but not actually send the "close notify" alert messages,
-see L<SSL_CTX_set_quiet_shutdown(3)|SSL_CTX_set_quiet_shutdown(3)>.
-When "quiet shutdown" is enabled, SSL_shutdown() will always succeed
-and return 1.
-
-=head1 RETURN VALUES
-
-The following return values can occur:
-
-=over 4
-
-=item C<0>
-
-The shutdown is not yet finished. Call SSL_shutdown() for a second time,
-if a bidirectional shutdown shall be performed.
-The output of L<SSL_get_error(3)|SSL_get_error(3)> may be misleading, as an
-erroneous SSL_ERROR_SYSCALL may be flagged even though no error occurred.
-
-=item C<1>
-
-The shutdown was successfully completed. The "close notify" alert was sent
-and the peer's "close notify" alert was received.
-
-=item C<-1>
-
-The shutdown was not successful because a fatal error occurred either
-at the protocol level or a connection failure occurred. It can also occur if
-action is need to continue the operation for non-blocking BIOs.
-Call L<SSL_get_error(3)|SSL_get_error(3)> with the return value B<ret>
-to find out the reason.
-
-=back
-
-=head1 SEE ALSO
-
-L<SSL_get_error(3)|SSL_get_error(3)>, L<SSL_connect(3)|SSL_connect(3)>,
-L<SSL_accept(3)|SSL_accept(3)>, L<SSL_set_shutdown(3)|SSL_set_shutdown(3)>,
-L<SSL_CTX_set_quiet_shutdown(3)|SSL_CTX_set_quiet_shutdown(3)>,
-L<SSL_clear(3)|SSL_clear(3)>, L<SSL_free(3)|SSL_free(3)>,
-L<ssl(3)|ssl(3)>, L<bio(3)|bio(3)>
-
-=cut