Fix spelling in pod files
Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
This commit is contained in:
parent
e0f96357e4
commit
24c2cd3967
12 changed files with 13 additions and 13 deletions
|
@ -25,7 +25,7 @@ B<openssl engine>
|
|||
|
||||
The B<engine> command is used to query the status and capabilities
|
||||
of the specified B<engine>'s.
|
||||
Engines may be speicifed before and after all other command-line flags.
|
||||
Engines may be specified before and after all other command-line flags.
|
||||
Only those specified are queried.
|
||||
|
||||
=head1 OPTIONS
|
||||
|
|
|
@ -53,7 +53,7 @@ ASYNC_WAIT_CTX_get_all_fds() with a NULL B<fd> value will return no file
|
|||
descriptors but will still populate B<*numfds>. Therefore application code is
|
||||
typically expected to call this function twice: once to get the number of fds,
|
||||
and then again when sufficient memory has been allocated. If only one
|
||||
asynchronous engine is being used then noramlly this call will only ever return
|
||||
asynchronous engine is being used then normally this call will only ever return
|
||||
one fd. If multiple asynchronous engines are being used then more could be
|
||||
returned.
|
||||
|
||||
|
|
|
@ -111,7 +111,7 @@ for the B<job>. ASYNC_WAIT_CTXs can have a "wait" file descriptor associated
|
|||
with them. Applications can wait for the file descriptor to be ready for "read"
|
||||
using a system function call such as select or poll (being ready for "read"
|
||||
indicates that the job should be resumed). If no file descriptor is made
|
||||
available then an application will have to priodically "poll" the job by
|
||||
available then an application will have to periodically "poll" the job by
|
||||
attempting to restart it to see if it is ready to continue.
|
||||
|
||||
An example of typical usage might be an async capable engine. User code would
|
||||
|
|
|
@ -72,7 +72,7 @@ with the given one.
|
|||
=head1 RETURN VALUES
|
||||
|
||||
BIO_lookup() returns 1 on success and 0 when an error occurred, and
|
||||
will leave an error indicaton on the OpenSSL error stack in that case.
|
||||
will leave an error indication on the OpenSSL error stack in that case.
|
||||
|
||||
All other functions described here return 0 or B<NULL> when the
|
||||
information they should return isn't available.
|
||||
|
|
|
@ -444,7 +444,7 @@ boolean success or failure.
|
|||
ENGINE_free(e);
|
||||
return 0;
|
||||
}
|
||||
pre_cmds += 2;
|
||||
pre_cmds += 2;
|
||||
}
|
||||
if(!ENGINE_init(e)) {
|
||||
fprintf(stderr, "Failed initialisation\n");
|
||||
|
@ -461,7 +461,7 @@ boolean success or failure.
|
|||
ENGINE_finish(e);
|
||||
return 0;
|
||||
}
|
||||
post_cmds += 2;
|
||||
post_cmds += 2;
|
||||
}
|
||||
ENGINE_set_default(e, ENGINE_METHOD_ALL & ~ENGINE_METHOD_RAND);
|
||||
/* Success */
|
||||
|
|
|
@ -26,7 +26,7 @@ It cannot be set for specific SSL_CTX or SSL objects.
|
|||
In versions of OpenSSL prior to 1.1.0 SSL_COMP_free_compression_methods() freed
|
||||
the internal table of compression methods that were built internally, and
|
||||
possibly augmented by adding SSL_COMP_add_compression_method(). However this is
|
||||
now unncessary from version 1.1.0. No explicit initialisation or
|
||||
now unnecessary from version 1.1.0. No explicit initialisation or
|
||||
de-initialisation is necessary. See L<OPENSSL_init_crypto(3)> and
|
||||
L<OPENSSL_init_ssl(3)>. From OpenSSL 1.1.0 calling this function does nothing.
|
||||
|
||||
|
|
|
@ -465,7 +465,7 @@ Set supported signature algorithms:
|
|||
|
||||
SSL_CONF_cmd(ctx, "SignatureAlgorithms", "ECDSA+SHA256:RSA+SHA256:DSA+SHA256");
|
||||
|
||||
There are various ways to select the supported procotols.
|
||||
There are various ways to select the supported protocols.
|
||||
|
||||
This set the minimum protocol version to TLSv1, and so disables SSLv3.
|
||||
This is the recommended way to disable protocols.
|
||||
|
|
|
@ -17,7 +17,7 @@ and maximum supported protocol version
|
|||
|
||||
=head1 DESCRIPTION
|
||||
|
||||
The functions set the minimum and maximum supported portocol versions
|
||||
The functions set the minimum and maximum supported protocol versions
|
||||
for the B<ctx> or B<ssl>.
|
||||
This works in combination with the options set via
|
||||
L<SSL_CTX_set_options(3)> that also make it possible to disable
|
||||
|
|
|
@ -58,7 +58,7 @@ explained further below. OpenSSL will only every use more than one pipeline if
|
|||
a ciphersuite is negotiated that uses a pipeline capable cipher provided by an
|
||||
engine.
|
||||
|
||||
Pipelining operates slighly differently for reading encrypted data compared to
|
||||
Pipelining operates slightly differently for reading encrypted data compared to
|
||||
writing encrypted data. SSL_CTX_set_split_send_fragment() and
|
||||
SSL_set_split_send_fragment() define how data is split up into pipelines when
|
||||
writing encrypted data. The number of pipelines used will be determined by the
|
||||
|
|
|
@ -72,7 +72,7 @@ B<file> into B<ctx>. The certificates must be in PEM format and must
|
|||
be sorted starting with the subject's certificate (actual client or server
|
||||
certificate), followed by intermediate CA certificates if applicable, and
|
||||
ending at the highest level (root) CA. SSL_use_certificate_chain_file() is
|
||||
similar except it loads the cerificate chain into B<ssl>.
|
||||
similar except it loads the certificate chain into B<ssl>.
|
||||
|
||||
SSL_CTX_use_PrivateKey() adds B<pkey> as private key to B<ctx>.
|
||||
SSL_CTX_use_RSAPrivateKey() adds the private key B<rsa> of type RSA
|
||||
|
|
|
@ -41,7 +41,7 @@ details.
|
|||
|
||||
Despite the names of SSL_get_client_random() and SSL_get_server_random(), they
|
||||
ARE NOT random number generators. Instead, they return the mostly-random values that
|
||||
were already generated and used in the TLS protoccol. Using them
|
||||
were already generated and used in the TLS protocol. Using them
|
||||
in place of RAND_bytes() would be grossly foolish.
|
||||
|
||||
The security of your TLS session depends on keeping the master key secret:
|
||||
|
|
|
@ -65,7 +65,7 @@ The NIDs are OpenSSL equivalents. For example if the peer sent sha256(4) and
|
|||
rsa(1) then B<*rhash> would be 4, B<*rsign> 1, B<*phash> NID_sha256, B<*psig>
|
||||
NID_rsaEncryption and B<*psighash> NID_sha256WithRSAEncryption.
|
||||
|
||||
If a signature algorithm is not recognised the corresponsing NIDs
|
||||
If a signature algorithm is not recognised the corresponding NIDs
|
||||
will be set to B<NID_undef>. This may be because the value is not supported
|
||||
or is not an appropriate combination (for example MD5 and DSA).
|
||||
|
||||
|
|
Loading…
Reference in a new issue