=head1 DESCRIPTION
-All libcrypto sub-systems that want to create their own methods based
+All libcrypto subsystems that want to create their own methods based
on provider dispatch tables need to do so in exactly the same way.
-ossl_method_construct() does this while leaving it to the sub-systems
+ossl_method_construct() does this while leaving it to the subsystems
to define more precisely how the methods are created, stored, etc.
It's important to keep in mind that a method is identified by three things:
ossl_method_construct() creates a method by asking all available
providers for a dispatch table given an I<operation_id>, and then
-calling the appropriate functions given by the sub-system specific
+calling the appropriate functions given by the subsystem specific
method creator through I<mcm> and the data in I<mcm_data> (which is
passed by ossl_method_construct()).
-This function assumes that the sub-system method creator implements
+This function assumes that the subsystem method creator implements
reference counting and acts accordingly (i.e. it will call the
-sub-system destruct() method to decrement the reference count when
+subsystem destruct() method to decrement the reference count when
appropriate).
=head2 Structures
-A central part of constructing a sub-system specific method is to give
+A central part of constructing a subsystem specific method is to give
ossl_method_construct a set of functions, all in the
B<OSSL_METHOD_CONSTRUCT_METHOD> structure, which holds the following
function pointers:
Look up an already existing method from a store by name.
The store may be given with I<store>.
-NULL is a valid value and means that a sub-system default store
+NULL is a valid value and means that a subsystem default store
must be used.
This default store should be stored in the library context I<libctx>.
in a store.
The store may be given with I<store>.
-NULL is a valid value and means that a sub-system default store
+NULL is a valid value and means that a subsystem default store
must be used.
This default store should be stored in the library context I<libctx>.
=item construct()
-Constructs a sub-system method for the given I<name> and the given
+Constructs a subsystem method for the given I<name> and the given
dispatch table I<fns>.
The associated provider object I<prov> is passed as well, to make
-it possible for the sub-system constructor to keep a reference, which
+it possible for the subsystem constructor to keep a reference, which
is recommended.
If such a reference is kept, the I<provider object> reference counter
must be incremented, using ossl_provider_up_ref().
=item B<-max_msgs> I<number>
Maximum number of CMP (request) messages the CMP HTTP server mock-up
-should handle, which must be non-negative.
+should handle, which must be nonnegative.
The default value is 0, which means that no limit is imposed.
In any case the server terminates on internal errors, but not when it
detects a CMP-level error that it can successfully answer with an error message.
=item B<-nbio_test>
-Tests non-blocking I/O
+Tests nonblocking I/O
=item B<-nbio>
-Turns on non-blocking I/O
+Turns on nonblocking I/O
=item B<-crlf>
=back
-There is one DER encoded protocol data unit defined for transporting a time
-stamp request to the TSA and one for sending the timestamp response
+There is one DER encoded protocol data unit defined for transporting a
+timestamp request to the TSA and one for sending the timestamp response
back to the client. This command has three main functions:
creating a timestamp request based on a data file,
creating a timestamp response based on a request, verifying if a
=head2 Timestamp Response verification
-The B<-verify> command is for verifying if a timestamp response or time
-stamp token is valid and matches a particular timestamp request or
+The B<-verify> command is for verifying if a timestamp response or
+timestamp token is valid and matches a particular timestamp request or
data file. The B<-verify> command does not use the configuration file.
=over 4
=back
The options to specify the format are as follows. Refer to the individual
-manpage to see which options are accepted.
+man page to see which options are accepted.
=over 4
ASYNC_WAIT_CTX_set_callback() sets the callback and the callback argument. The
callback will be called to notify user code when an engine completes a
cryptography operation. It is a requirement that the callback function is small
-and non-blocking as it will be run in the context of a polling mechanism or an
+and nonblocking as it will be run in the context of a polling mechanism or an
interrupt.
ASYNC_WAIT_CTX_get_callback() returns the callback set in the B<ASYNC_WAIT_CTX>
=item BIO_SOCK_NONBLOCK
-Sets the socket to non-blocking mode.
+Sets the socket to nonblocking mode.
=item BIO_SOCK_NODELAY
after connect() failures.
The function returns 1 if the connection was established successfully.
A zero or negative value is returned if the connection could not be established.
-The call BIO_should_retry() should be used for non-blocking connect BIOs
+The call BIO_should_retry() should be used for nonblocking connect BIOs
to determine if the call should be retried.
If a connection has already been established this call has no effect.
=head1 NOTES
A 0 or -1 return is not necessarily an indication of an error. In
-particular when the source/sink is non-blocking or of a certain type
+particular when the source/sink is nonblocking or of a certain type
it may merely be an indication that no data is currently available and that
the application should retry the operation later.
connections. This can be resolved by using BIO_pop() (see above)
and freeing up the accept BIO after the initial connection.
-If the underlying accept socket is non-blocking and BIO_do_accept() is
+If the underlying accept socket is nonblocking and BIO_do_accept() is
called to await an incoming connection it is possible for
BIO_should_io_special() with the reason BIO_RR_ACCEPT. If this happens
then it is an indication that an accept attempt would block: the application
...
As the BIO pair will only buffer the data and never directly access the
-connection, it behaves non-blocking and will return as soon as the write
+connection, it behaves nonblocking and will return as soon as the write
buffer is full or the read buffer is drained. Then the application has to
flush the write buffer and/or fill the read buffer.
BIO_do_connect_retry() connects via the given B<bio>.
It retries BIO_do_connect() as far as needed to reach a definite outcome,
i.e., connection succeeded, timeout has been reached, or an error occurred.
-For non-blocking and potentially even non-socket BIOs it polls
+For nonblocking and potentially even non-socket BIOs it polls
every B<nap_milliseconds> and sleeps in between using BIO_wait().
If B<nap_milliseconds> is < 0 then a default value of 100 ms is used.
If the B<timeout> parameter is > 0 this indicates the maximum number of seconds
BN_mod() corresponds to BN_div() with I<dv> set to B<NULL>.
-BN_nnmod() reduces I<a> modulo I<m> and places the non-negative
+BN_nnmod() reduces I<a> modulo I<m> and places the nonnegative
remainder in I<r>.
-BN_mod_add() adds I<a> to I<b> modulo I<m> and places the non-negative
+BN_mod_add() adds I<a> to I<b> modulo I<m> and places the nonnegative
result in I<r>.
BN_mod_sub() subtracts I<b> from I<a> modulo I<m> and places the
-non-negative result in I<r>.
+nonnegative result in I<r>.
-BN_mod_mul() multiplies I<a> by I<b> and finds the non-negative
+BN_mod_mul() multiplies I<a> by I<b> and finds the nonnegative
remainder respective to modulus I<m> (C<r=(a*b) mod m>). I<r> may be
the same B<BIGNUM> as I<a> or I<b>. For more efficient algorithms for
repeated computations using the same modulus, see
BN_is_prime_fasttest_ex() and BN_is_prime_ex() respectively, but with the old
style call back.
-B<ctx> is a pre-allocated B<BN_CTX> (to save the overhead of allocating and
+B<ctx> is a preallocated B<BN_CTX> (to save the overhead of allocating and
freeing the structure in a loop), or B<NULL>.
If the trial division is done, and no divisors are found and B<cb>
BN_from_montgomery() performs the Montgomery reduction I<r> = I<a>*R^-1.
BN_to_montgomery() computes Mont(I<a>,R^2), i.e. I<a>*R.
-Note that I<a> must be non-negative and smaller than the modulus.
+Note that I<a> must be nonnegative and smaller than the modulus.
For all functions, I<ctx> is a previously allocated B<BN_CTX> used for
temporary variables.
shorter than B<n> bits.
BN_lshift() shifts B<a> left by B<n> bits and places the result in
-B<r> (C<r=a*2^n>). Note that B<n> must be non-negative. BN_lshift1() shifts
+B<r> (C<r=a*2^n>). Note that B<n> must be nonnegative. BN_lshift1() shifts
B<a> left by one and places the result in B<r> (C<r=2*a>).
BN_rshift() shifts B<a> right by B<n> bits and places the result in
-B<r> (C<r=a/2^n>). Note that B<n> must be non-negative. BN_rshift1() shifts
+B<r> (C<r=a/2^n>). Note that B<n> must be nonnegative. BN_rshift1() shifts
B<a> right by one and places the result in B<r> (C<r=a/2>).
For the shift functions, B<r> and B<a> may be the same variable.
filled in.
A return value of 0 indicates a non-fatal error. This could (for
-example) be because of non-blocking IO, or some invalid message having been
+example) be because of nonblocking IO, or some invalid message having been
received from a peer. Errors may be placed on the OpenSSL error queue with
further information if appropriate. Typically user code is expected to retry the
call to DTLSv1_listen() in the event of a non-fatal error.
=head1 NOTES
The library number is unique to each unit that records errors.
-OpenSSL has a number of pre-allocated ones for its own uses, but
+OpenSSL has a number of preallocated ones for its own uses, but
others may allocate their own library number dynamically with
L<ERR_get_next_error_library(3)>.
The function EVP_PKEY_CTX_get_keygen_info() returns parameters associated
with the generation operation. If I<idx> is -1 the total number of
parameters available is returned. Any non negative value returns the value of
-that parameter. EVP_PKEY_CTX_gen_keygen_info() with a non-negative value for
+that parameter. EVP_PKEY_CTX_gen_keygen_info() with a nonnegative value for
I<idx> should only be called within the generation callback.
If the callback returns 0 then the key generation operation is aborted and an
automatically deinitialise as required.
However, there may be situations when explicit initialisation is desirable or
-needed, for example when some non-default initialisation is required. The
+needed, for example when some nondefault initialisation is required. The
function OPENSSL_init_crypto() can be used for this purpose for
libcrypto (see also L<OPENSSL_init_ssl(3)> for the libssl
equivalent).
Numerous internal OpenSSL functions call OPENSSL_init_crypto().
-Therefore, in order to perform non-default initialisation,
+Therefore, in order to perform nondefault initialisation,
OPENSSL_init_crypto() MUST be called by application code prior to
any other OpenSSL function calls.
Note that in OpenSSL 1.1.1 this was the default for libssl but not for
libcrypto (see L<OPENSSL_init_ssl(3)> for further details about libssl
initialisation).
-In OpenSSL 1.1.0 this was a non-default option for both libssl and libcrypto.
+In OpenSSL 1.1.0 this was a nondefault option for both libssl and libcrypto.
See the description of OPENSSL_INIT_new(), below.
=item OPENSSL_INIT_NO_LOAD_CONFIG
non-null B<OPENSSL_INIT_SETTINGS> object.
The object can be allocated via B<OPENSSL_INIT_new()>.
The B<OPENSSL_INIT_set_config_filename()> function can be used to specify a
-non-default filename, which is copied and need not refer to persistent storage.
+nondefault filename, which is copied and need not refer to persistent storage.
Similarly, OPENSSL_INIT_set_config_appname() can be used to specify a
-non-default application name.
-Finally, OPENSSL_INIT_set_file_flags can be used to specify non-default flags.
+nondefault application name.
+Finally, OPENSSL_INIT_set_file_flags can be used to specify nondefault flags.
If the B<CONF_MFLAGS_IGNORE_RETURN_CODES> flag is not included, any errors in
the configuration file will cause an error return from B<OPENSSL_init_crypto>
or indirectly L<OPENSSL_init_ssl(3)>.
automatically deinitialise as required.
However, there may be situations when explicit initialisation is desirable or
-needed, for example when some non-default initialisation is required. The
+needed, for example when some nondefault initialisation is required. The
function OPENSSL_init_ssl() can be used for this purpose. Calling
this function will explicitly initialise BOTH libcrypto and libssl. To
explicitly initialise ONLY libcrypto see the
L<OPENSSL_init_crypto(3)> function.
Numerous internal OpenSSL functions call OPENSSL_init_ssl().
-Therefore, in order to perform non-default initialisation,
+Therefore, in order to perform nondefault initialisation,
OPENSSL_init_ssl() MUST be called by application code prior to
any other OpenSSL function calls.
response message IP/CP/KUP.
OSSL_CMP_CTX_get1_extraCertsIn() returns a pointer to a duplicate of the stack
-of X.509 certificates received in the last received non-empty extraCerts field.
+of X.509 certificates received in the last received nonempty extraCerts field.
Returns an empty stack if no extraCerts have been received in the current
transaction.
=head1 RETURN VALUES
OSSL_CRMF_MSG_get_certReqId() returns the certificate request ID as a
-non-negative integer or -1 on error.
+nonnegative integer or -1 on error.
All other functions return a pointer with the intended result or NULL on error.
=head1 DESCRIPTION
RAND_load_file() reads a number of bytes from file B<filename> and
-adds them to the PRNG. If B<max_bytes> is non-negative,
+adds them to the PRNG. If B<max_bytes> is nonnegative,
up to B<max_bytes> are read;
if B<max_bytes> is -1, the complete file is read.
Do not load the same file multiple times unless its contents have
must be used to protect the RSA operation from that attack.
RSA_blinding_on() turns blinding on for key B<rsa> and generates a
-random blinding factor. B<ctx> is B<NULL> or a pre-allocated and
+random blinding factor. B<ctx> is B<NULL> or a preallocated and
initialized B<BN_CTX>.
RSA_blinding_off() turns blinding off and frees the memory used for
matched the peer certificate chain.
The return value indicates the match depth or failure to match just as with
SSL_get0_dane_authority().
-When the return value is non-negative, the storage pointed to by the B<usage>,
+When the return value is nonnegative, the storage pointed to by the B<usage>,
B<selector>, B<mtype> and B<data> parameters is updated to the corresponding
TLSA record fields.
The B<data> field is in binary wire form, and is therefore not NUL-terminated,
The functions SSL_get0_dane_authority() and SSL_get0_dane_tlsa() return a
negative value when DANE authentication failed or was not enabled, a
-non-negative value indicates the chain depth at which the TLSA record matched a
+nonnegative value indicates the chain depth at which the TLSA record matched a
chain certificate, or the depth of the top-most certificate, when the TLSA
record is a full public key that is its signer.
=head1 NOTES
The protocol-lists must be in wire-format, which is defined as a vector of
-non-empty, 8-bit length-prefixed, byte strings. The length-prefix byte is not
+nonempty, 8-bit length-prefixed, byte strings. The length-prefix byte is not
included in the length. Each string is limited to 255 bytes. A byte-string
length of 0 is invalid. A truncated byte-string is invalid. The length of the
vector is not in the vector itself, but in a separate variable.
Callback has been called to indicate exit of a handshake function. This will
happen after the end of a handshake, but may happen at other times too such as
-on error or when IO might otherwise block and non-blocking is being used.
+on error or when IO might otherwise block and nonblocking is being used.
=item SSL_CB_READ
chain is set.
The default value for the maximum certificate chain size is 100kB (30kB
-on the 16bit DOS platform). This should be sufficient for usual certificate
+on the 16-bit DOS platform). This should be sufficient for usual certificate
chains (OpenSSL's default maximum chain length is 10, see
L<SSL_CTX_set_verify(3)>, and certificates
without special extensions have a typical size of 1-2kB).
Make it possible to retry SSL_write_ex() or SSL_write() with changed buffer
location (the buffer contents must stay the same). This is not the default to
-avoid the misconception that non-blocking SSL_write() behaves like
-non-blocking write().
+avoid the misconception that nonblocking SSL_write() behaves like
+nonblocking write().
=item SSL_MODE_AUTO_RETRY
B<SSL_MODE_AUTO_RETRY> causes it to try to process the next record instead of
returning.
-In a non-blocking environment applications must be prepared to handle
+In a nonblocking environment applications must be prepared to handle
incomplete read/write operations.
-Setting B<SSL_MODE_AUTO_RETRY> for a non-blocking B<BIO> will process
+Setting B<SSL_MODE_AUTO_RETRY> for a nonblocking B<BIO> will process
non-application data records until either no more data is available or
an application data record has been processed.
next portion of data. When enabling SSL_OP_CLEANSE_PLAINTEXT
deciphered application data is cleansed by calling OPENSSL_cleanse(3)
after passing data to the application. Data is also cleansed when
-releasing the connection (eg. L<SSL_free(3)>).
+releasing the connection (e.g. L<SSL_free(3)>).
Since OpenSSL only cleanses internal buffers, the application is still
responsible for cleansing all other buffers. Most notably, this
=head1 DESCRIPTION
SSL_CTX_set_read_ahead() and SSL_set_read_ahead() set whether we should read as
-many input bytes as possible (for non-blocking reads) or not. For example if
+many input bytes as possible (for nonblocking reads) or not. For example if
B<x> bytes are currently required by OpenSSL, but B<y> bytes are available from
the underlying BIO (where B<y> > B<x>), then OpenSSL will read all B<y> bytes
into its buffer (providing that the buffer is large enough) if reading ahead is
=head1 DESCRIPTION
These functions provide access to SRP (Secure Remote Password) parameters,
-an alternate authentication mechanism for TLS. SRP allows the use of user names
+an alternate authentication mechanism for TLS. SRP allows the use of usernames
and passwords over unencrypted channels without revealing the password to an
eavesdropper. SRP also supplies a shared secret at the end of the authentication
sequence that can be used to generate encryption keys.
If the underlying BIO is B<blocking>, SSL_accept() will only return once the
handshake has been finished or an error occurred.
-If the underlying BIO is B<non-blocking>, SSL_accept() will also return
+If the underlying BIO is B<nonblocking>, SSL_accept() will also return
when the underlying BIO could not satisfy the needs of SSL_accept()
to continue the handshake, indicating the problem by the return value -1.
In this case a call to SSL_get_error() with the
return value of SSL_accept() 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_accept().
-The action depends on the underlying BIO. When using a non-blocking socket,
+The action depends on the underlying BIO. When using a nonblocking 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.
The TLS/SSL handshake was not successful because a fatal error occurred either
at the protocol level or a connection failure occurred. The shutdown was
not clean. It can also occur if action is needed to continue the operation
-for non-blocking BIOs. Call SSL_get_error() with the return value B<ret>
+for nonblocking BIOs. Call SSL_get_error() with the return value B<ret>
to find out the reason.
=back
After freeing the buffers, the buffers are automatically reallocated upon a
new read or write. The SSL_alloc_buffers() does not need to be called, but
-can be used to make sure the buffers are pre-allocated. This can be used to
+can be used to make sure the buffers are preallocated. This can be used to
avoid allocation during data processing or with CRYPTO_set_mem_functions()
to control where and how buffers are allocated.
If the underlying BIO is B<blocking>, SSL_connect() will only return once the
handshake has been finished or an error occurred.
-If the underlying BIO is B<non-blocking>, SSL_connect() will also return
+If the underlying BIO is B<nonblocking>, SSL_connect() will also return
when the underlying BIO could not satisfy the needs of SSL_connect()
to continue the handshake, indicating the problem by the return value -1.
In this case a call to SSL_get_error() with the
return value of SSL_connect() 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_connect().
-The action depends on the underlying BIO. When using a non-blocking socket,
+The action depends on the underlying BIO. When using a nonblocking 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.
The TLS/SSL handshake was not successful, because a fatal error occurred either
at the protocol level or a connection failure occurred. The shutdown was
not clean. It can also occur if action is needed to continue the operation
-for non-blocking BIOs. Call SSL_get_error() with the return value B<ret>
+for nonblocking BIOs. Call SSL_get_error() with the return value B<ret>
to find out the reason.
=back
If the underlying BIO is B<blocking>, SSL_do_handshake() will only return
once the handshake has been finished or an error occurred.
-If the underlying BIO is B<non-blocking>, SSL_do_handshake() will also return
+If the underlying BIO is B<nonblocking>, SSL_do_handshake() will also return
when the underlying BIO could not satisfy the needs of SSL_do_handshake()
to continue the handshake. In this case a call to SSL_get_error() with the
return value of SSL_do_handshake() 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_do_handshake().
-The action depends on the underlying BIO. When using a non-blocking socket,
+The action depends on the underlying BIO. When using a nonblocking 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.
The TLS/SSL handshake was not successful because a fatal error occurred either
at the protocol level or a connection failure occurred. The shutdown was
not clean. It can also occur if action is needed to continue the operation
-for non-blocking BIOs. Call SSL_get_error() with the return value B<ret>
+for nonblocking BIOs. Call SSL_get_error() with the return value B<ret>
to find out the reason.
=back
The operation did not complete and can be retried later.
B<SSL_ERROR_WANT_READ> is returned when the last operation was a read
-operation from a non-blocking B<BIO>.
+operation from a nonblocking B<BIO>.
It means that not enough data was available at this time to complete the
operation.
If at a later time the underlying B<BIO> has data available for reading the same
See L<SSL_read(3)> for more information.
B<SSL_ERROR_WANT_WRITE> is returned when the last operation was a write
-to a non-blocking B<BIO> and it was unable to sent all data to the B<BIO>.
+to a nonblocking B<BIO> and it was unable to sent all data to the B<BIO>.
When the B<BIO> is writable again, the same function can be called again.
Note that the retry may again lead to an B<SSL_ERROR_WANT_READ> or
Note that if B<SSL_MODE_AUTO_RETRY> is set and only non-application data is
available the call will hang.
-If the underlying BIO is B<non-blocking>, a read function will also return when
+If the underlying BIO is B<nonblocking>, a read function will also return when
the underlying BIO could not satisfy the needs of the function to continue the
operation.
In this case a call to L<SSL_get_error(3)> with the
The calling process then must repeat the call after taking appropriate action
to satisfy the needs of the read function.
The action depends on the underlying BIO.
-When using a non-blocking socket, nothing is to be done, but select() can be
+When using a nonblocking 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_set1_host() sets the expected DNS hostname to B<name> clearing
any previously specified hostname. If B<name> is NULL
or the empty string, the list of hostnames is cleared and name
-checks are not performed on the peer certificate. When a non-empty
+checks are not performed on the peer certificate. When a nonempty
B<name> is specified, certificate verification automatically checks
the peer hostname via L<X509_check_host(3)> with B<flags> as specified
via SSL_set_hostflags(). Clients that enable DANE TLSA authentication
=item 7.
The callback function should then run. Note: it is a requirement that the
-callback function is small and non-blocking as it will be run in the context of
+callback function is small and nonblocking as it will be run in the context of
a polling mechanism or an interrupt.
=item 8.
SSL_set0_rbio() connects the BIO B<rbio> for the read operations of the B<ssl>
object. The SSL engine inherits the behaviour of B<rbio>. If the BIO is
-non-blocking then the B<ssl> object will also have non-blocking behaviour. This
+nonblocking then the B<ssl> object will also have nonblocking behaviour. This
function transfers ownership of B<rbio> to B<ssl>. It will be automatically
freed using L<BIO_free_all(3)> when the B<ssl> is freed. On calling this
function, any existing B<rbio> that was previously set will also be freed via a
When performing the operation, a B<socket BIO> is automatically created to
interface between the B<ssl> and B<fd>. The BIO and hence the SSL engine
-inherit the behaviour of B<fd>. If B<fd> is non-blocking, the B<ssl> will
-also have non-blocking behaviour.
+inherit the behaviour of B<fd>. If B<fd> is nonblocking, the B<ssl> will
+also have nonblocking behaviour.
If there was already a BIO connected to B<ssl>, BIO_free() will be called
(for both the reading and writing side, if different).
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
+If the underlying BIO is B<nonblocking>, 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,
+The action depends on the underlying BIO. When using a nonblocking 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.
The shutdown was not successful.
Call L<SSL_get_error(3)> with the return value B<ret> to find out the reason.
-It can occur if an action is needed to continue the operation for non-blocking
+It can occur if an action is needed to continue the operation for nonblocking
BIOs.
It can also occur when not all data was read using SSL_read().
or when a connection has been established. It however can be of significant
interest during the handshake.
-When using non-blocking sockets, the function call performing the handshake
+When using nonblocking sockets, the function call performing the handshake
may return with SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE condition,
so that SSL_state_string[_long]() may be called.
-For both blocking or non-blocking sockets, the details state information
+For both blocking or nonblocking sockets, the details state information
can be used within the info_callback function set with the
SSL_set_info_callback() call.
Unlike L<SSL_get_error(3)>, which also evaluates the
error queue, the results are obtained by examining an internal state flag
only. The information must therefore only be used for normal operation under
-non-blocking I/O. Error conditions are not handled and must be treated
+nonblocking I/O. Error conditions are not handled and must be treated
using L<SSL_get_error(3)>.
The result returned by SSL_want() should always be consistent with
If the underlying BIO is B<blocking>, the write functions will only return, once
the write operation has been finished or an error occurred.
-If the underlying BIO is B<non-blocking> the write functions will also return
+If the underlying BIO is B<nonblocking> the write functions will also return
when the underlying BIO could not satisfy the needs of the function to continue
the operation. In this case a call to L<SSL_get_error(3)> with the
return value of the write function will yield B<SSL_ERROR_WANT_READ>
call to a write function can also cause read operations! The calling process
then must repeat the call after taking appropriate action to satisfy the needs
of the write function. 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
+nonblocking 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.
checks.
X509_STORE_CTX_get_error_depth() returns the B<depth> of the error. This is a
-non-negative integer representing where in the certificate chain the error
+nonnegative integer representing where in the certificate chain the error
occurred. If it is zero it occurred in the end entity certificate, one if
it is the certificate which signed the end entity certificate and so on.
X509_STORE_CTX_get_error() returns B<X509_V_OK> or an error code.
-X509_STORE_CTX_get_error_depth() returns a non-negative error depth.
+X509_STORE_CTX_get_error_depth() returns a nonnegative error depth.
X509_STORE_CTX_get_current_cert() returns the certificate which caused the
error or B<NULL> if no certificate is relevant to the error.
other means.
X509_check_host() checks if the certificate Subject Alternative
-Name (SAN) or Subject CommonName (CN) matches the specified host
-name, which must be encoded in the preferred name syntax described
+Name (SAN) or Subject CommonName (CN) matches the specified hostname,
+which must be encoded in the preferred name syntax described
in section 3.5 of RFC 1034. By default, wildcards are supported
and they match only in the left-most label; but they may match
part of that label with an explicit prefix or suffix. For example,
This is a multi-valued extension which indicates whether a certificate is
a CA certificate. The first value is B<CA> followed by B<TRUE> or
B<FALSE>. If B<CA> is B<TRUE> then an optional B<pathlen> name followed by a
-non-negative value can be included.
+nonnegative value can be included.
For example:
# This is from http://man7.org/linux/man-pages/man7/man-pages.7.html
my %preferred_words = (
+ '16bit' => '16-bit',
'a.k.a.' => 'aka',
'bitmask' => 'bit mask',
'builtin' => 'built-in',
'i-node' => 'inode',
'lower case' => 'lowercase',
'lower-case' => 'lowercase',
+ 'manpage' => 'man page',
+ 'non-blocking' => 'nonblocking',
+ 'non-default' => 'nondefault',
+ 'non-empty' => 'nonempty',
+ 'non-negative' => 'nonnegative',
'non-zero' => 'nonzero',
'path name' => 'pathname',
+ 'pre-allocated' => 'preallocated',
'pseudo-terminal' => 'pseudoterminal',
- 'reserved port' => 'privileged port',
- 'system port' => 'privileged port',
- 'realtime' => 'real-time',
'real time' => 'real-time',
+ 'realtime' => 'real-time',
+ 'reserved port' => 'privileged port',
'runtime' => 'run time',
'saved group ID'=> 'saved set-group-ID',
'saved set-GID' => 'saved set-group-ID',
- 'saved user ID' => 'saved set-user-ID',
'saved set-UID' => 'saved set-user-ID',
+ 'saved user ID' => 'saved set-user-ID',
'set-GID' => 'set-group-ID',
- 'setgid' => 'set-group-ID',
'set-UID' => 'set-user-ID',
+ 'setgid' => 'set-group-ID',
'setuid' => 'set-user-ID',
- 'super user' => 'superuser',
- 'super-user' => 'superuser',
+ 'sub-system' => 'subsystem',
'super block' => 'superblock',
'super-block' => 'superblock',
+ 'super user' => 'superuser',
+ 'super-user' => 'superuser',
+ 'system port' => 'privileged port',
'time stamp' => 'timestamp',
'time zone' => 'timezone',
'upper case' => 'uppercase',
'upper-case' => 'uppercase',
'useable' => 'usable',
- 'userspace' => 'user space',
'user name' => 'username',
+ 'userspace' => 'user space',
'zeroes' => 'zeros'
);
projects / openssl.git / commitdiff