[openssl] OpenSSL_1_1_1-stable update
matthias.st.pierre at ncp-e.com
matthias.st.pierre at ncp-e.com
Fri Jul 24 19:07:35 UTC 2020
The branch OpenSSL_1_1_1-stable has been updated
via 6328d3673fabc336e3064368d855c2d1153ef54c (commit)
from 7a989af7386e97add7c759fda688c5d2e79e812e (commit)
- Log -----------------------------------------------------------------
commit 6328d3673fabc336e3064368d855c2d1153ef54c
Author: Gustaf Neumann <neumann at wu-wien.ac.at>
Date: Sat Jul 4 21:58:30 2020 +0200
Fix typos and repeated words
Reviewed-by: Paul Dale <paul.dale at oracle.com>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre at ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/12370)
-----------------------------------------------------------------------
Summary of changes:
NOTES.ANDROID | 4 +-
NOTES.PERL | 2 +-
NOTES.VMS | 2 +-
NOTES.WIN | 10 +--
doc/man1/CA.pl.pod | 2 +-
doc/man1/ca.pod | 2 +-
doc/man1/enc.pod | 2 +-
doc/man1/ocsp.pod | 2 +-
doc/man1/pkcs12.pod | 2 +-
doc/man1/pkcs8.pod | 2 +-
doc/man1/pkeyutl.pod | 2 +-
doc/man1/s_client.pod | 8 +-
doc/man1/s_server.pod | 4 +-
doc/man1/s_time.pod | 4 +-
doc/man1/sess_id.pod | 2 +-
doc/man1/ts.pod | 92 +++++++++++-----------
doc/man1/tsget.pod | 28 +++----
doc/man1/verify.pod | 2 +-
doc/man1/x509.pod | 2 +-
doc/man3/ASN1_INTEGER_get_int64.pod | 2 +-
doc/man3/ASN1_STRING_length.pod | 2 +-
doc/man3/ASN1_TIME_set.pod | 4 +-
doc/man3/ASN1_TYPE_get.pod | 10 +--
doc/man3/ASYNC_WAIT_CTX_new.pod | 4 +-
doc/man3/ASYNC_start_job.pod | 2 +-
doc/man3/BF_encrypt.pod | 2 +-
doc/man3/BIO_ADDR.pod | 2 +-
doc/man3/BIO_ADDRINFO.pod | 2 +-
doc/man3/BIO_connect.pod | 2 +-
doc/man3/BIO_ctrl.pod | 2 +-
doc/man3/BIO_get_data.pod | 2 +-
doc/man3/BIO_parse_hostserv.pod | 4 +-
doc/man3/BIO_read.pod | 2 +-
doc/man3/BIO_s_accept.pod | 2 +-
doc/man3/BIO_s_bio.pod | 4 +-
doc/man3/BIO_s_connect.pod | 2 +-
doc/man3/BIO_s_file.pod | 2 +-
doc/man3/BIO_set_callback.pod | 2 +-
doc/man3/BN_add.pod | 8 +-
doc/man3/BN_bn2bin.pod | 2 +-
doc/man3/BN_generate_prime.pod | 2 +-
doc/man3/BN_mod_mul_montgomery.pod | 2 +-
doc/man3/BN_set_bit.pod | 4 +-
doc/man3/CMS_verify.pod | 2 +-
doc/man3/CRYPTO_THREAD_run_once.pod | 2 +-
doc/man3/CRYPTO_memcmp.pod | 4 +-
doc/man3/DES_random_key.pod | 6 +-
doc/man3/DH_get0_pqg.pod | 2 +-
doc/man3/DH_set_method.pod | 4 +-
doc/man3/DSA_set_method.pod | 4 +-
doc/man3/DTLSv1_listen.pod | 4 +-
doc/man3/ECDSA_SIG_new.pod | 4 +-
doc/man3/EC_GROUP_new.pod | 2 +-
doc/man3/EC_POINT_new.pod | 2 +-
doc/man3/ENGINE_add.pod | 20 ++---
doc/man3/ERR_get_error.pod | 2 +-
doc/man3/ERR_print_errors.pod | 2 +-
doc/man3/ERR_put_error.pod | 4 +-
doc/man3/EVP_DigestInit.pod | 4 +-
doc/man3/EVP_DigestSignInit.pod | 4 +-
doc/man3/EVP_DigestVerifyInit.pod | 4 +-
doc/man3/EVP_EncodeInit.pod | 2 +-
doc/man3/EVP_EncryptInit.pod | 10 +--
doc/man3/EVP_OpenInit.pod | 2 +-
doc/man3/EVP_PKEY_CTX_ctrl.pod | 2 +-
doc/man3/EVP_PKEY_CTX_new.pod | 2 +-
doc/man3/EVP_PKEY_keygen.pod | 2 +-
doc/man3/EVP_SealInit.pod | 2 +-
doc/man3/EVP_SignInit.pod | 4 +-
doc/man3/EVP_VerifyInit.pod | 4 +-
doc/man3/HMAC.pod | 2 +-
doc/man3/OCSP_cert_to_id.pod | 2 +-
doc/man3/OCSP_request_add1_nonce.pod | 2 +-
doc/man3/OCSP_resp_find_status.pod | 4 +-
doc/man3/OCSP_sendreq_new.pod | 4 +-
doc/man3/OPENSSL_LH_COMPFUNC.pod | 4 +-
doc/man3/OPENSSL_config.pod | 2 +-
doc/man3/OPENSSL_ia32cap.pod | 2 +-
doc/man3/OPENSSL_init_crypto.pod | 10 +--
doc/man3/OPENSSL_init_ssl.pod | 4 +-
doc/man3/PEM_read_bio_PrivateKey.pod | 4 +-
doc/man3/PKCS7_verify.pod | 2 +-
doc/man3/RAND_DRBG_new.pod | 2 +-
doc/man3/RAND_DRBG_set_callbacks.pod | 2 +-
doc/man3/RAND_add.pod | 2 +-
doc/man3/RAND_load_file.pod | 6 +-
doc/man3/RSA_blinding_on.pod | 2 +-
doc/man3/RSA_private_encrypt.pod | 4 +-
doc/man3/RSA_set_method.pod | 2 +-
doc/man3/SSL_CONF_cmd.pod | 8 +-
doc/man3/SSL_CTX_dane_enable.pod | 6 +-
doc/man3/SSL_CTX_set_alpn_select_cb.pod | 2 +-
doc/man3/SSL_CTX_set_generate_session_id.pod | 4 +-
doc/man3/SSL_CTX_set_info_callback.pod | 4 +-
doc/man3/SSL_CTX_set_max_cert_list.pod | 2 +-
doc/man3/SSL_CTX_set_mode.pod | 20 ++---
doc/man3/SSL_CTX_set_options.pod | 18 ++---
doc/man3/SSL_CTX_set_psk_client_callback.pod | 2 +-
doc/man3/SSL_CTX_set_read_ahead.pod | 2 +-
doc/man3/SSL_CTX_set_session_cache_mode.pod | 2 +-
doc/man3/SSL_CTX_set_session_id_context.pod | 2 +-
doc/man3/SSL_CTX_set_session_ticket_cb.pod | 2 +-
doc/man3/SSL_CTX_set_split_send_fragment.pod | 2 +-
.../SSL_CTX_set_tlsext_servername_callback.pod | 2 +-
doc/man3/SSL_CTX_use_psk_identity_hint.pod | 2 +-
doc/man3/SSL_accept.pod | 6 +-
doc/man3/SSL_alloc_buffers.pod | 2 +-
doc/man3/SSL_connect.pod | 6 +-
doc/man3/SSL_do_handshake.pod | 6 +-
doc/man3/SSL_get_all_async_fds.pod | 4 +-
doc/man3/SSL_get_error.pod | 8 +-
doc/man3/SSL_pending.pod | 2 +-
doc/man3/SSL_read.pod | 6 +-
doc/man3/SSL_read_early_data.pod | 8 +-
doc/man3/SSL_set1_host.pod | 4 +-
doc/man3/SSL_set_bio.pod | 4 +-
doc/man3/SSL_set_fd.pod | 4 +-
doc/man3/SSL_set_shutdown.pod | 2 +-
doc/man3/SSL_shutdown.pod | 6 +-
doc/man3/SSL_state_string.pod | 4 +-
doc/man3/SSL_want.pod | 2 +-
doc/man3/SSL_write.pod | 4 +-
doc/man3/UI_UTIL_read_pw.pod | 2 +-
doc/man3/UI_create_method.pod | 2 +-
doc/man3/UI_new.pod | 2 +-
doc/man3/X509V3_get_d2i.pod | 2 +-
doc/man3/X509_ALGOR_dup.pod | 4 +-
doc/man3/X509_LOOKUP_hash_dir.pod | 2 +-
doc/man3/X509_LOOKUP_meth_new.pod | 2 +-
doc/man3/X509_STORE_CTX_get_error.pod | 4 +-
doc/man3/X509_STORE_CTX_new.pod | 6 +-
doc/man3/X509_STORE_CTX_set_verify_cb.pod | 2 +-
doc/man3/X509_VERIFY_PARAM_set_flags.pod | 2 +-
doc/man3/X509_check_ca.pod | 2 +-
doc/man3/X509_check_host.pod | 8 +-
doc/man3/X509_check_purpose.pod | 4 +-
doc/man3/X509v3_get_ext_by_NID.pod | 2 +-
doc/man3/d2i_X509.pod | 4 +-
doc/man5/config.pod | 2 +-
doc/man5/x509v3_config.pod | 4 +-
doc/man7/SM2.pod | 2 +-
doc/man7/evp.pod | 12 +--
doc/man7/ossl_store.pod | 2 +-
143 files changed, 322 insertions(+), 322 deletions(-)
diff --git a/NOTES.ANDROID b/NOTES.ANDROID
index f19ec71b83..293ad4327c 100644
--- a/NOTES.ANDROID
+++ b/NOTES.ANDROID
@@ -6,8 +6,8 @@
-------------------
Beside basic tools like perl and make you'll need to download the Android
- NDK. It's available for Linux, Mac OS X and Windows, but only Linux
- version was actually tested. There is no reason to believe that Mac OS X
+ NDK. It's available for Linux, macOS and Windows, but only Linux
+ version was actually tested. There is no reason to believe that macOS
wouldn't work. And as for Windows, it's unclear which "shell" would be
suitable, MSYS2 might have best chances. NDK version should play lesser
role, the goal is to support a range of most recent versions.
diff --git a/NOTES.PERL b/NOTES.PERL
index 42c6127724..201b143867 100644
--- a/NOTES.PERL
+++ b/NOTES.PERL
@@ -109,7 +109,7 @@
$ cpan -f -i Text::Template
- Note: on VMS, you must quote any argument that contains upper case
+ Note: on VMS, you must quote any argument that contains uppercase
characters, so the lines above would be:
$ cpan -i "Text::Template"
diff --git a/NOTES.VMS b/NOTES.VMS
index d6a336ff7c..c82e231ad7 100644
--- a/NOTES.VMS
+++ b/NOTES.VMS
@@ -18,7 +18,7 @@
An ANSI C compiled is needed among other things. This means that
VAX C is not and will not be supported.
- We have only tested with DEC C (a.k.a HP VMS C / VSI C) and require
+ We have only tested with DEC C (aka HP VMS C / VSI C) and require
version 7.1 or later. Compiling with a different ANSI C compiler may
require some work.
diff --git a/NOTES.WIN b/NOTES.WIN
index b1cb542d09..26c1e6b19b 100644
--- a/NOTES.WIN
+++ b/NOTES.WIN
@@ -12,11 +12,11 @@
and require --cross-compile-prefix option. While on MSYS[2] it's solved
rather by placing gcc that produces "MinGW binary" code 1st on $PATH.
This is customarily source of confusion. "Hosted" applications "live" in
- emulated file system name space with POSIX-y root, mount points, /dev
+ emulated filesystem name space with POSIX-y root, mount points, /dev
and even /proc. Confusion is intensified by the fact that MSYS2 shell
(or rather emulated execve(2) call) examines the binary it's about to
start, and if it's found *not* to be linked with MSYS2 POSIX-y thing,
- command line arguments that look like file names get translated from
+ command line arguments that look like filenames get translated from
emulated name space to "native". For example '/c/some/where' becomes
'c:\some\where', '/dev/null' - 'nul'. This creates an illusion that
there is no difference between MSYS2 shell and "MinGW binary", but
@@ -26,7 +26,7 @@
it's referred to in quotes here, as "MinGW binary", it's just as
"native" as it can get.)
- Visual C++ builds, a.k.a. VC-*
+ Visual C++ builds, aka VC-*
==============================
Requirement details
@@ -47,7 +47,7 @@
the other hand oldest one is known not to work. Everything between
falls into best-effort category.
- - Netwide Assembler, a.k.a. NASM, available from https://www.nasm.us,
+ - Netwide Assembler, aka NASM, available from https://www.nasm.us,
is required. Note that NASM is the only supported assembler. Even
though Microsoft provided assembler is NOT supported, contemporary
64-bit version is exercised through continuous integration of
@@ -132,7 +132,7 @@
If you link with static OpenSSL libraries then you're expected to
additionally link your application with WS2_32.LIB, GDI32.LIB,
ADVAPI32.LIB, CRYPT32.LIB and USER32.LIB. Those developing
- non-interactive service applications might feel concerned about
+ noninteractive service applications might feel concerned about
linking with GDI32.LIB and USER32.LIB, as they are justly associated
with interactive desktop, which is not available to service
processes. The toolkit is designed to detect in which context it's
diff --git a/doc/man1/CA.pl.pod b/doc/man1/CA.pl.pod
index 0176f20178..7b72e32338 100644
--- a/doc/man1/CA.pl.pod
+++ b/doc/man1/CA.pl.pod
@@ -164,7 +164,7 @@ Create the CA directories and files:
CA.pl -newca
-enter cacert.pem when prompted for the CA file name.
+enter cacert.pem when prompted for the CA filename.
Create a DSA certificate request and private key (a different set of parameters
can optionally be created first):
diff --git a/doc/man1/ca.pod b/doc/man1/ca.pod
index 27bb31493a..1502946906 100644
--- a/doc/man1/ca.pod
+++ b/doc/man1/ca.pod
@@ -219,7 +219,7 @@ DNs match the order of the request. This is not needed for Xenroll.
=item B<-noemailDN>
The DN of a certificate can contain the EMAIL field if present in the
-request DN, however it is good policy just having the e-mail set into
+request DN, however, it is good policy just having the e-mail set into
the altName extension of the certificate. When this option is set the
EMAIL field is removed from the certificate' subject and set only in
the, eventually present, extensions. The B<email_in_dn> keyword can be
diff --git a/doc/man1/enc.pod b/doc/man1/enc.pod
index 6f20ac1fc7..9f5a4f487f 100644
--- a/doc/man1/enc.pod
+++ b/doc/man1/enc.pod
@@ -240,7 +240,7 @@ a strong block cipher, such as AES, in CBC mode.
All the block ciphers normally use PKCS#5 padding, also known as standard
block padding. This allows a rudimentary integrity or password check to
-be performed. However since the chance of random data passing the test
+be performed. However, since the chance of random data passing the test
is better than 1 in 256 it isn't a very good test.
If padding is disabled then the input data must be a multiple of the cipher
diff --git a/doc/man1/ocsp.pod b/doc/man1/ocsp.pod
index 736055b1b6..d4d18f8ffd 100644
--- a/doc/man1/ocsp.pod
+++ b/doc/man1/ocsp.pod
@@ -176,7 +176,7 @@ Specify the responder URL. Both HTTP and HTTPS (SSL/TLS) URLs can be specified.
=item B<-host hostname:port>, B<-path pathname>
If the B<host> option is present then the OCSP request is sent to the host
-B<hostname> on port B<port>. B<path> specifies the HTTP path name to use
+B<hostname> on port B<port>. B<path> specifies the HTTP pathname to use
or "/" by default. This is equivalent to specifying B<-url> with scheme
http:// and the given hostname, port, and pathname.
diff --git a/doc/man1/pkcs12.pod b/doc/man1/pkcs12.pod
index da887a4699..d07e8bd613 100644
--- a/doc/man1/pkcs12.pod
+++ b/doc/man1/pkcs12.pod
@@ -245,7 +245,7 @@ This option is only interpreted by MSIE and similar MS software. Normally
encryption purposes but arbitrary length keys for signing. The B<-keysig>
option marks the key for signing only. Signing only keys can be used for
S/MIME signing, authenticode (ActiveX control signing) and SSL client
-authentication, however due to a bug only MSIE 5.0 and later support
+authentication, however, due to a bug only MSIE 5.0 and later support
the use of signing only keys for SSL client authentication.
=item B<-macalg digest>
diff --git a/doc/man1/pkcs8.pod b/doc/man1/pkcs8.pod
index b079885d2f..53367dc650 100644
--- a/doc/man1/pkcs8.pod
+++ b/doc/man1/pkcs8.pod
@@ -285,7 +285,7 @@ one million iterations of the password:
Test vectors from this PKCS#5 v2.0 implementation were posted to the
pkcs-tng mailing list using triple DES, DES and RC2 with high iteration
counts, several people confirmed that they could decrypt the private
-keys produced and Therefore it can be assumed that the PKCS#5 v2.0
+keys produced and therefore, it can be assumed that the PKCS#5 v2.0
implementation is reasonably accurate at least as far as these
algorithms are concerned.
diff --git a/doc/man1/pkeyutl.pod b/doc/man1/pkeyutl.pod
index dffc449a4e..e24021508e 100644
--- a/doc/man1/pkeyutl.pod
+++ b/doc/man1/pkeyutl.pod
@@ -38,7 +38,7 @@ B<openssl> B<pkeyutl>
=head1 DESCRIPTION
-The B<pkeyutl> command can be used to perform low level public key operations
+The B<pkeyutl> command can be used to perform low-level public key operations
using any supported algorithm.
=head1 OPTIONS
diff --git a/doc/man1/s_client.pod b/doc/man1/s_client.pod
index 86cc295691..132778b4d9 100644
--- a/doc/man1/s_client.pod
+++ b/doc/man1/s_client.pod
@@ -427,11 +427,11 @@ File to send output of B<-msg> or B<-trace> to, default standard output.
=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>
@@ -781,14 +781,14 @@ is that a web client complains it has no certificates or gives an empty
list to choose from. This is normally because the server is not sending
the clients certificate authority in its "acceptable CA list" when it
requests a certificate. By using B<s_client> the CA list can be viewed
-and checked. However some servers only request client authentication
+and checked. However, some servers only request client authentication
after a specific URL is requested. To obtain the list in this case it
is necessary to use the B<-prexit> option and send an HTTP request
for an appropriate page.
If a certificate is specified on the command line using the B<-cert>
option it will not be used unless the server specifically requests
-a client certificate. Therefore merely including a client certificate
+a client certificate. Therefore, merely including a client certificate
on the command line is no guarantee that the certificate works.
If there are problems verifying a server certificate then the
diff --git a/doc/man1/s_server.pod b/doc/man1/s_server.pod
index 7fa382a8ae..5e9d09cebf 100644
--- a/doc/man1/s_server.pod
+++ b/doc/man1/s_server.pod
@@ -432,9 +432,9 @@ used in conjunction with B<-early_data>.
=item B<-id_prefix val>
Generate SSL/TLS session IDs prefixed by B<val>. This is mostly useful
-for testing any SSL/TLS code (eg. proxies) that wish to deal with multiple
+for testing any SSL/TLS code (e.g. proxies) that wish to deal with multiple
servers, when each of which might be generating a unique range of session
-IDs (eg. with a certain prefix).
+IDs (e.g. with a certain prefix).
=item B<-rand file...>
diff --git a/doc/man1/s_time.pod b/doc/man1/s_time.pod
index 04cae196a5..1085bfbbb4 100644
--- a/doc/man1/s_time.pod
+++ b/doc/man1/s_time.pod
@@ -177,14 +177,14 @@ is that a web client complains it has no certificates or gives an empty
list to choose from. This is normally because the server is not sending
the clients certificate authority in its "acceptable CA list" when it
requests a certificate. By using L<s_client(1)> the CA list can be
-viewed and checked. However some servers only request client authentication
+viewed and checked. However, some servers only request client authentication
after a specific URL is requested. To obtain the list in this case it
is necessary to use the B<-prexit> option of L<s_client(1)> and
send an HTTP request for an appropriate page.
If a certificate is specified on the command line using the B<-cert>
option it will not be used unless the server specifically requests
-a client certificate. Therefore merely including a client certificate
+a client certificate. Therefore, merely including a client certificate
on the command line is no guarantee that the certificate works.
=head1 BUGS
diff --git a/doc/man1/sess_id.pod b/doc/man1/sess_id.pod
index 6c54ed988b..543b5b7de7 100644
--- a/doc/man1/sess_id.pod
+++ b/doc/man1/sess_id.pod
@@ -142,7 +142,7 @@ The PEM encoded session format uses the header and footer lines:
Since the SSL session output contains the master key it is
possible to read the contents of an encrypted session using this
-information. Therefore appropriate security precautions should be taken if
+information. Therefore, appropriate security precautions should be taken if
the information is being output by a "real" application. This is however
strongly discouraged and should only be used for debugging purposes.
diff --git a/doc/man1/ts.pod b/doc/man1/ts.pod
index ec57ec7ebb..a21e2a5f05 100644
--- a/doc/man1/ts.pod
+++ b/doc/man1/ts.pod
@@ -101,23 +101,23 @@ the hash to the TSA.
=item 2.
The TSA attaches the current date and time to the received hash value,
-signs them and sends the time stamp token back to the client. By
+signs them and sends the timestamp token back to the client. By
creating this token the TSA certifies the existence of the original
data file at the time of response generation.
=item 3.
-The TSA client receives the time stamp token and verifies the
+The TSA client receives the timestamp token and verifies the
signature on it. It also checks if the token contains the same hash
value that it had sent to the TSA.
=back
-There is one DER encoded protocol data unit defined for transporting a time
-stamp request to the TSA and one for sending the time stamp 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. The B<ts> command has three main functions:
-creating a time stamp request based on a data file,
-creating a time stamp response based on a request, verifying if a
+creating a timestamp request based on a data file,
+creating a timestamp response based on a request, verifying if a
response corresponds to a particular request or a data file.
There is no support for sending the requests/responses automatically
@@ -128,7 +128,7 @@ requests either by ftp or e-mail.
=head2 Time Stamp Request generation
-The B<-query> switch can be used for creating and printing a time stamp
+The B<-query> switch can be used for creating and printing a timestamp
request with the following options:
=over 4
@@ -154,7 +154,7 @@ see L<openssl(1)/COMMAND SUMMARY>.
=item B<-data> file_to_hash
-The data file for which the time stamp request needs to be
+The data file for which the timestamp request needs to be
created. stdin is the default if neither the B<-data> nor the B<-digest>
parameter is specified. (Optional)
@@ -175,7 +175,7 @@ The default is SHA-1. (Optional)
=item B<-tspolicy> object_id
The policy that the client expects the TSA to use for creating the
-time stamp token. Either the dotted OID notation or OID names defined
+timestamp token. Either the dotted OID notation or OID names defined
in the config file can be used. If no policy is requested the TSA will
use its own default policy. (Optional)
@@ -193,7 +193,7 @@ response. (Optional)
=item B<-in> request.tsq
-This option specifies a previously created time stamp request in DER
+This option specifies a previously created timestamp request in DER
format that will be printed into the output file. Useful when you need
to examine the content of a request in human-readable
format. (Optional)
@@ -212,13 +212,13 @@ instead of DER. (Optional)
=head2 Time Stamp Response generation
-A time stamp response (TimeStampResp) consists of a response status
-and the time stamp token itself (ContentInfo), if the token generation was
-successful. The B<-reply> command is for creating a time stamp
-response or time stamp token based on a request and printing the
+A timestamp response (TimeStampResp) consists of a response status
+and the timestamp token itself (ContentInfo), if the token generation was
+successful. The B<-reply> command is for creating a timestamp
+response or timestamp token based on a request and printing the
response/token in human-readable format. If B<-token_out> is not
-specified the output is always a time stamp response (TimeStampResp),
-otherwise it is a time stamp token (ContentInfo).
+specified the output is always a timestamp response (TimeStampResp),
+otherwise it is a timestamp token (ContentInfo).
=over 4
@@ -237,7 +237,7 @@ used, see B<CONFIGURATION FILE OPTIONS> for details. (Optional)
=item B<-queryfile> request.tsq
-The name of the file containing a DER encoded time stamp request. (Optional)
+The name of the file containing a DER encoded timestamp request. (Optional)
=item B<-passin> password_src
@@ -282,19 +282,19 @@ B<default_policy> config file option. (Optional)
=item B<-in> response.tsr
-Specifies a previously created time stamp response or time stamp token
+Specifies a previously created timestamp response or timestamp token
(if B<-token_in> is also specified) in DER format that will be written
to the output file. This option does not require a request, it is
useful e.g. when you need to examine the content of a response or
-token or you want to extract the time stamp token from a response. If
-the input is a token and the output is a time stamp response a default
+token or you want to extract the timestamp token from a response. If
+the input is a token and the output is a timestamp response a default
'granted' status info is added to the token. (Optional)
=item B<-token_in>
This flag can be used together with the B<-in> option and indicates
-that the input is a DER encoded time stamp token (ContentInfo) instead
-of a time stamp response (TimeStampResp). (Optional)
+that the input is a DER encoded timestamp token (ContentInfo) instead
+of a timestamp response (TimeStampResp). (Optional)
=item B<-out> response.tsr
@@ -304,7 +304,7 @@ stdout. (Optional)
=item B<-token_out>
-The output is a time stamp token (ContentInfo) instead of time stamp
+The output is a timestamp token (ContentInfo) instead of timestamp
response (TimeStampResp). (Optional)
=item B<-text>
@@ -323,8 +323,8 @@ for all available algorithms. Default is builtin. (Optional)
=head2 Time Stamp Response verification
-The B<-verify> command is for verifying if a time stamp response or time
-stamp token is valid and matches a particular time stamp 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
@@ -345,18 +345,18 @@ specified with this one. (Optional)
=item B<-queryfile> request.tsq
-The original time stamp request in DER format. The B<-data> and B<-digest>
+The original timestamp request in DER format. The B<-data> and B<-digest>
options must not be specified with this one. (Optional)
=item B<-in> response.tsr
-The time stamp response that needs to be verified in DER format. (Mandatory)
+The timestamp response that needs to be verified in DER format. (Mandatory)
=item B<-token_in>
This flag can be used together with the B<-in> option and indicates
-that the input is a DER encoded time stamp token (ContentInfo) instead
-of a time stamp response (TimeStampResp). (Optional)
+that the input is a DER encoded timestamp token (ContentInfo) instead
+of a timestamp response (TimeStampResp). (Optional)
=item B<-CApath> trusted_cert_path
@@ -430,7 +430,7 @@ See L<ca(1)> for description. (Optional)
=item B<serial>
The name of the file containing the hexadecimal serial number of the
-last time stamp response created. This number is incremented by 1 for
+last timestamp response created. This number is incremented by 1 for
each response. If the file does not exist at the time of response
generation a new file is created with serial number 1. (Mandatory)
@@ -487,7 +487,7 @@ the components is missing zero is assumed for that field. (Optional)
=item B<clock_precision_digits>
Specifies the maximum number of digits, which represent the fraction of
-seconds, that need to be included in the time field. The trailing zeroes
+seconds, that need to be included in the time field. The trailing zeros
must be removed from the time, so there might actually be fewer digits,
or no fraction of seconds at all. Supported only on UNIX platforms.
The maximum value is 6, default is 0.
@@ -530,13 +530,13 @@ openssl/apps/openssl.cnf will do.
=head2 Time Stamp Request
-To create a time stamp request for design1.txt with SHA-1
+To create a timestamp request for design1.txt with SHA-1
without nonce and policy and no certificate is required in the response:
openssl ts -query -data design1.txt -no_nonce \
-out design1.tsq
-To create a similar time stamp request with specifying the message imprint
+To create a similar timestamp request with specifying the message imprint
explicitly:
openssl ts -query -digest b7e5d3f93198b38379852f2c04e78d73abdd0f4b \
@@ -546,7 +546,7 @@ To print the content of the previous request in human readable format:
openssl ts -query -in design1.tsq -text
-To create a time stamp request which includes the MD-5 digest
+To create a timestamp request which includes the MD-5 digest
of design2.txt, requests the signer certificate and nonce,
specifies a policy id (assuming the tsa_policy1 name is defined in the
OID section of the config file):
@@ -568,7 +568,7 @@ below assume that cacert.pem contains the certificate of the CA,
tsacert.pem is the signing certificate issued by cacert.pem and
tsakey.pem is the private key of the TSA.
-To create a time stamp response for a request:
+To create a timestamp response for a request:
openssl ts -reply -queryfile design1.tsq -inkey tsakey.pem \
-signer tsacert.pem -out design1.tsr
@@ -577,44 +577,44 @@ If you want to use the settings in the config file you could just write:
openssl ts -reply -queryfile design1.tsq -out design1.tsr
-To print a time stamp reply to stdout in human readable format:
+To print a timestamp reply to stdout in human readable format:
openssl ts -reply -in design1.tsr -text
-To create a time stamp token instead of time stamp response:
+To create a timestamp token instead of timestamp response:
openssl ts -reply -queryfile design1.tsq -out design1_token.der -token_out
-To print a time stamp token to stdout in human readable format:
+To print a timestamp token to stdout in human readable format:
openssl ts -reply -in design1_token.der -token_in -text -token_out
-To extract the time stamp token from a response:
+To extract the timestamp token from a response:
openssl ts -reply -in design1.tsr -out design1_token.der -token_out
-To add 'granted' status info to a time stamp token thereby creating a
+To add 'granted' status info to a timestamp token thereby creating a
valid response:
openssl ts -reply -in design1_token.der -token_in -out design1.tsr
=head2 Time Stamp Verification
-To verify a time stamp reply against a request:
+To verify a timestamp reply against a request:
openssl ts -verify -queryfile design1.tsq -in design1.tsr \
-CAfile cacert.pem -untrusted tsacert.pem
-To verify a time stamp reply that includes the certificate chain:
+To verify a timestamp reply that includes the certificate chain:
openssl ts -verify -queryfile design2.tsq -in design2.tsr \
-CAfile cacert.pem
-To verify a time stamp token against the original data file:
+To verify a timestamp token against the original data file:
openssl ts -verify -data design2.txt -in design2.tsr \
-CAfile cacert.pem
-To verify a time stamp token against a message imprint:
+To verify a timestamp token against a message imprint:
openssl ts -verify -digest b7e5d3f93198b38379852f2c04e78d73abdd0f4b \
-in design2.tsr -CAfile cacert.pem
@@ -628,7 +628,7 @@ You could also look at the 'test' directory for more examples.
=item *
-No support for time stamps over SMTP, though it is quite easy
+No support for timestamps over SMTP, though it is quite easy
to implement an automatic e-mail based TSA with L<procmail(1)>
and L<perl(1)>. HTTP server support is provided in the form of
a separate apache module. HTTP client support is provided by
@@ -638,7 +638,7 @@ L<tsget(1)>. Pure TCP/IP protocol is not supported.
The file containing the last serial number of the TSA is not
locked when being read or written. This is a problem if more than one
-instance of L<openssl(1)> is trying to create a time stamp
+instance of L<openssl(1)> is trying to create a timestamp
response at the same time. This is not an issue when using the apache
server module, it does proper locking.
diff --git a/doc/man1/tsget.pod b/doc/man1/tsget.pod
index 43bf2c7e35..9f58201fd5 100644
--- a/doc/man1/tsget.pod
+++ b/doc/man1/tsget.pod
@@ -24,15 +24,15 @@ B<-h> server_url
=head1 DESCRIPTION
-The B<tsget> command can be used for sending a time stamp request, as
-specified in B<RFC 3161>, to a time stamp server over HTTP or HTTPS and storing
-the time stamp response in a file. This tool cannot be used for creating the
+The B<tsget> command can be used for sending a timestamp request, as
+specified in B<RFC 3161>, to a timestamp server over HTTP or HTTPS and storing
+the timestamp response in a file. This tool cannot be used for creating the
requests and verifying responses, you can use the OpenSSL B<ts(1)> command to
do that. B<tsget> can send several requests to the server without closing
the TCP connection if more than one requests are specified on the command
line.
-The tool sends the following HTTP request for each time stamp request:
+The tool sends the following HTTP request for each timestamp request:
POST url HTTP/1.1
User-Agent: OpenTSA tsget.pl/<version>
@@ -53,7 +53,7 @@ written to a file without any interpretation.
=item B<-h> server_url
-The URL of the HTTP/HTTPS server listening for time stamp requests.
+The URL of the HTTP/HTTPS server listening for timestamp requests.
=item B<-e> extension
@@ -64,8 +64,8 @@ the input files. Default extension is '.tsr'. (Optional)
=item B<-o> output
This option can be specified only when just one request is sent to the
-server. The time stamp response will be written to the given output file. '-'
-means standard output. In case of multiple time stamp requests or the absence
+server. The timestamp response will be written to the given output file. '-'
+means standard output. In case of multiple timestamp requests or the absence
of this argument the names of the output files will be derived from the names
of the input files and the default or specified extension argument. (Optional)
@@ -124,7 +124,7 @@ The name of an EGD socket to get random data from. (Optional)
=item [request]...
-List of files containing B<RFC 3161> DER-encoded time stamp requests. If no
+List of files containing B<RFC 3161> DER-encoded timestamp requests. If no
requests are specified only one request will be sent to the server and it will be
read from the standard input. (Optional)
@@ -139,35 +139,35 @@ arguments.
=head1 EXAMPLES
The examples below presume that B<file1.tsq> and B<file2.tsq> contain valid
-time stamp requests, tsa.opentsa.org listens at port 8080 for HTTP requests
+timestamp requests, tsa.opentsa.org listens at port 8080 for HTTP requests
and at port 8443 for HTTPS requests, the TSA service is available at the /tsa
absolute path.
-Get a time stamp response for file1.tsq over HTTP, output is written to
+Get a timestamp response for file1.tsq over HTTP, output is written to
file1.tsr:
tsget -h http://tsa.opentsa.org:8080/tsa file1.tsq
-Get a time stamp response for file1.tsq and file2.tsq over HTTP showing
+Get a timestamp response for file1.tsq and file2.tsq over HTTP showing
progress, output is written to file1.reply and file2.reply respectively:
tsget -h http://tsa.opentsa.org:8080/tsa -v -e .reply \
file1.tsq file2.tsq
-Create a time stamp request, write it to file3.tsq, send it to the server and
+Create a timestamp request, write it to file3.tsq, send it to the server and
write the response to file3.tsr:
openssl ts -query -data file3.txt -cert | tee file3.tsq \
| tsget -h http://tsa.opentsa.org:8080/tsa \
-o file3.tsr
-Get a time stamp response for file1.tsq over HTTPS without client
+Get a timestamp response for file1.tsq over HTTPS without client
authentication:
tsget -h https://tsa.opentsa.org:8443/tsa \
-C cacerts.pem file1.tsq
-Get a time stamp response for file1.tsq over HTTPS with certificate-based
+Get a timestamp response for file1.tsq over HTTPS with certificate-based
client authentication (it will ask for the passphrase if client_key.pem is
protected):
diff --git a/doc/man1/verify.pod b/doc/man1/verify.pod
index 18e803c8d6..0a49d790c0 100644
--- a/doc/man1/verify.pod
+++ b/doc/man1/verify.pod
@@ -336,7 +336,7 @@ in PEM format.
=head1 VERIFY OPERATION
The B<verify> program uses the same functions as the internal SSL and S/MIME
-verification, therefore this description applies to these verify operations
+verification, therefore, this description applies to these verify operations
too.
There is one crucial difference between the verify operations performed
diff --git a/doc/man1/x509.pod b/doc/man1/x509.pod
index 65cec9dbda..98d285e414 100644
--- a/doc/man1/x509.pod
+++ b/doc/man1/x509.pod
@@ -255,7 +255,7 @@ Prints out the start and expiry dates of a certificate.
=item B<-checkend arg>
Checks if the certificate expires within the next B<arg> seconds and exits
-non-zero if yes it will expire or zero if not.
+nonzero if yes it will expire or zero if not.
=item B<-fingerprint>
diff --git a/doc/man3/ASN1_INTEGER_get_int64.pod b/doc/man3/ASN1_INTEGER_get_int64.pod
index ac6a5799df..b4f961eab8 100644
--- a/doc/man3/ASN1_INTEGER_get_int64.pod
+++ b/doc/man3/ASN1_INTEGER_get_int64.pod
@@ -81,7 +81,7 @@ instead.
In general an B<ASN1_INTEGER> or B<ASN1_ENUMERATED> type can contain an
integer of almost arbitrary size and so cannot always be represented by a C
-B<int64_t> type. However in many cases (for example version numbers) they
+B<int64_t> type. However, in many cases (for example version numbers) they
represent small integers which can be more easily manipulated if converted to
an appropriate C integer type.
diff --git a/doc/man3/ASN1_STRING_length.pod b/doc/man3/ASN1_STRING_length.pod
index 85d356540b..595e63ad51 100644
--- a/doc/man3/ASN1_STRING_length.pod
+++ b/doc/man3/ASN1_STRING_length.pod
@@ -72,7 +72,7 @@ In general it cannot be assumed that the data returned by ASN1_STRING_data()
is null terminated or does not contain embedded nulls. The actual format
of the data will depend on the actual string type itself: for example
for an IA5String the data will be ASCII, for a BMPString two bytes per
-character in big endian format, and for an UTF8String it will be in UTF8 format.
+character in big endian format, and for a UTF8String it will be in UTF8 format.
Similar care should be take to ensure the data is in the correct format
when calling ASN1_STRING_set().
diff --git a/doc/man3/ASN1_TIME_set.pod b/doc/man3/ASN1_TIME_set.pod
index 5ed817517d..a115db4c85 100644
--- a/doc/man3/ASN1_TIME_set.pod
+++ b/doc/man3/ASN1_TIME_set.pod
@@ -117,7 +117,7 @@ one or both (depending on the time difference) of B<*pday> and B<*psec>
will be positive. If B<to> represents a time earlier than B<from> then
one or both of B<*pday> and B<*psec> will be negative. If B<to> and B<from>
represent the same time then B<*pday> and B<*psec> will both be zero.
-If both B<*pday> and B<*psec> are non-zero they will always have the same
+If both B<*pday> and B<*psec> are nonzero they will always have the same
sign. The value of B<*psec> will always be less than the number of seconds
in a day. If B<from> or B<to> is NULL the current time is used.
@@ -167,7 +167,7 @@ format.
=head1 BUGS
ASN1_TIME_print(), ASN1_UTCTIME_print() and ASN1_GENERALIZEDTIME_print()
-do not print out the time zone: it either prints out "GMT" or nothing. But all
+do not print out the timezone: it either prints out "GMT" or nothing. But all
certificates complying with RFC5280 et al use GMT anyway.
Use the ASN1_TIME_normalize() function to normalize the time value before
diff --git a/doc/man3/ASN1_TYPE_get.pod b/doc/man3/ASN1_TYPE_get.pod
index fb797220a4..f14850b39f 100644
--- a/doc/man3/ASN1_TYPE_get.pod
+++ b/doc/man3/ASN1_TYPE_get.pod
@@ -33,7 +33,7 @@ up after the call.
ASN1_TYPE_set1() sets the value of B<a> to B<type> a copy of B<value>.
ASN1_TYPE_cmp() compares ASN.1 types B<a> and B<b> and returns 0 if
-they are identical and non-zero otherwise.
+they are identical and nonzero otherwise.
ASN1_TYPE_unpack_sequence() attempts to parse the SEQUENCE present in
B<t> using the ASN.1 structure B<it>. If successful it returns a pointer
@@ -62,12 +62,12 @@ length octets).
ASN1_TYPE_cmp() may not return zero if two types are equivalent but have
different encodings. For example the single content octet of the boolean TRUE
-value under BER can have any non-zero encoding but ASN1_TYPE_cmp() will
+value under BER can have any nonzero encoding but ASN1_TYPE_cmp() will
only return zero if the values are the same.
If either or both of the parameters passed to ASN1_TYPE_cmp() is NULL the
-return value is non-zero. Technically if both parameters are NULL the two
-types could be absent OPTIONAL fields and so should match, however passing
+return value is nonzero. Technically if both parameters are NULL the two
+types could be absent OPTIONAL fields and so should match, however, passing
NULL values could also indicate a programming error (for example an
unparsable type which returns NULL) for types which do B<not> match. So
applications should handle the case of two absent values separately.
@@ -80,7 +80,7 @@ ASN1_TYPE_set() does not return a value.
ASN1_TYPE_set1() returns 1 for success and 0 for failure.
-ASN1_TYPE_cmp() returns 0 if the types are identical and non-zero otherwise.
+ASN1_TYPE_cmp() returns 0 if the types are identical and nonzero otherwise.
ASN1_TYPE_unpack_sequence() returns a pointer to an ASN.1 structure or
NULL on failure.
diff --git a/doc/man3/ASYNC_WAIT_CTX_new.pod b/doc/man3/ASYNC_WAIT_CTX_new.pod
index e4d809c08f..6f6a217e16 100644
--- a/doc/man3/ASYNC_WAIT_CTX_new.pod
+++ b/doc/man3/ASYNC_WAIT_CTX_new.pod
@@ -50,7 +50,7 @@ job in B<*fd>. The number of file descriptors returned will be stored in
B<*numfds>. It is the caller's responsibility to ensure that sufficient memory
has been allocated in B<*fd> to receive all the file descriptors. Calling
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
+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 normally this call will only ever return
@@ -117,7 +117,7 @@ success or 0 on error.
On Windows platforms the openssl/async.h header is dependent on some
of the types customarily made available by including windows.h. The
application developer is likely to require control over when the latter
-is included, commonly as one of the first included headers. Therefore
+is included, commonly as one of the first included headers. Therefore,
it is defined as an application developer's responsibility to include
windows.h prior to async.h.
diff --git a/doc/man3/ASYNC_start_job.pod b/doc/man3/ASYNC_start_job.pod
index b06db76708..b7f3448bb5 100644
--- a/doc/man3/ASYNC_start_job.pod
+++ b/doc/man3/ASYNC_start_job.pod
@@ -166,7 +166,7 @@ otherwise.
On Windows platforms the openssl/async.h header is dependent on some
of the types customarily made available by including windows.h. The
application developer is likely to require control over when the latter
-is included, commonly as one of the first included headers. Therefore
+is included, commonly as one of the first included headers. Therefore,
it is defined as an application developer's responsibility to include
windows.h prior to async.h.
diff --git a/doc/man3/BF_encrypt.pod b/doc/man3/BF_encrypt.pod
index b20f634da6..ebf1e3f89b 100644
--- a/doc/man3/BF_encrypt.pod
+++ b/doc/man3/BF_encrypt.pod
@@ -60,7 +60,7 @@ recipient needs to know what it was initialized with, or it won't be able
to decrypt. Some programs and protocols simplify this, like SSH, where
B<ivec> is simply initialized to zero.
BF_cbc_encrypt() operates on data that is a multiple of 8 bytes long, while
-BF_cfb64_encrypt() and BF_ofb64_encrypt() are used to encrypt an variable
+BF_cfb64_encrypt() and BF_ofb64_encrypt() are used to encrypt a variable
number of bytes (the amount does not have to be an exact multiple of 8). The
purpose of the latter two is to simulate stream ciphers, and therefore, they
need the parameter B<num>, which is a pointer to an integer where the current
diff --git a/doc/man3/BIO_ADDR.pod b/doc/man3/BIO_ADDR.pod
index 4b169e8a89..c23d62be92 100644
--- a/doc/man3/BIO_ADDR.pod
+++ b/doc/man3/BIO_ADDR.pod
@@ -42,7 +42,7 @@ BIO_ADDR_free() frees a B<BIO_ADDR> created with BIO_ADDR_new().
BIO_ADDR_clear() clears any data held within the provided B<BIO_ADDR> and sets
it back to an uninitialised state.
-BIO_ADDR_rawmake() takes a protocol B<family>, an byte array of
+BIO_ADDR_rawmake() takes a protocol B<family>, a byte array of
size B<wherelen> with an address in network byte order pointed at
by B<where> and a port number in network byte order in B<port> (except
for the B<AF_UNIX> protocol family, where B<port> is meaningless and
diff --git a/doc/man3/BIO_ADDRINFO.pod b/doc/man3/BIO_ADDRINFO.pod
index 8ca6454abb..8414a118d5 100644
--- a/doc/man3/BIO_ADDRINFO.pod
+++ b/doc/man3/BIO_ADDRINFO.pod
@@ -94,7 +94,7 @@ information they should return isn't available.
The BIO_lookup_ex() implementation uses the platform provided getaddrinfo()
function. On Linux it is known that specifying 0 for the protocol will not
-return any SCTP based addresses when calling getaddrinfo(). Therefore if an SCTP
+return any SCTP based addresses when calling getaddrinfo(). Therefore, if an SCTP
address is required then the B<protocol> parameter to BIO_lookup_ex() should be
explicitly set to IPPROTO_SCTP. The same may be true on other platforms.
diff --git a/doc/man3/BIO_connect.pod b/doc/man3/BIO_connect.pod
index 853315aa46..c695e0730a 100644
--- a/doc/man3/BIO_connect.pod
+++ b/doc/man3/BIO_connect.pod
@@ -55,7 +55,7 @@ Enables regular sending of keep-alive messages.
=item BIO_SOCK_NONBLOCK
-Sets the socket to non-blocking mode.
+Sets the socket to nonblocking mode.
=item BIO_SOCK_NODELAY
diff --git a/doc/man3/BIO_ctrl.pod b/doc/man3/BIO_ctrl.pod
index 60cd10883b..9fd60a6747 100644
--- a/doc/man3/BIO_ctrl.pod
+++ b/doc/man3/BIO_ctrl.pod
@@ -109,7 +109,7 @@ Filter BIOs if they do not internally handle a particular BIO_ctrl()
operation usually pass the operation to the next BIO in the chain.
This often means there is no need to locate the required BIO for
a particular operation, it can be called on a chain and it will
-be automatically passed to the relevant BIO. However this can cause
+be automatically passed to the relevant BIO. However, this can cause
unexpected results: for example no current filter BIOs implement
BIO_seek(), but this may still succeed if the chain ends in a FILE
or file descriptor BIO.
diff --git a/doc/man3/BIO_get_data.pod b/doc/man3/BIO_get_data.pod
index c3137c4c55..4b10e1a90e 100644
--- a/doc/man3/BIO_get_data.pod
+++ b/doc/man3/BIO_get_data.pod
@@ -25,7 +25,7 @@ the BIO. This data can subsequently be retrieved via a call to BIO_get_data().
This can be used by custom BIOs for storing implementation specific information.
The BIO_set_init() function sets the value of the BIO's "init" flag to indicate
-whether initialisation has been completed for this BIO or not. A non-zero value
+whether initialisation has been completed for this BIO or not. A nonzero value
indicates that initialisation is complete, whilst zero indicates that it is not.
Often initialisation will complete during initial construction of the BIO. For
some BIOs however, initialisation may not complete until after additional steps
diff --git a/doc/man3/BIO_parse_hostserv.pod b/doc/man3/BIO_parse_hostserv.pod
index 73cb6100d7..01fa8abd85 100644
--- a/doc/man3/BIO_parse_hostserv.pod
+++ b/doc/man3/BIO_parse_hostserv.pod
@@ -19,10 +19,10 @@ BIO_parse_hostserv
=head1 DESCRIPTION
BIO_parse_hostserv() will parse the information given in B<hostserv>,
-create strings with the host name and service name and give those
+create strings with the hostname and service name and give those
back via B<host> and B<service>. Those will need to be freed after
they are used. B<hostserv_prio> helps determine if B<hostserv> shall
-be interpreted primarily as a host name or a service name in ambiguous
+be interpreted primarily as a hostname or a service name in ambiguous
cases.
The syntax the BIO_parse_hostserv() recognises is:
diff --git a/doc/man3/BIO_read.pod b/doc/man3/BIO_read.pod
index 270ab533e5..f548cdd226 100644
--- a/doc/man3/BIO_read.pod
+++ b/doc/man3/BIO_read.pod
@@ -55,7 +55,7 @@ NUL is not included in the length returned by BIO_gets().
=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.
diff --git a/doc/man3/BIO_s_accept.pod b/doc/man3/BIO_s_accept.pod
index 37b6f4d839..7b5ac87e66 100644
--- a/doc/man3/BIO_s_accept.pod
+++ b/doc/man3/BIO_s_accept.pod
@@ -143,7 +143,7 @@ however because the accept BIO will still accept additional incoming
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
diff --git a/doc/man3/BIO_s_bio.pod b/doc/man3/BIO_s_bio.pod
index f78fe13489..ba6225c893 100644
--- a/doc/man3/BIO_s_bio.pod
+++ b/doc/man3/BIO_s_bio.pod
@@ -144,7 +144,7 @@ without having to go through the SSL-interface.
...
BIO_new_bio_pair(&internal_bio, 0, &network_bio, 0);
SSL_set_bio(ssl, internal_bio, internal_bio);
- SSL_operations(); /* e.g SSL_read and SSL_write */
+ SSL_operations(); /* e.g. SSL_read and SSL_write */
...
application | TLS-engine
@@ -167,7 +167,7 @@ without having to go through the SSL-interface.
...
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.
diff --git a/doc/man3/BIO_s_connect.pod b/doc/man3/BIO_s_connect.pod
index 4f145297c5..aa99c92abe 100644
--- a/doc/man3/BIO_s_connect.pod
+++ b/doc/man3/BIO_s_connect.pod
@@ -106,7 +106,7 @@ If blocking I/O is set then a non positive return value from any
I/O call is caused by an error condition, although a zero return
will normally mean that the connection was closed.
-If the port name is supplied as part of the host name then this will
+If the port name is supplied as part of the hostname then this will
override any value set with BIO_set_conn_port(). This may be undesirable
if the application does not wish to allow connection to arbitrary
ports. This can be avoided by checking for the presence of the ':'
diff --git a/doc/man3/BIO_s_file.pod b/doc/man3/BIO_s_file.pod
index 2ed0bb3c0f..12843b0125 100644
--- a/doc/man3/BIO_s_file.pod
+++ b/doc/man3/BIO_s_file.pod
@@ -78,7 +78,7 @@ in stdio behaviour will be mirrored by the corresponding BIO.
On Windows BIO_new_files reserves for the filename argument to be
UTF-8 encoded. In other words if you have to make it work in multi-
-lingual environment, encode file names in UTF-8.
+lingual environment, encode filenames in UTF-8.
=head1 RETURN VALUES
diff --git a/doc/man3/BIO_set_callback.pod b/doc/man3/BIO_set_callback.pod
index 291456baa4..c9281a83ad 100644
--- a/doc/man3/BIO_set_callback.pod
+++ b/doc/man3/BIO_set_callback.pod
@@ -31,7 +31,7 @@ BIO_callback_fn_ex, BIO_callback_fn
=head1 DESCRIPTION
BIO_set_callback_ex() and BIO_get_callback_ex() set and retrieve the BIO
-callback. The callback is called during most high level BIO operations. It can
+callback. The callback is called during most high-level BIO operations. It can
be used for debugging purposes to trace operations on a BIO or to modify its
operation.
diff --git a/doc/man3/BN_add.pod b/doc/man3/BN_add.pod
index 0f0e49556d..7203b78d13 100644
--- a/doc/man3/BN_add.pod
+++ b/doc/man3/BN_add.pod
@@ -68,16 +68,16 @@ For division by powers of 2, use BN_rshift(3).
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
diff --git a/doc/man3/BN_bn2bin.pod b/doc/man3/BN_bn2bin.pod
index b3cbc8cb66..8548a16954 100644
--- a/doc/man3/BN_bn2bin.pod
+++ b/doc/man3/BN_bn2bin.pod
@@ -37,7 +37,7 @@ memory.
BN_bn2binpad() also converts the absolute value of B<a> into big-endian form
and stores it at B<to>. B<tolen> indicates the length of the output buffer
-B<to>. The result is padded with zeroes if necessary. If B<tolen> is less than
+B<to>. The result is padded with zeros if necessary. If B<tolen> is less than
BN_num_bytes(B<a>) an error is returned.
BN_bin2bn() converts the positive integer in big-endian form of length
diff --git a/doc/man3/BN_generate_prime.pod b/doc/man3/BN_generate_prime.pod
index f1e63f3b3c..25674d0348 100644
--- a/doc/man3/BN_generate_prime.pod
+++ b/doc/man3/BN_generate_prime.pod
@@ -127,7 +127,7 @@ For instance, to reach the 128 bit security level, B<nchecks> should be set to
If B<cb> is not B<NULL>, B<BN_GENCB_call(cb, 1, j)> is called
after the j-th iteration (j = 0, 1, ...). B<ctx> is a
-pre-allocated B<BN_CTX> (to save the overhead of allocating and
+preallocated B<BN_CTX> (to save the overhead of allocating and
freeing the structure in a loop), or B<NULL>.
BN_GENCB_call() calls the callback function held in the B<BN_GENCB> structure
diff --git a/doc/man3/BN_mod_mul_montgomery.pod b/doc/man3/BN_mod_mul_montgomery.pod
index 7f47e94c2b..c0d43bbad6 100644
--- a/doc/man3/BN_mod_mul_montgomery.pod
+++ b/doc/man3/BN_mod_mul_montgomery.pod
@@ -49,7 +49,7 @@ the result in I<r>.
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.
diff --git a/doc/man3/BN_set_bit.pod b/doc/man3/BN_set_bit.pod
index af02983c8f..537d730d74 100644
--- a/doc/man3/BN_set_bit.pod
+++ b/doc/man3/BN_set_bit.pod
@@ -37,11 +37,11 @@ BN_mask_bits() truncates B<a> to an B<n> bit number
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.
diff --git a/doc/man3/CMS_verify.pod b/doc/man3/CMS_verify.pod
index b6650fdeb6..b761c9281b 100644
--- a/doc/man3/CMS_verify.pod
+++ b/doc/man3/CMS_verify.pod
@@ -94,7 +94,7 @@ useful if one merely wishes to write the content to B<out> and its validity
is not considered important.
Chain verification should arguably be performed using the signing time rather
-than the current time. However since the signing time is supplied by the
+than the current time. However, since the signing time is supplied by the
signer it cannot be trusted without additional evidence (such as a trusted
timestamp).
diff --git a/doc/man3/CRYPTO_THREAD_run_once.pod b/doc/man3/CRYPTO_THREAD_run_once.pod
index b919e2e478..7f0392ceb1 100644
--- a/doc/man3/CRYPTO_THREAD_run_once.pod
+++ b/doc/man3/CRYPTO_THREAD_run_once.pod
@@ -93,7 +93,7 @@ On Windows platforms the CRYPTO_THREAD_* types and functions in the
openssl/crypto.h header are dependent on some of the types customarily
made available by including windows.h. The application developer is
likely to require control over when the latter is included, commonly as
-one of the first included headers. Therefore it is defined as an
+one of the first included headers. Therefore, it is defined as an
application developer's responsibility to include windows.h prior to
crypto.h where use of CRYPTO_THREAD_* types and functions is required.
diff --git a/doc/man3/CRYPTO_memcmp.pod b/doc/man3/CRYPTO_memcmp.pod
index 9182d00796..a65a41fdcf 100644
--- a/doc/man3/CRYPTO_memcmp.pod
+++ b/doc/man3/CRYPTO_memcmp.pod
@@ -19,13 +19,13 @@ contents of the memory regions pointed to by B<a> and B<b>.
=head1 RETURN VALUES
-CRYPTO_memcmp() returns 0 if the memory regions are equal and non-zero
+CRYPTO_memcmp() returns 0 if the memory regions are equal and nonzero
otherwise.
=head1 NOTES
Unlike memcmp(2), this function cannot be used to order the two memory regions
-as the return value when they differ is undefined, other than being non-zero.
+as the return value when they differ is undefined, other than being nonzero.
=head1 COPYRIGHT
diff --git a/doc/man3/DES_random_key.pod b/doc/man3/DES_random_key.pod
index 04df6ec0df..035d7f876a 100644
--- a/doc/man3/DES_random_key.pod
+++ b/doc/man3/DES_random_key.pod
@@ -120,7 +120,7 @@ is returned. If the key is a weak key, then -2 is returned. If an
error is returned, the key schedule is not generated.
DES_set_key() works like
-DES_set_key_checked() if the I<DES_check_key> flag is non-zero,
+DES_set_key_checked() if the I<DES_check_key> flag is nonzero,
otherwise like DES_set_key_unchecked(). These functions are available
for compatibility; it is recommended to use a function that does not
depend on a global variable.
@@ -137,7 +137,7 @@ DES_ecb_encrypt() is the basic DES encryption routine that encrypts or
decrypts a single 8-byte I<DES_cblock> in I<electronic code book>
(ECB) mode. It always transforms the input data, pointed to by
I<input>, into the output data, pointed to by the I<output> argument.
-If the I<encrypt> argument is non-zero (DES_ENCRYPT), the I<input>
+If the I<encrypt> argument is nonzero (DES_ENCRYPT), the I<input>
(cleartext) is encrypted in to the I<output> (ciphertext) using the
key_schedule specified by the I<schedule> argument, previously set via
I<DES_set_key>. If I<encrypt> is zero (DES_DECRYPT), the I<input> (now
@@ -156,7 +156,7 @@ The macro DES_ecb2_encrypt() is provided to perform two-key Triple-DES
encryption by using I<ks1> for the final encryption.
DES_ncbc_encrypt() encrypts/decrypts using the I<cipher-block-chaining>
-(CBC) mode of DES. If the I<encrypt> argument is non-zero, the
+(CBC) mode of DES. If the I<encrypt> argument is nonzero, the
routine cipher-block-chain encrypts the cleartext data pointed to by
the I<input> argument into the ciphertext pointed to by the I<output>
argument, using the key schedule provided by the I<schedule> argument,
diff --git a/doc/man3/DH_get0_pqg.pod b/doc/man3/DH_get0_pqg.pod
index e878fa0051..feec38e492 100644
--- a/doc/man3/DH_get0_pqg.pod
+++ b/doc/man3/DH_get0_pqg.pod
@@ -81,7 +81,7 @@ DH_get0_engine() returns a handle to the ENGINE that has been set for this DH
object, or NULL if no such ENGINE has been set.
The DH_get_length() and DH_set_length() functions get and set the optional
-length parameter associated with this DH object. If the length is non-zero then
+length parameter associated with this DH object. If the length is nonzero then
it is used, otherwise it is ignored. The B<length> parameter indicates the
length of the secret exponent (private key) in bits.
diff --git a/doc/man3/DH_set_method.pod b/doc/man3/DH_set_method.pod
index ea45961f15..c183383860 100644
--- a/doc/man3/DH_set_method.pod
+++ b/doc/man3/DH_set_method.pod
@@ -45,7 +45,7 @@ DH_set_method() selects B<meth> to perform all operations using the key B<dh>.
This will replace the DH_METHOD used by the DH key and if the previous method
was supplied by an ENGINE, the handle to that ENGINE will be released during the
change. It is possible to have DH keys that only work with certain DH_METHOD
-implementations (eg. from an ENGINE module that supports embedded
+implementations (e.g. from an ENGINE module that supports embedded
hardware-protected keys), and in such cases attempting to change the DH_METHOD
for the key can have unexpected results.
@@ -64,7 +64,7 @@ B<DH_METHOD>s.
DH_set_default_method() returns no value.
-DH_set_method() returns non-zero if the provided B<meth> was successfully set as
+DH_set_method() returns nonzero if the provided B<meth> was successfully set as
the method for B<dh> (including unloading the ENGINE handle if the previous
method was supplied by an ENGINE).
diff --git a/doc/man3/DSA_set_method.pod b/doc/man3/DSA_set_method.pod
index f10307e66d..ee91e01cb9 100644
--- a/doc/man3/DSA_set_method.pod
+++ b/doc/man3/DSA_set_method.pod
@@ -46,7 +46,7 @@ DSA_set_method() selects B<meth> to perform all operations using the key
B<rsa>. This will replace the DSA_METHOD used by the DSA key and if the
previous method was supplied by an ENGINE, the handle to that ENGINE will
be released during the change. It is possible to have DSA keys that only
-work with certain DSA_METHOD implementations (eg. from an ENGINE module
+work with certain DSA_METHOD implementations (e.g. from an ENGINE module
that supports embedded hardware-protected keys), and in such cases
attempting to change the DSA_METHOD for the key can have unexpected
results. See L<DSA_meth_new> for information on constructing custom DSA_METHOD
@@ -64,7 +64,7 @@ B<DSA_METHOD>s.
DSA_set_default_method() returns no value.
-DSA_set_method() returns non-zero if the provided B<meth> was successfully set as
+DSA_set_method() returns nonzero if the provided B<meth> was successfully set as
the method for B<dsa> (including unloading the ENGINE handle if the previous
method was supplied by an ENGINE).
diff --git a/doc/man3/DTLSv1_listen.pod b/doc/man3/DTLSv1_listen.pod
index 98511a475f..7daa32bd1a 100644
--- a/doc/man3/DTLSv1_listen.pod
+++ b/doc/man3/DTLSv1_listen.pod
@@ -35,7 +35,7 @@ message then the amplification attack has succeeded.
If DTLS is used over UDP (or any datagram based protocol that does not validate
the source IP) then it is susceptible to this type of attack. TLSv1.3 is
designed to operate over a stream-based transport protocol (such as TCP).
-If TCP is being used then there is no need to use SSL_stateless(). However some
+If TCP is being used then there is no need to use SSL_stateless(). However, some
stream-based transport protocols (e.g. QUIC) may not validate the source
address. In this case a TLSv1.3 application would be susceptible to this attack.
@@ -98,7 +98,7 @@ will be set up ready to continue the handshake. the B<peer> value will also be
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.
diff --git a/doc/man3/ECDSA_SIG_new.pod b/doc/man3/ECDSA_SIG_new.pod
index 6a7d107079..bce8691f28 100644
--- a/doc/man3/ECDSA_SIG_new.pod
+++ b/doc/man3/ECDSA_SIG_new.pod
@@ -5,7 +5,7 @@
ECDSA_SIG_get0, ECDSA_SIG_get0_r, ECDSA_SIG_get0_s, ECDSA_SIG_set0,
ECDSA_SIG_new, ECDSA_SIG_free, ECDSA_size, ECDSA_sign, ECDSA_do_sign,
ECDSA_verify, ECDSA_do_verify, ECDSA_sign_setup, ECDSA_sign_ex,
-ECDSA_do_sign_ex - low level elliptic curve digital signature algorithm (ECDSA)
+ECDSA_do_sign_ex - low-level elliptic curve digital signature algorithm (ECDSA)
functions
=head1 SYNOPSIS
@@ -40,7 +40,7 @@ functions
=head1 DESCRIPTION
-Note: these functions provide a low level interface to ECDSA. Most
+Note: these functions provide a low-level interface to ECDSA. Most
applications should use the higher level B<EVP> interface such as
L<EVP_DigestSignInit(3)> or L<EVP_DigestVerifyInit(3)> instead.
diff --git a/doc/man3/EC_GROUP_new.pod b/doc/man3/EC_GROUP_new.pod
index c80b191785..04767d7688 100644
--- a/doc/man3/EC_GROUP_new.pod
+++ b/doc/man3/EC_GROUP_new.pod
@@ -84,7 +84,7 @@ specific PK B<params>.
EC_GROUP_set_curve() sets the curve parameters B<p>, B<a> and B<b>. For a curve
over Fp B<p> is the prime for the field. For a curve over F2^m B<p> represents
the irreducible polynomial - each bit represents a term in the polynomial.
-Therefore there will either be three or five bits set dependent on whether the
+Therefore, there will either be three or five bits set dependent on whether the
polynomial is a trinomial or a pentanomial.
In either case, B<a> and B<b> represents the coefficients a and b from the
relevant equation introduced above.
diff --git a/doc/man3/EC_POINT_new.pod b/doc/man3/EC_POINT_new.pod
index 8cadaa75f1..4820d8597a 100644
--- a/doc/man3/EC_POINT_new.pod
+++ b/doc/man3/EC_POINT_new.pod
@@ -148,7 +148,7 @@ EC_POINT_get_Jprojective_coordinates_GFp() respectively.
Points can also be described in terms of their compressed co-ordinates. For a
point (x, y), for any given value for x such that the point is on the curve
-there will only ever be two possible values for y. Therefore a point can be set
+there will only ever be two possible values for y. Therefore, a point can be set
using the EC_POINT_set_compressed_coordinates() function where B<x> is the x
co-ordinate and B<y_bit> is a value 0 or 1 to identify which of the two
possible values for y should be used.
diff --git a/doc/man3/ENGINE_add.pod b/doc/man3/ENGINE_add.pod
index a2fc299482..b44c8e591f 100644
--- a/doc/man3/ENGINE_add.pod
+++ b/doc/man3/ENGINE_add.pod
@@ -181,7 +181,7 @@ implementation includes the following abstractions;
=head2 Reference counting and handles
Due to the modular nature of the ENGINE API, pointers to ENGINEs need to be
-treated as handles - ie. not only as pointers, but also as references to
+treated as handles - i.e. not only as pointers, but also as references to
the underlying ENGINE object. Ie. one should obtain a new reference when
making copies of an ENGINE pointer if the copies will be used (and
released) independently.
@@ -252,15 +252,15 @@ operational ENGINE for a given cryptographic purpose.
To obtain a functional reference from an existing structural reference,
call the ENGINE_init() function. This returns zero if the ENGINE was not
-already operational and couldn't be successfully initialised (eg. lack of
+already operational and couldn't be successfully initialised (e.g. lack of
system drivers, no special hardware attached, etc), otherwise it will
-return non-zero to indicate that the ENGINE is now operational and will
+return nonzero to indicate that the ENGINE is now operational and will
have allocated a new B<functional> reference to the ENGINE. All functional
references are released by calling ENGINE_finish() (which removes the
implicit structural reference as well).
The second way to get a functional reference is by asking OpenSSL for a
-default implementation for a given task, eg. by ENGINE_get_default_RSA(),
+default implementation for a given task, e.g. by ENGINE_get_default_RSA(),
ENGINE_get_default_cipher_engine(), etc. These are discussed in the next
section, though they are not usually required by application programmers as
they are used automatically when creating and using the relevant
@@ -278,7 +278,7 @@ In the case of other abstractions like RSA, DSA, etc, there is only one
"algorithm" so all implementations implicitly register using the same 'nid'
index.
-When a default ENGINE is requested for a given abstraction/algorithm/mode, (eg.
+When a default ENGINE is requested for a given abstraction/algorithm/mode, (e.g.
when calling RSA_new_method(NULL)), a "get_default" call will be made to the
ENGINE subsystem to process the corresponding state table and return a
functional reference to an initialised ENGINE whose implementation should be
@@ -328,7 +328,7 @@ is something for the application to control. Some applications
will want to allow the user to specify exactly which ENGINE they want used
if any is to be used at all. Others may prefer to load all support and have
OpenSSL automatically use at run-time any ENGINE that is able to
-successfully initialise - ie. to assume that this corresponds to
+successfully initialise - i.e. to assume that this corresponds to
acceleration hardware attached to the machine or some such thing. There are
probably numerous other ways in which applications may prefer to handle
things, so we will simply illustrate the consequences as they apply to a
@@ -417,7 +417,7 @@ so that it can be initialised for use. This could include the path to any
driver or config files it needs to load, required network addresses,
smart-card identifiers, passwords to initialise protected devices,
logging information, etc etc. This class of commands typically needs to be
-passed to an ENGINE B<before> attempting to initialise it, ie. before
+passed to an ENGINE B<before> attempting to initialise it, i.e. before
calling ENGINE_init(). The other class of commands consist of settings or
operations that tweak certain behaviour or cause certain operations to take
place, and these commands may work either before or after ENGINE_init(), or
@@ -477,7 +477,7 @@ boolean success or failure.
}
Note that ENGINE_ctrl_cmd_string() accepts a boolean argument that can
-relax the semantics of the function - if set non-zero it will only return
+relax the semantics of the function - if set nonzero it will only return
failure if the ENGINE supported the given command name but failed while
executing it, if the ENGINE doesn't support the command name it will simply
return success without doing anything. In this case we assume the user is
@@ -490,7 +490,7 @@ It is possible to discover at run-time the names, numerical-ids, descriptions
and input parameters of the control commands supported by an ENGINE using a
structural reference. Note that some control commands are defined by OpenSSL
itself and it will intercept and handle these control commands on behalf of the
-ENGINE, ie. the ENGINE's ctrl() handler is not used for the control command.
+ENGINE, i.e. the ENGINE's ctrl() handler is not used for the control command.
openssl/engine.h defines an index, ENGINE_CMD_BASE, that all control commands
implemented by ENGINEs should be numbered from. Any command value lower than
this symbol is considered a "generic" command is handled directly by the
@@ -556,7 +556,7 @@ by applications, administrations, users, etc. These can support arbitrary
operations via ENGINE_ctrl(), including passing to and/or from the control
commands data of any arbitrary type. These commands are supported in the
discovery mechanisms simply to allow applications to determine if an ENGINE
-supports certain specific commands it might want to use (eg. application "foo"
+supports certain specific commands it might want to use (e.g. application "foo"
might query various ENGINEs to see if they implement "FOO_GET_VENDOR_LOGO_GIF" -
and ENGINE could therefore decide whether or not to support this "foo"-specific
extension).
diff --git a/doc/man3/ERR_get_error.pod b/doc/man3/ERR_get_error.pod
index a76df03882..bfeaa3d48f 100644
--- a/doc/man3/ERR_get_error.pod
+++ b/doc/man3/ERR_get_error.pod
@@ -45,7 +45,7 @@ messages.
ERR_get_error_line(), ERR_peek_error_line() and
ERR_peek_last_error_line() are the same as the above, but they
-additionally store the file name and line number where
+additionally store the filename and line number where
the error occurred in *B<file> and *B<line>, unless these are B<NULL>.
ERR_get_error_line_data(), ERR_peek_error_line_data() and
diff --git a/doc/man3/ERR_print_errors.pod b/doc/man3/ERR_print_errors.pod
index f7e612f618..7f83c1937e 100644
--- a/doc/man3/ERR_print_errors.pod
+++ b/doc/man3/ERR_print_errors.pod
@@ -29,7 +29,7 @@ B<u> as the callback parameters.
The error strings will have the following format:
- [pid]:error:[error code]:[library name]:[function name]:[reason string]:[file name]:[line]:[optional text message]
+ [pid]:error:[error code]:[library name]:[function name]:[reason string]:[filename]:[line]:[optional text message]
I<error code> is an 8 digit hexadecimal number. I<library name>,
I<function name> and I<reason string> are ASCII text, as is I<optional
diff --git a/doc/man3/ERR_put_error.pod b/doc/man3/ERR_put_error.pod
index 4fba618db4..e63494ea59 100644
--- a/doc/man3/ERR_put_error.pod
+++ b/doc/man3/ERR_put_error.pod
@@ -39,14 +39,14 @@ descriptions. For example, the function ssl3_read_bytes() reports a
SSLerr(SSL_F_SSL3_READ_BYTES, SSL_R_SSL_HANDSHAKE_FAILURE);
-Function and reason codes should consist of upper case characters,
+Function and reason codes should consist of uppercase characters,
numbers and underscores only. The error file generation script translates
function codes into function names by looking in the header files
for an appropriate function name, if none is found it just uses
the capitalized form such as "SSL3_READ_BYTES" in the above example.
The trailing section of a reason code (after the "_R_") is translated
-into lower case and underscores changed to spaces.
+into lowercase and underscores changed to spaces.
Although a library will normally report errors using its own specific
XXXerr macro, another library's macro can be used. This is normally
diff --git a/doc/man3/EVP_DigestInit.pod b/doc/man3/EVP_DigestInit.pod
index 434e22030f..b03e52cc54 100644
--- a/doc/man3/EVP_DigestInit.pod
+++ b/doc/man3/EVP_DigestInit.pod
@@ -68,7 +68,7 @@ EVP_MD_CTX_pkey_ctx, EVP_MD_CTX_set_pkey_ctx - EVP digest routines
=head1 DESCRIPTION
-The EVP digest routines are a high level interface to message digests,
+The EVP digest routines are a high-level interface to message digests,
and should be used instead of the cipher-specific functions.
=over 4
@@ -338,7 +338,7 @@ This function has no return value.
=head1 NOTES
The B<EVP> interface to message digests should almost always be used in
-preference to the low level interfaces. This is because the code then becomes
+preference to the low-level interfaces. This is because the code then becomes
transparent to the digest used and much more flexible.
New applications should use the SHA-2 (such as L<EVP_sha256(3)>) or the SHA-3
diff --git a/doc/man3/EVP_DigestSignInit.pod b/doc/man3/EVP_DigestSignInit.pod
index 912880a5e1..4efc8a4974 100644
--- a/doc/man3/EVP_DigestSignInit.pod
+++ b/doc/man3/EVP_DigestSignInit.pod
@@ -20,7 +20,7 @@ EVP_DigestSign - EVP signing functions
=head1 DESCRIPTION
-The EVP signature routines are a high level interface to digital signatures.
+The EVP signature routines are a high-level interface to digital signatures.
EVP_DigestSignInit() sets up signing context B<ctx> to use digest B<type> from
ENGINE B<e> and private key B<pkey>. B<ctx> must be created with
@@ -110,7 +110,7 @@ The error codes can be obtained from L<ERR_get_error(3)>.
=head1 NOTES
The B<EVP> interface to digital signatures should almost always be used in
-preference to the low level interfaces. This is because the code then becomes
+preference to the low-level interfaces. This is because the code then becomes
transparent to the algorithm used and much more flexible.
EVP_DigestSign() is a one shot operation which signs a single block of data
diff --git a/doc/man3/EVP_DigestVerifyInit.pod b/doc/man3/EVP_DigestVerifyInit.pod
index 0806cd5d58..984cef4db3 100644
--- a/doc/man3/EVP_DigestVerifyInit.pod
+++ b/doc/man3/EVP_DigestVerifyInit.pod
@@ -19,7 +19,7 @@ EVP_DigestVerify - EVP signature verification functions
=head1 DESCRIPTION
-The EVP signature routines are a high level interface to digital signatures.
+The EVP signature routines are a high-level interface to digital signatures.
EVP_DigestVerifyInit() sets up verification context B<ctx> to use digest
B<type> from ENGINE B<e> and public key B<pkey>. B<ctx> must be created
@@ -62,7 +62,7 @@ The error codes can be obtained from L<ERR_get_error(3)>.
=head1 NOTES
The B<EVP> interface to digital signatures should almost always be used in
-preference to the low level interfaces. This is because the code then becomes
+preference to the low-level interfaces. This is because the code then becomes
transparent to the algorithm used and much more flexible.
EVP_DigestVerify() is a one shot operation which verifies a single block of
diff --git a/doc/man3/EVP_EncodeInit.pod b/doc/man3/EVP_EncodeInit.pod
index 2589254735..811110f1bf 100644
--- a/doc/man3/EVP_EncodeInit.pod
+++ b/doc/man3/EVP_EncodeInit.pod
@@ -29,7 +29,7 @@ EVP_DecodeBlock - EVP base 64 encode/decode routines
=head1 DESCRIPTION
-The EVP encode routines provide a high level interface to base 64 encoding and
+The EVP encode routines provide a high-level interface to base 64 encoding and
decoding. Base 64 encoding converts binary data into a printable form that uses
the characters A-Z, a-z, 0-9, "+" and "/" to represent the data. For every 3
bytes of binary data provided 4 bytes of base 64 encoded data will be produced
diff --git a/doc/man3/EVP_EncryptInit.pod b/doc/man3/EVP_EncryptInit.pod
index 23ddf9153d..17d17d5ca0 100644
--- a/doc/man3/EVP_EncryptInit.pod
+++ b/doc/man3/EVP_EncryptInit.pod
@@ -120,7 +120,7 @@ EVP_enc_null
=head1 DESCRIPTION
-The EVP cipher routines are a high level interface to certain
+The EVP cipher routines are a high-level interface to certain
symmetric ciphers.
EVP_CIPHER_CTX_new() creates a cipher context.
@@ -427,8 +427,8 @@ Sets the CCM B<L> value. If not set a default is used (8 for AES).
=item EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_AEAD_SET_IVLEN, ivlen, NULL)
-Sets the CCM nonce (IV) length. This call can only be made before specifying an
-nonce value. The nonce length is given by B<15 - L> so it is 7 by default for
+Sets the CCM nonce (IV) length. This call can only be made before specifying
+a nonce value. The nonce length is given by B<15 - L> so it is 7 by default for
AES.
=back
@@ -468,10 +468,10 @@ This call is only valid when decrypting data.
=head1 NOTES
Where possible the B<EVP> interface to symmetric ciphers should be used in
-preference to the low level interfaces. This is because the code then becomes
+preference to the low-level interfaces. This is because the code then becomes
transparent to the cipher used and much more flexible. Additionally, the
B<EVP> interface will ensure the use of platform specific cryptographic
-acceleration such as AES-NI (the low level interfaces do not provide the
+acceleration such as AES-NI (the low-level interfaces do not provide the
guarantee).
PKCS padding works by adding B<n> padding bytes of value B<n> to make the total
diff --git a/doc/man3/EVP_OpenInit.pod b/doc/man3/EVP_OpenInit.pod
index 61b4307bca..2f4693710a 100644
--- a/doc/man3/EVP_OpenInit.pod
+++ b/doc/man3/EVP_OpenInit.pod
@@ -16,7 +16,7 @@ EVP_OpenInit, EVP_OpenUpdate, EVP_OpenFinal - EVP envelope decryption
=head1 DESCRIPTION
-The EVP envelope routines are a high level interface to envelope
+The EVP envelope routines are a high-level interface to envelope
decryption. They decrypt a public key encrypted symmetric key and
then decrypt data using it.
diff --git a/doc/man3/EVP_PKEY_CTX_ctrl.pod b/doc/man3/EVP_PKEY_CTX_ctrl.pod
index 16d8462a42..9215e943cf 100644
--- a/doc/man3/EVP_PKEY_CTX_ctrl.pod
+++ b/doc/man3/EVP_PKEY_CTX_ctrl.pod
@@ -290,7 +290,7 @@ parameter generation. Use 0 for PKCS#3 DH and 1 for X9.42 DH.
The default is 0.
The EVP_PKEY_CTX_set_dh_pad() macro sets the DH padding mode. If B<pad> is
-1 the shared secret is padded with zeroes up to the size of the DH prime B<p>.
+1 the shared secret is padded with zeros up to the size of the DH prime B<p>.
If B<pad> is zero (the default) then no padding is performed.
EVP_PKEY_CTX_set_dh_nid() sets the DH parameters to values corresponding to
diff --git a/doc/man3/EVP_PKEY_CTX_new.pod b/doc/man3/EVP_PKEY_CTX_new.pod
index f01fc97522..9abf3e1cd4 100644
--- a/doc/man3/EVP_PKEY_CTX_new.pod
+++ b/doc/man3/EVP_PKEY_CTX_new.pod
@@ -31,7 +31,7 @@ If B<ctx> is NULL, nothing is done.
=head1 NOTES
The B<EVP_PKEY_CTX> structure is an opaque public key algorithm context used
-by the OpenSSL high level public key API. Contexts B<MUST NOT> be shared between
+by the OpenSSL high-level public key API. Contexts B<MUST NOT> be shared between
threads: that is it is not permissible to use the same context simultaneously
in two threads.
diff --git a/doc/man3/EVP_PKEY_keygen.pod b/doc/man3/EVP_PKEY_keygen.pod
index 83cebe7ce2..3850fb31e5 100644
--- a/doc/man3/EVP_PKEY_keygen.pod
+++ b/doc/man3/EVP_PKEY_keygen.pod
@@ -51,7 +51,7 @@ generation callback.
The function EVP_PKEY_CTX_get_keygen_info() returns parameters associated
with the generation operation. If B<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
B<idx> should only be called within the generation callback.
If the callback returns 0 then the key generation operation is aborted and an
diff --git a/doc/man3/EVP_SealInit.pod b/doc/man3/EVP_SealInit.pod
index 2c2c89a71b..eeb6d64b02 100644
--- a/doc/man3/EVP_SealInit.pod
+++ b/doc/man3/EVP_SealInit.pod
@@ -17,7 +17,7 @@ EVP_SealInit, EVP_SealUpdate, EVP_SealFinal - EVP envelope encryption
=head1 DESCRIPTION
-The EVP envelope routines are a high level interface to envelope
+The EVP envelope routines are a high-level interface to envelope
encryption. They generate a random key and IV (if required) then
"envelope" it by using public key encryption. Data can then be
encrypted using this key.
diff --git a/doc/man3/EVP_SignInit.pod b/doc/man3/EVP_SignInit.pod
index 22ce747d33..299c5cf312 100644
--- a/doc/man3/EVP_SignInit.pod
+++ b/doc/man3/EVP_SignInit.pod
@@ -17,7 +17,7 @@ EVP_SignInit, EVP_SignInit_ex, EVP_SignUpdate, EVP_SignFinal
=head1 DESCRIPTION
-The EVP signature routines are a high level interface to digital
+The EVP signature routines are a high-level interface to digital
signatures.
EVP_SignInit_ex() sets up signing context I<ctx> to use digest
@@ -48,7 +48,7 @@ The error codes can be obtained by L<ERR_get_error(3)>.
=head1 NOTES
The B<EVP> interface to digital signatures should almost always be used in
-preference to the low level interfaces. This is because the code then becomes
+preference to the low-level interfaces. This is because the code then becomes
transparent to the algorithm used and much more flexible.
When signing with DSA private keys the random number generator must be seeded.
diff --git a/doc/man3/EVP_VerifyInit.pod b/doc/man3/EVP_VerifyInit.pod
index 647c99bceb..929b4c6e2c 100644
--- a/doc/man3/EVP_VerifyInit.pod
+++ b/doc/man3/EVP_VerifyInit.pod
@@ -19,7 +19,7 @@ EVP_VerifyInit, EVP_VerifyUpdate, EVP_VerifyFinal
=head1 DESCRIPTION
-The EVP signature verification routines are a high level interface to digital
+The EVP signature verification routines are a high-level interface to digital
signatures.
EVP_VerifyInit_ex() sets up verification context B<ctx> to use digest
@@ -49,7 +49,7 @@ The error codes can be obtained by L<ERR_get_error(3)>.
=head1 NOTES
The B<EVP> interface to digital signatures should almost always be used in
-preference to the low level interfaces. This is because the code then becomes
+preference to the low-level interfaces. This is because the code then becomes
transparent to the algorithm used and much more flexible.
The call to EVP_VerifyFinal() internally finalizes a copy of the digest context.
diff --git a/doc/man3/HMAC.pod b/doc/man3/HMAC.pod
index cc0d470907..97089c7389 100644
--- a/doc/man3/HMAC.pod
+++ b/doc/man3/HMAC.pod
@@ -69,7 +69,7 @@ EVP_shake256().
HMAC_CTX_new() creates a new HMAC_CTX in heap memory.
-HMAC_CTX_reset() zeroes an existing B<HMAC_CTX> and associated
+HMAC_CTX_reset() zeros an existing B<HMAC_CTX> and associated
resources, making it suitable for new computations as if it was newly
created with HMAC_CTX_new().
diff --git a/doc/man3/OCSP_cert_to_id.pod b/doc/man3/OCSP_cert_to_id.pod
index c8d39c1913..cc03452a9f 100644
--- a/doc/man3/OCSP_cert_to_id.pod
+++ b/doc/man3/OCSP_cert_to_id.pod
@@ -52,7 +52,7 @@ corresponding parameter can be set to B<NULL>.
OCSP_cert_to_id() and OCSP_cert_id_new() return either a pointer to a valid
B<OCSP_CERTID> structure or B<NULL> if an error occurred.
-OCSP_id_cmp() and OCSP_id_issuer_cmp() returns zero for a match and non-zero
+OCSP_id_cmp() and OCSP_id_issuer_cmp() returns zero for a match and nonzero
otherwise.
OCSP_CERTID_free() does not return a value.
diff --git a/doc/man3/OCSP_request_add1_nonce.pod b/doc/man3/OCSP_request_add1_nonce.pod
index 81bf645108..777d876d04 100644
--- a/doc/man3/OCSP_request_add1_nonce.pod
+++ b/doc/man3/OCSP_request_add1_nonce.pod
@@ -57,7 +57,7 @@ performance reasons. As a result they do not support nonces.
The return values of OCSP_check_nonce() can be checked to cover each case. A
positive return value effectively indicates success: nonces are both present
-and match, both absent or present in the response only. A non-zero return
+and match, both absent or present in the response only. A nonzero return
additionally covers the case where the nonce is present in the request only:
this will happen if the responder doesn't support nonces. A zero return value
indicates present and mismatched nonces: this should be treated as an error
diff --git a/doc/man3/OCSP_resp_find_status.pod b/doc/man3/OCSP_resp_find_status.pod
index 35f7d35e99..3c8ed39e74 100644
--- a/doc/man3/OCSP_resp_find_status.pod
+++ b/doc/man3/OCSP_resp_find_status.pod
@@ -112,7 +112,7 @@ no freeing of the results is necessary.
OCSP_check_validity() checks the validity of B<thisupd> and B<nextupd> values
which will be typically obtained from OCSP_resp_find_status() or
-OCSP_single_get0_status(). If B<sec> is non-zero it indicates how many seconds
+OCSP_single_get0_status(). If B<sec> is nonzero it indicates how many seconds
leeway should be allowed in the check. If B<maxsec> is positive it indicates
the maximum age of B<thisupd> in seconds.
@@ -167,7 +167,7 @@ can then take appropriate action based on the status of the certificate.
An OCSP response for a certificate contains B<thisUpdate> and B<nextUpdate>
fields. Normally the current time should be between these two values. To
-account for clock skew the B<maxsec> field can be set to non-zero in
+account for clock skew the B<maxsec> field can be set to nonzero in
OCSP_check_validity(). Some responders do not set the B<nextUpdate> field, this
would otherwise mean an ancient response would be considered valid: the
B<maxsec> parameter to OCSP_check_validity() can be used to limit the permitted
diff --git a/doc/man3/OCSP_sendreq_new.pod b/doc/man3/OCSP_sendreq_new.pod
index a129a16bf2..16d5a21dfc 100644
--- a/doc/man3/OCSP_sendreq_new.pod
+++ b/doc/man3/OCSP_sendreq_new.pod
@@ -34,7 +34,7 @@ response header maximum line length of B<maxline>. If B<maxline> is zero a
default value of 4k is used. The OCSP request B<req> may be set to B<NULL>
and provided later if required.
-OCSP_sendreq_nbio() performs non-blocking I/O on the OCSP request context
+OCSP_sendreq_nbio() performs nonblocking I/O on the OCSP request context
B<rctx>. When the operation is complete it returns the response in B<*presp>.
OCSP_REQ_CTX_free() frees up the OCSP context B<rctx>.
@@ -96,7 +96,7 @@ corresponding BIO can be examined to determine which operation (read or
write) should be retried and appropriate action taken (for example a select()
call on the underlying socket).
-OCSP_sendreq_bio() does not support retries and so cannot handle non-blocking
+OCSP_sendreq_bio() does not support retries and so cannot handle nonblocking
I/O efficiently. It is retained for compatibility and its use in new
applications is not recommended.
diff --git a/doc/man3/OPENSSL_LH_COMPFUNC.pod b/doc/man3/OPENSSL_LH_COMPFUNC.pod
index a312ef7342..ed884ddbd8 100644
--- a/doc/man3/OPENSSL_LH_COMPFUNC.pod
+++ b/doc/man3/OPENSSL_LH_COMPFUNC.pod
@@ -51,7 +51,7 @@ an unsigned long hash value for its key field. The hash value is
normally truncated to a power of 2, so make sure that your hash
function returns well mixed low order bits. The B<compare> callback
takes two arguments (pointers to two hash table entries), and returns
-0 if their keys are equal, non-zero otherwise.
+0 if their keys are equal, nonzero otherwise.
If your hash table
will contain items of some particular type and the B<hash> and
@@ -196,7 +196,7 @@ all such parameters as constant.
As an example, a hash table may be maintained by code that, for
reasons of encapsulation, has only "const" access to the data being
-indexed in the hash table (ie. it is returned as "const" from
+indexed in the hash table (i.e. it is returned as "const" from
elsewhere in their code) - in this case the LHASH prototypes are
appropriate as-is. Conversely, if the caller is responsible for the
life-time of the data in question, then they may well wish to make
diff --git a/doc/man3/OPENSSL_config.pod b/doc/man3/OPENSSL_config.pod
index 6294ee1d1b..4e4eef7757 100644
--- a/doc/man3/OPENSSL_config.pod
+++ b/doc/man3/OPENSSL_config.pod
@@ -41,7 +41,7 @@ initialization (that is before starting any threads).
There are several reasons why calling the OpenSSL configuration routines is
advisable. For example, to load dynamic ENGINEs from shared libraries (DSOs).
-However very few applications currently support the control interface and so
+However, very few applications currently support the control interface and so
very few can load and use dynamic ENGINEs. Equally in future more sophisticated
ENGINEs will require certain control operations to customize them. If an
application calls OPENSSL_config() it doesn't need to know or care about
diff --git a/doc/man3/OPENSSL_ia32cap.pod b/doc/man3/OPENSSL_ia32cap.pod
index 08a181168f..c367f70789 100644
--- a/doc/man3/OPENSSL_ia32cap.pod
+++ b/doc/man3/OPENSSL_ia32cap.pod
@@ -102,7 +102,7 @@ and RORX;
=item bit #64+19 denoting availability of ADCX and ADOX instructions;
=item bit #64+21 denoting availability of VPMADD52[LH]UQ instructions,
-a.k.a. AVX512IFMA extension;
+aka AVX512IFMA extension;
=item bit #64+29 denoting availability of SHA extension;
diff --git a/doc/man3/OPENSSL_init_crypto.pod b/doc/man3/OPENSSL_init_crypto.pod
index c7823e32d6..fe41086cfd 100644
--- a/doc/man3/OPENSSL_init_crypto.pod
+++ b/doc/man3/OPENSSL_init_crypto.pod
@@ -39,13 +39,13 @@ needs so no explicit initialisation is required. Similarly it will also
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.
@@ -216,10 +216,10 @@ The filename, application name, and flags can be customized by providing a
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)>.
diff --git a/doc/man3/OPENSSL_init_ssl.pod b/doc/man3/OPENSSL_init_ssl.pod
index b963e5e7a9..56d8f8222f 100644
--- a/doc/man3/OPENSSL_init_ssl.pod
+++ b/doc/man3/OPENSSL_init_ssl.pod
@@ -23,14 +23,14 @@ needs so no explicit initialisation is required. Similarly it will also
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.
diff --git a/doc/man3/PEM_read_bio_PrivateKey.pod b/doc/man3/PEM_read_bio_PrivateKey.pod
index a8306500fb..79bff12618 100644
--- a/doc/man3/PEM_read_bio_PrivateKey.pod
+++ b/doc/man3/PEM_read_bio_PrivateKey.pod
@@ -206,7 +206,7 @@ RSA structure. The public key is encoded using a PKCS#1 RSAPublicKey
structure.
The B<RSA_PUBKEY> functions also process an RSA public key using
-an RSA structure. However the public key is encoded using a
+an RSA structure. However, the public key is encoded using a
SubjectPublicKeyInfo structure and an error occurs if the public
key is not RSA.
@@ -387,7 +387,7 @@ The pseudo code to derive the key would look similar to:
=head1 BUGS
The PEM read routines in some versions of OpenSSL will not correctly reuse
-an existing structure. Therefore the following:
+an existing structure. Therefore, the following:
PEM_read_bio_X509(bp, &x, 0, NULL);
diff --git a/doc/man3/PKCS7_verify.pod b/doc/man3/PKCS7_verify.pod
index ebcdde0795..01e8efc442 100644
--- a/doc/man3/PKCS7_verify.pod
+++ b/doc/man3/PKCS7_verify.pod
@@ -91,7 +91,7 @@ useful if one merely wishes to write the content to B<out> and its validity
is not considered important.
Chain verification should arguably be performed using the signing time rather
-than the current time. However since the signing time is supplied by the
+than the current time. However, since the signing time is supplied by the
signer it cannot be trusted without additional evidence (such as a trusted
timestamp).
diff --git a/doc/man3/RAND_DRBG_new.pod b/doc/man3/RAND_DRBG_new.pod
index 5da91be9df..4f76a2b569 100644
--- a/doc/man3/RAND_DRBG_new.pod
+++ b/doc/man3/RAND_DRBG_new.pod
@@ -56,7 +56,7 @@ its type and to instantiate it.
The optional B<flags> argument specifies a set of bit flags which can be
joined using the | operator. Currently, the only flag is
-RAND_DRBG_FLAG_CTR_NO_DF, which disables the use of a the derivation function
+RAND_DRBG_FLAG_CTR_NO_DF, which disables the use of the derivation function
ctr_df. For an explanation, see [NIST SP 800-90A Rev. 1].
If a B<parent> instance is specified then this will be used instead of
diff --git a/doc/man3/RAND_DRBG_set_callbacks.pod b/doc/man3/RAND_DRBG_set_callbacks.pod
index 55e9a8b7af..4af628daab 100644
--- a/doc/man3/RAND_DRBG_set_callbacks.pod
+++ b/doc/man3/RAND_DRBG_set_callbacks.pod
@@ -77,7 +77,7 @@ does not satisfy the conditions requested by [NIST SP 800-90C], then
it must also indicate an error by returning a buffer length of 0.
See NOTES section for more details.
-The B<cleanup_entropy>() callback is called from the B<drbg> to to clear and
+The B<cleanup_entropy>() callback is called from the B<drbg> to clear and
free the buffer allocated previously by get_entropy().
The values B<out> and B<outlen> are the random buffer's address and length,
as returned by the get_entropy() callback.
diff --git a/doc/man3/RAND_add.pod b/doc/man3/RAND_add.pod
index 4ba6ff977d..85ae64bffb 100644
--- a/doc/man3/RAND_add.pod
+++ b/doc/man3/RAND_add.pod
@@ -62,7 +62,7 @@ usage by the random seed sources. Some seed sources maintain open file
descriptors by default, which allows such sources to operate in a
chroot(2) jail without the associated device nodes being available. When
the B<keep> argument is zero, this call disables the retention of file
-descriptors. Conversely, a non-zero argument enables the retention of
+descriptors. Conversely, a nonzero argument enables the retention of
file descriptors. This function is usually called during initialization
and it takes effect immediately.
diff --git a/doc/man3/RAND_load_file.pod b/doc/man3/RAND_load_file.pod
index 24f8fdcf4f..3169c78578 100644
--- a/doc/man3/RAND_load_file.pod
+++ b/doc/man3/RAND_load_file.pod
@@ -17,7 +17,7 @@ RAND_load_file, RAND_write_file, RAND_file_name - PRNG seed file
=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
@@ -37,7 +37,7 @@ file. B<buf> points to a buffer of size B<num> in which to store the
filename.
On all systems, if the environment variable B<RANDFILE> is set, its
-value will be used as the seed file name.
+value will be used as the seed filename.
Otherwise, the file is called C<.rnd>, found in platform dependent locations:
=over 4
@@ -57,7 +57,7 @@ Otherwise, the file is called C<.rnd>, found in platform dependent locations:
=back
If C<$HOME> (on non-Windows and non-VMS system) is not set either, or
-B<num> is too small for the path name, an error occurs.
+B<num> is too small for the pathname, an error occurs.
=head1 RETURN VALUES
diff --git a/doc/man3/RSA_blinding_on.pod b/doc/man3/RSA_blinding_on.pod
index 5db127f16e..3d7c0e12c6 100644
--- a/doc/man3/RSA_blinding_on.pod
+++ b/doc/man3/RSA_blinding_on.pod
@@ -19,7 +19,7 @@ measure the time of RSA decryption or signature operations, blinding
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
diff --git a/doc/man3/RSA_private_encrypt.pod b/doc/man3/RSA_private_encrypt.pod
index 060a9000f8..6e6d9a3d07 100644
--- a/doc/man3/RSA_private_encrypt.pod
+++ b/doc/man3/RSA_private_encrypt.pod
@@ -2,7 +2,7 @@
=head1 NAME
-RSA_private_encrypt, RSA_public_decrypt - low level signature operations
+RSA_private_encrypt, RSA_public_decrypt - low-level signature operations
=head1 SYNOPSIS
@@ -16,7 +16,7 @@ RSA_private_encrypt, RSA_public_decrypt - low level signature operations
=head1 DESCRIPTION
-These functions handle RSA signatures at a low level.
+These functions handle RSA signatures at a low-level.
RSA_private_encrypt() signs the B<flen> bytes at B<from> (usually a
message digest with an algorithm identifier) using the private key
diff --git a/doc/man3/RSA_set_method.pod b/doc/man3/RSA_set_method.pod
index 4bb63962cf..d486ffcdd9 100644
--- a/doc/man3/RSA_set_method.pod
+++ b/doc/man3/RSA_set_method.pod
@@ -51,7 +51,7 @@ RSA_set_method() selects B<meth> to perform all operations using the key
B<rsa>. This will replace the RSA_METHOD used by the RSA key and if the
previous method was supplied by an ENGINE, the handle to that ENGINE will
be released during the change. It is possible to have RSA keys that only
-work with certain RSA_METHOD implementations (eg. from an ENGINE module
+work with certain RSA_METHOD implementations (e.g. from an ENGINE module
that supports embedded hardware-protected keys), and in such cases
attempting to change the RSA_METHOD for the key can have unexpected
results.
diff --git a/doc/man3/SSL_CONF_cmd.pod b/doc/man3/SSL_CONF_cmd.pod
index c5fed8e1e0..1f9e06a4ba 100644
--- a/doc/man3/SSL_CONF_cmd.pod
+++ b/doc/man3/SSL_CONF_cmd.pod
@@ -79,7 +79,7 @@ B<ClientHello>.
The B<value> argument is a colon separated list of groups. The group can be
either the B<NIST> name (e.g. B<P-256>), some other commonly used name where
-applicable (e.g. B<X25519>) or an OpenSSL OID name (e.g B<prime256v1>). Group
+applicable (e.g. B<X25519>) or an OpenSSL OID name (e.g. B<prime256v1>). Group
names are case sensitive. The list should be in order of preference with the
most preferred group first.
@@ -95,7 +95,7 @@ servers
The B<value> argument is a curve name or the special value B<auto> which
picks an appropriate curve based on client and server preferences. The curve
can be either the B<NIST> name (e.g. B<P-256>) or an OpenSSL OID name
-(e.g B<prime256v1>). Curve names are case sensitive.
+(e.g. B<prime256v1>). Curve names are case sensitive.
=item B<-cipher>
@@ -359,7 +359,7 @@ B<ClientHello>.
The B<value> argument is a colon separated list of groups. The group can be
either the B<NIST> name (e.g. B<P-256>), some other commonly used name where
-applicable (e.g. B<X25519>) or an OpenSSL OID name (e.g B<prime256v1>). Group
+applicable (e.g. B<X25519>) or an OpenSSL OID name (e.g. B<prime256v1>). Group
names are case sensitive. The list should be in order of preference with the
most preferred group first.
@@ -548,7 +548,7 @@ The value is a string without any specific structure.
=item B<SSL_CONF_TYPE_FILE>
-The value is a file name.
+The value is a filename.
=item B<SSL_CONF_TYPE_DIR>
diff --git a/doc/man3/SSL_CTX_dane_enable.pod b/doc/man3/SSL_CTX_dane_enable.pod
index 7168bd64fd..e504f95a7a 100644
--- a/doc/man3/SSL_CTX_dane_enable.pod
+++ b/doc/man3/SSL_CTX_dane_enable.pod
@@ -122,7 +122,7 @@ SSL_get0_dane_tlsa() can be used to retrieve the fields of the TLSA record that
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,
@@ -136,7 +136,7 @@ SSL_CTX_dane_set_flags() and SSL_dane_set_flags() can be used to enable
optional DANE verification features.
SSL_CTX_dane_clear_flags() and SSL_dane_clear_flags() can be used to disable
the same features.
-The B<flags> argument is a bitmask of the features to enable or disable.
+The B<flags> argument is a bit mask of the features to enable or disable.
The B<flags> set for an B<SSL_CTX> context are copied to each B<SSL> handle
associated with that context at the time the handle is created.
Subsequent changes in the context's B<flags> have no effect on the B<flags> set
@@ -173,7 +173,7 @@ certificate or a public key that fails to parse.
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.
diff --git a/doc/man3/SSL_CTX_set_alpn_select_cb.pod b/doc/man3/SSL_CTX_set_alpn_select_cb.pod
index 56c86097b6..62ad20f0ab 100644
--- a/doc/man3/SSL_CTX_set_alpn_select_cb.pod
+++ b/doc/man3/SSL_CTX_set_alpn_select_cb.pod
@@ -114,7 +114,7 @@ provided by the callback.
=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.
diff --git a/doc/man3/SSL_CTX_set_generate_session_id.pod b/doc/man3/SSL_CTX_set_generate_session_id.pod
index 1735c6271b..8d9d1598ab 100644
--- a/doc/man3/SSL_CTX_set_generate_session_id.pod
+++ b/doc/man3/SSL_CTX_set_generate_session_id.pod
@@ -108,8 +108,8 @@ server id given, and will fill the rest with pseudo random bytes:
/*
* Prefix the session_id with the required prefix. NB: If our
* prefix is too long, clip it - but there will be worse effects
- * anyway, eg. the server could only possibly create 1 session
- * ID (ie. the prefix!) so all future session negotiations will
+ * anyway, e.g. the server could only possibly create 1 session
+ * ID (i.e. the prefix!) so all future session negotiations will
* fail due to conflicts.
*/
memcpy(id, session_id_prefix, strlen(session_id_prefix) < *id_len ?
diff --git a/doc/man3/SSL_CTX_set_info_callback.pod b/doc/man3/SSL_CTX_set_info_callback.pod
index 01b03f9a59..a957bf0890 100644
--- a/doc/man3/SSL_CTX_set_info_callback.pod
+++ b/doc/man3/SSL_CTX_set_info_callback.pod
@@ -50,7 +50,7 @@ the callback function was called. If B<ret> is 0, an error condition occurred.
If an alert is handled, SSL_CB_ALERT is set and B<ret> specifies the alert
information.
-B<where> is a bitmask made up of the following bits:
+B<where> is a bit mask made up of the following bits:
=over 4
@@ -64,7 +64,7 @@ per state in some situations.
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
diff --git a/doc/man3/SSL_CTX_set_max_cert_list.pod b/doc/man3/SSL_CTX_set_max_cert_list.pod
index 01936c5847..893b35d063 100644
--- a/doc/man3/SSL_CTX_set_max_cert_list.pod
+++ b/doc/man3/SSL_CTX_set_max_cert_list.pod
@@ -39,7 +39,7 @@ received from a faulty or malicious peer, a maximum size for the certificate
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).
diff --git a/doc/man3/SSL_CTX_set_mode.pod b/doc/man3/SSL_CTX_set_mode.pod
index 387d1ec1ef..a91648ab22 100644
--- a/doc/man3/SSL_CTX_set_mode.pod
+++ b/doc/man3/SSL_CTX_set_mode.pod
@@ -18,13 +18,13 @@ SSL_CTX_set_mode, SSL_CTX_clear_mode, SSL_set_mode, SSL_clear_mode, SSL_CTX_get_
=head1 DESCRIPTION
-SSL_CTX_set_mode() adds the mode set via bitmask in B<mode> to B<ctx>.
+SSL_CTX_set_mode() adds the mode set via bit mask in B<mode> to B<ctx>.
Options already set before are not cleared.
-SSL_CTX_clear_mode() removes the mode set via bitmask in B<mode> from B<ctx>.
+SSL_CTX_clear_mode() removes the mode set via bit mask in B<mode> from B<ctx>.
-SSL_set_mode() adds the mode set via bitmask in B<mode> to B<ssl>.
+SSL_set_mode() adds the mode set via bit mask in B<mode> to B<ssl>.
Options already set before are not cleared.
-SSL_clear_mode() removes the mode set via bitmask in B<mode> from B<ssl>.
+SSL_clear_mode() removes the mode set via bit mask in B<mode> from B<ssl>.
SSL_CTX_get_mode() returns the mode set for B<ctx>.
@@ -50,8 +50,8 @@ the behaviour of write().
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
@@ -64,9 +64,9 @@ If such a non-application data record was processed, the flag
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.
@@ -121,10 +121,10 @@ default since 1.1.1.
=head1 RETURN VALUES
-SSL_CTX_set_mode() and SSL_set_mode() return the new mode bitmask
+SSL_CTX_set_mode() and SSL_set_mode() return the new mode bit mask
after adding B<mode>.
-SSL_CTX_get_mode() and SSL_get_mode() return the current bitmask.
+SSL_CTX_get_mode() and SSL_get_mode() return the current bit mask.
=head1 SEE ALSO
diff --git a/doc/man3/SSL_CTX_set_options.pod b/doc/man3/SSL_CTX_set_options.pod
index 2d840b62cb..245a7b2b9e 100644
--- a/doc/man3/SSL_CTX_set_options.pod
+++ b/doc/man3/SSL_CTX_set_options.pod
@@ -23,16 +23,16 @@ SSL_get_secure_renegotiation_support - manipulate SSL options
=head1 DESCRIPTION
-SSL_CTX_set_options() adds the options set via bitmask in B<options> to B<ctx>.
+SSL_CTX_set_options() adds the options set via bit mask in B<options> to B<ctx>.
Options already set before are not cleared!
-SSL_set_options() adds the options set via bitmask in B<options> to B<ssl>.
+SSL_set_options() adds the options set via bit mask in B<options> to B<ssl>.
Options already set before are not cleared!
-SSL_CTX_clear_options() clears the options set via bitmask in B<options>
+SSL_CTX_clear_options() clears the options set via bit mask in B<options>
to B<ctx>.
-SSL_clear_options() clears the options set via bitmask in B<options> to B<ssl>.
+SSL_clear_options() clears the options set via bit mask in B<options> to B<ssl>.
SSL_CTX_get_options() returns the options set for B<ctx>.
@@ -45,7 +45,7 @@ Note, this is implemented via a macro.
=head1 NOTES
The behaviour of the SSL library can be changed by setting several options.
-The options are coded as bitmasks and can be combined by a bitwise B<or>
+The options are coded as bit masks and can be combined by a bitwise B<or>
operation (|).
SSL_CTX_set_options() and SSL_set_options() affect the (external)
@@ -161,7 +161,7 @@ the session. In this way the server can operate statelessly - no session
information needs to be cached locally.
The TLSv1.3 protocol only supports tickets and does not directly support session
-ids. However OpenSSL allows two modes of ticket operation in TLSv1.3: stateful
+ids. However, OpenSSL allows two modes of ticket operation in TLSv1.3: stateful
and stateless. Stateless tickets work the same way as in TLSv1.2 and below.
Stateful tickets mimic the session id behaviour available in TLSv1.2 and below.
The session information is cached on the server and the session id is wrapped up
@@ -340,13 +340,13 @@ and renegotiation between OpenSSL and unpatched clients or servers.
=head1 RETURN VALUES
-SSL_CTX_set_options() and SSL_set_options() return the new options bitmask
+SSL_CTX_set_options() and SSL_set_options() return the new options bit mask
after adding B<options>.
-SSL_CTX_clear_options() and SSL_clear_options() return the new options bitmask
+SSL_CTX_clear_options() and SSL_clear_options() return the new options bit mask
after clearing B<options>.
-SSL_CTX_get_options() and SSL_get_options() return the current bitmask.
+SSL_CTX_get_options() and SSL_get_options() return the current bit mask.
SSL_get_secure_renegotiation_support() returns 1 is the peer supports
secure renegotiation and 0 if it does not.
diff --git a/doc/man3/SSL_CTX_set_psk_client_callback.pod b/doc/man3/SSL_CTX_set_psk_client_callback.pod
index 293ddcbead..d24e5411af 100644
--- a/doc/man3/SSL_CTX_set_psk_client_callback.pod
+++ b/doc/man3/SSL_CTX_set_psk_client_callback.pod
@@ -135,7 +135,7 @@ A connection established via a TLSv1.3 PSK will appear as if session resumption
has occurred so that L<SSL_session_reused(3)> will return true.
There are no known security issues with sharing the same PSK between TLSv1.2 (or
-below) and TLSv1.3. However the RFC has this note of caution:
+below) and TLSv1.3. However, the RFC has this note of caution:
"While there is no known way in which the same PSK might produce related output
in both versions, only limited analysis has been done. Implementations can
diff --git a/doc/man3/SSL_CTX_set_read_ahead.pod b/doc/man3/SSL_CTX_set_read_ahead.pod
index ff037d938d..a7d1662edc 100644
--- a/doc/man3/SSL_CTX_set_read_ahead.pod
+++ b/doc/man3/SSL_CTX_set_read_ahead.pod
@@ -21,7 +21,7 @@ SSL_CTX_get_default_read_ahead
=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
diff --git a/doc/man3/SSL_CTX_set_session_cache_mode.pod b/doc/man3/SSL_CTX_set_session_cache_mode.pod
index 18c9783fe0..fd863627e1 100644
--- a/doc/man3/SSL_CTX_set_session_cache_mode.pod
+++ b/doc/man3/SSL_CTX_set_session_cache_mode.pod
@@ -96,7 +96,7 @@ session caching (callback) that is configured for the SSL_CTX. This flag will
prevent sessions being stored in the internal cache (though the application can
add them manually using L<SSL_CTX_add_session(3)>). Note:
in any SSL/TLS servers where external caching is configured, any successful
-session lookups in the external cache (ie. for session-resume requests) would
+session lookups in the external cache (i.e. for session-resume requests) would
normally be copied into the local cache before processing continues - this flag
prevents these additions to the internal cache as well.
diff --git a/doc/man3/SSL_CTX_set_session_id_context.pod b/doc/man3/SSL_CTX_set_session_id_context.pod
index 4036d3c7b3..93382d73a1 100644
--- a/doc/man3/SSL_CTX_set_session_id_context.pod
+++ b/doc/man3/SSL_CTX_set_session_id_context.pod
@@ -26,7 +26,7 @@ B<sid_ctx_len> within which a session can be reused for the B<ssl> object.
Sessions are generated within a certain context. When exporting/importing
sessions with B<i2d_SSL_SESSION>/B<d2i_SSL_SESSION> it would be possible,
to re-import a session generated from another context (e.g. another
-application), which might lead to malfunctions. Therefore each application
+application), which might lead to malfunctions. Therefore, each application
must set its own session id context B<sid_ctx> which is used to distinguish
the contexts and is stored in exported sessions. The B<sid_ctx> can be
any kind of binary data with a given length, it is therefore possible
diff --git a/doc/man3/SSL_CTX_set_session_ticket_cb.pod b/doc/man3/SSL_CTX_set_session_ticket_cb.pod
index 99d2f29ac6..19765d2fd4 100644
--- a/doc/man3/SSL_CTX_set_session_ticket_cb.pod
+++ b/doc/man3/SSL_CTX_set_session_ticket_cb.pod
@@ -107,7 +107,7 @@ The return value can be any of these values:
The handshake should be aborted, either because of an error or because of some
policy. Note that in TLSv1.3 a client may send more than one ticket in a single
-handshake. Therefore just because one ticket is unacceptable it does not mean
+handshake. Therefore, just because one ticket is unacceptable it does not mean
that all of them are. For this reason this option should be used with caution.
=item SSL_TICKET_RETURN_IGNORE
diff --git a/doc/man3/SSL_CTX_set_split_send_fragment.pod b/doc/man3/SSL_CTX_set_split_send_fragment.pod
index d63ca4157e..0853d49475 100644
--- a/doc/man3/SSL_CTX_set_split_send_fragment.pod
+++ b/doc/man3/SSL_CTX_set_split_send_fragment.pod
@@ -41,7 +41,7 @@ capability is known as "pipelining" within OpenSSL.
In order to benefit from the pipelining capability. You need to have an engine
that provides ciphers that support this. The OpenSSL "dasync" engine provides
-AES128-SHA based ciphers that have this capability. However these are for
+AES128-SHA based ciphers that have this capability. However, these are for
development and test purposes only.
SSL_CTX_set_max_send_fragment() and SSL_set_max_send_fragment() set the
diff --git a/doc/man3/SSL_CTX_set_tlsext_servername_callback.pod b/doc/man3/SSL_CTX_set_tlsext_servername_callback.pod
index 160a7343c3..0c21cfdb6b 100644
--- a/doc/man3/SSL_CTX_set_tlsext_servername_callback.pod
+++ b/doc/man3/SSL_CTX_set_tlsext_servername_callback.pod
@@ -51,7 +51,7 @@ value is initialised to SSL_AD_UNRECOGNIZED_NAME.
=item SSL_TLSEXT_ERR_ALERT_WARNING
If this value is returned then the servername is not accepted by the server.
-However the handshake will continue and send a warning alert instead. The value
+However, the handshake will continue and send a warning alert instead. The value
of the alert should be stored in the location pointed to by the B<al> parameter
as for SSL_TLSEXT_ERR_ALERT_FATAL above. Note that TLSv1.3 does not support
warning alerts, so if TLSv1.3 has been negotiated then this return value is
diff --git a/doc/man3/SSL_CTX_use_psk_identity_hint.pod b/doc/man3/SSL_CTX_use_psk_identity_hint.pod
index 6403da3d6b..42acd7fc92 100644
--- a/doc/man3/SSL_CTX_use_psk_identity_hint.pod
+++ b/doc/man3/SSL_CTX_use_psk_identity_hint.pod
@@ -128,7 +128,7 @@ failure. In the event of failure the connection setup fails.
=head1 NOTES
There are no known security issues with sharing the same PSK between TLSv1.2 (or
-below) and TLSv1.3. However the RFC has this note of caution:
+below) and TLSv1.3. However, the RFC has this note of caution:
"While there is no known way in which the same PSK might produce related output
in both versions, only limited analysis has been done. Implementations can
diff --git a/doc/man3/SSL_accept.pod b/doc/man3/SSL_accept.pod
index b1595f7acf..81c9dbea57 100644
--- a/doc/man3/SSL_accept.pod
+++ b/doc/man3/SSL_accept.pod
@@ -23,14 +23,14 @@ The behaviour of SSL_accept() depends on the underlying BIO.
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.
@@ -57,7 +57,7 @@ established.
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
diff --git a/doc/man3/SSL_alloc_buffers.pod b/doc/man3/SSL_alloc_buffers.pod
index 94bd05840c..8a447d5a58 100644
--- a/doc/man3/SSL_alloc_buffers.pod
+++ b/doc/man3/SSL_alloc_buffers.pod
@@ -22,7 +22,7 @@ control when buffers are freed and allocated.
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.
diff --git a/doc/man3/SSL_connect.pod b/doc/man3/SSL_connect.pod
index f7d9e57db6..0e6b625358 100644
--- a/doc/man3/SSL_connect.pod
+++ b/doc/man3/SSL_connect.pod
@@ -23,14 +23,14 @@ The behaviour of SSL_connect() depends on the underlying BIO.
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.
@@ -72,7 +72,7 @@ established.
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
diff --git a/doc/man3/SSL_do_handshake.pod b/doc/man3/SSL_do_handshake.pod
index 8852f9d3e3..fa133d76a8 100644
--- a/doc/man3/SSL_do_handshake.pod
+++ b/doc/man3/SSL_do_handshake.pod
@@ -25,13 +25,13 @@ The behaviour of SSL_do_handshake() depends on the underlying BIO.
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.
@@ -58,7 +58,7 @@ established.
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
diff --git a/doc/man3/SSL_get_all_async_fds.pod b/doc/man3/SSL_get_all_async_fds.pod
index 5b17f091e3..35ae178f3a 100644
--- a/doc/man3/SSL_get_all_async_fds.pod
+++ b/doc/man3/SSL_get_all_async_fds.pod
@@ -32,7 +32,7 @@ appearing as "read ready" on the file descriptor (no actual data should be read
from the file descriptor). This function should only be called if the SSL object
is currently waiting for asynchronous work to complete (i.e.
SSL_ERROR_WANT_ASYNC has been received - see L<SSL_get_error(3)>). Typically the
-list will only contain one file descriptor. However if multiple asynchronous
+list will only contain one file descriptor. However, if multiple asynchronous
capable engines are in use then more than one is possible. The number of file
descriptors returned is stored in B<*numfds> and the file descriptors themselves
are in B<*fds>. The B<fds> parameter may be NULL in which case no file
@@ -63,7 +63,7 @@ SSL_get_all_async_fds() and SSL_get_changed_async_fds() return 1 on success or
On Windows platforms the openssl/async.h header is dependent on some
of the types customarily made available by including windows.h. The
application developer is likely to require control over when the latter
-is included, commonly as one of the first included headers. Therefore
+is included, commonly as one of the first included headers. Therefore,
it is defined as an application developer's responsibility to include
windows.h prior to async.h.
diff --git a/doc/man3/SSL_get_error.pod b/doc/man3/SSL_get_error.pod
index 5221ccfe18..e6a1e8b63d 100644
--- a/doc/man3/SSL_get_error.pod
+++ b/doc/man3/SSL_get_error.pod
@@ -49,7 +49,7 @@ indicate that the underlying transport has been closed.
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
@@ -61,8 +61,8 @@ for a blocking B<BIO>.
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>.
-When the B<BIO> is writeable again, the same function can be called again.
+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
B<SSL_ERROR_WANT_WRITE> condition.
@@ -72,7 +72,7 @@ protocol level.
It is safe to call SSL_read() or SSL_read_ex() when more data is available
even when the call that set this error was an SSL_write() or SSL_write_ex().
-However if the call was an SSL_write() or SSL_write_ex(), it should be called
+However, if the call was an SSL_write() or SSL_write_ex(), it should be called
again to continue sending the application data.
For socket B<BIO>s (e.g. when SSL_set_fd() was used), select() or
diff --git a/doc/man3/SSL_pending.pod b/doc/man3/SSL_pending.pod
index c077a318c2..6aa59c5412 100644
--- a/doc/man3/SSL_pending.pod
+++ b/doc/man3/SSL_pending.pod
@@ -27,7 +27,7 @@ record) may have been read containing more TLS/SSL records. This also applies to
DTLS and pipelining (see L<SSL_CTX_set_split_send_fragment(3)>). These
additional bytes will be buffered by OpenSSL but will remain unprocessed until
they are needed. As these bytes are still in an unprocessed state SSL_pending()
-will ignore them. Therefore it is possible for no more bytes to be readable from
+will ignore them. Therefore, it is possible for no more bytes to be readable from
the underlying BIO (because OpenSSL has already read them) and for SSL_pending()
to return 0, even though readable application data bytes are available (because
the data is in unprocessed buffered records).
diff --git a/doc/man3/SSL_read.pod b/doc/man3/SSL_read.pod
index 4da7ad1ae1..c86fcc8e08 100644
--- a/doc/man3/SSL_read.pod
+++ b/doc/man3/SSL_read.pod
@@ -45,7 +45,7 @@ invocation of a read function.
The read functions work based on the SSL/TLS records. The data are received in
records (with a maximum record size of 16kB). Only when a record has been
completely received, can it be processed (decryption and check of integrity).
-Therefore data that was not retrieved at the last read call can still be
+Therefore, data that was not retrieved at the last read call can still be
buffered inside the SSL layer and will be retrieved on the next read
call. If B<num> is higher than the number of bytes buffered then the read
functions will return with the bytes buffered. If no more bytes are in the
@@ -72,7 +72,7 @@ not set.
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
@@ -83,7 +83,7 @@ a read function can also cause write operations.
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.
diff --git a/doc/man3/SSL_read_early_data.pod b/doc/man3/SSL_read_early_data.pod
index d3552c928b..27d210f89b 100644
--- a/doc/man3/SSL_read_early_data.pod
+++ b/doc/man3/SSL_read_early_data.pod
@@ -203,7 +203,7 @@ early data settings for the SSL_CTX and SSL objects respectively. Generally a
server application will either use both of SSL_read_early_data() and
SSL_CTX_set_max_early_data() (or SSL_set_max_early_data()), or neither of them,
since there is no practical benefit from using only one of them. If the maximum
-early data setting for a server is non-zero then replay protection is
+early data setting for a server is nonzero then replay protection is
automatically enabled (see L</REPLAY PROTECTION> below).
If the server rejects the early data sent by a client then it will skip over
@@ -221,7 +221,7 @@ max_early_data for the session and the recv_max_early_data setting for the
server. If a client sends more data than this then the connection will abort.
The configured value for max_early_data on a server may change over time as
-required. However clients may have tickets containing the previously configured
+required. However, clients may have tickets containing the previously configured
max_early_data value. The recv_max_early_data should always be equal to or
higher than any recently configured max_early_data value in order to avoid
aborted connections. The recv_max_early_data should never be set to less than
@@ -286,7 +286,7 @@ retry with a lower maximum protocol version.
When early data is in use the TLS protocol provides no security guarantees that
the same early data was not replayed across multiple connections. As a
mitigation for this issue OpenSSL automatically enables replay protection if the
-server is configured with a non-zero max early data value. With replay
+server is configured with a nonzero max early data value. With replay
protection enabled sessions are forced to be single use only. If a client
attempts to reuse a session ticket more than once, then the second and
subsequent attempts will fall back to a full handshake (and any early data that
@@ -317,7 +317,7 @@ cache. Applications should be designed with this in mind in order to minimise
the possibility of replay attacks.
The OpenSSL replay protection does not apply to external Pre Shared Keys (PSKs)
-(e.g. see SSL_CTX_set_psk_find_session_callback(3)). Therefore extreme caution
+(e.g. see SSL_CTX_set_psk_find_session_callback(3)). Therefore, extreme caution
should be applied when combining external PSKs with early data.
Some applications may mitigate the replay risks in other ways. For those
diff --git a/doc/man3/SSL_set1_host.pod b/doc/man3/SSL_set1_host.pod
index 4ae9f6e7f3..88dc353284 100644
--- a/doc/man3/SSL_set1_host.pod
+++ b/doc/man3/SSL_set1_host.pod
@@ -19,9 +19,9 @@ SSL server verification parameters
These functions configure server hostname checks in the SSL client.
SSL_set1_host() sets the expected DNS hostname to B<name> clearing
-any previously specified host name or names. If B<name> is NULL,
+any previously specified hostname or names. 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
diff --git a/doc/man3/SSL_set_bio.pod b/doc/man3/SSL_set_bio.pod
index 1fa0d34926..8a1c8aaf42 100644
--- a/doc/man3/SSL_set_bio.pod
+++ b/doc/man3/SSL_set_bio.pod
@@ -16,7 +16,7 @@ SSL_set_bio, SSL_set0_rbio, SSL_set0_wbio - connect the SSL object with a BIO
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
@@ -26,7 +26,7 @@ the same value as previously).
SSL_set0_wbio() works in the same as SSL_set0_rbio() except that it connects
the BIO B<wbio> for the write operations of the B<ssl> object. Note that if the
rbio and wbio are the same then SSL_set0_rbio() and SSL_set0_wbio() each take
-ownership of one reference. Therefore it may be necessary to increment the
+ownership of one reference. Therefore, it may be necessary to increment the
number of references available using L<BIO_up_ref(3)> before calling the set0
functions.
diff --git a/doc/man3/SSL_set_fd.pod b/doc/man3/SSL_set_fd.pod
index d5ec951e0b..3a1bb972b8 100644
--- a/doc/man3/SSL_set_fd.pod
+++ b/doc/man3/SSL_set_fd.pod
@@ -20,8 +20,8 @@ socket file descriptor of a network connection.
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).
diff --git a/doc/man3/SSL_set_shutdown.pod b/doc/man3/SSL_set_shutdown.pod
index b1cf58920b..de1a71aa96 100644
--- a/doc/man3/SSL_set_shutdown.pod
+++ b/doc/man3/SSL_set_shutdown.pod
@@ -20,7 +20,7 @@ SSL_get_shutdown() returns the shutdown mode of B<ssl>.
=head1 NOTES
-The shutdown state of an ssl connection is a bitmask of:
+The shutdown state of an ssl connection is a bit mask of:
=over 4
diff --git a/doc/man3/SSL_shutdown.pod b/doc/man3/SSL_shutdown.pod
index 30cf484619..5b7ef94dd1 100644
--- a/doc/man3/SSL_shutdown.pod
+++ b/doc/man3/SSL_shutdown.pod
@@ -95,13 +95,13 @@ 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
+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.
@@ -152,7 +152,7 @@ and the peer's close_notify alert was received.
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().
diff --git a/doc/man3/SSL_state_string.pod b/doc/man3/SSL_state_string.pod
index 505945a942..ad6ee8fb9e 100644
--- a/doc/man3/SSL_state_string.pod
+++ b/doc/man3/SSL_state_string.pod
@@ -26,11 +26,11 @@ maintained. Querying the state information is not very informative before
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.
diff --git a/doc/man3/SSL_want.pod b/doc/man3/SSL_want.pod
index 6840ccbfb6..6e283dda15 100644
--- a/doc/man3/SSL_want.pod
+++ b/doc/man3/SSL_want.pod
@@ -33,7 +33,7 @@ return values are similar to that of L<SSL_get_error(3)>.
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
diff --git a/doc/man3/SSL_write.pod b/doc/man3/SSL_write.pod
index a76ffbb8fd..8857a87e90 100644
--- a/doc/man3/SSL_write.pod
+++ b/doc/man3/SSL_write.pod
@@ -36,7 +36,7 @@ before the first call to a write function.
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>
@@ -44,7 +44,7 @@ or B<SSL_ERROR_WANT_WRITE>. As at any time a re-negotiation is possible, a
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.
diff --git a/doc/man3/UI_UTIL_read_pw.pod b/doc/man3/UI_UTIL_read_pw.pod
index a59cc4f386..032c6a1916 100644
--- a/doc/man3/UI_UTIL_read_pw.pod
+++ b/doc/man3/UI_UTIL_read_pw.pod
@@ -21,7 +21,7 @@ UI_UTIL_read_pw_string() asks for a passphrase, using B<prompt> as a
prompt, and stores it in B<buf>.
The maximum allowed size is given with B<length>, including the
terminating NUL byte.
-If B<verify> is non-zero, the password will be verified as well.
+If B<verify> is nonzero, the password will be verified as well.
UI_UTIL_read_pw() does the same as UI_UTIL_read_pw_string(), the
difference is that you can give it an external buffer B<buff> for the
diff --git a/doc/man3/UI_create_method.pod b/doc/man3/UI_create_method.pod
index a01e1012dc..210ebb4743 100644
--- a/doc/man3/UI_create_method.pod
+++ b/doc/man3/UI_create_method.pod
@@ -51,7 +51,7 @@ interface method creation and destruction
=head1 DESCRIPTION
-A method contains a few functions that implement the low level of the
+A method contains a few functions that implement the low-level of the
User Interface.
These functions are:
diff --git a/doc/man3/UI_new.pod b/doc/man3/UI_new.pod
index 3042b13f1f..0186632445 100644
--- a/doc/man3/UI_new.pod
+++ b/doc/man3/UI_new.pod
@@ -152,7 +152,7 @@ UI_construct_prompt() is a helper function that can be used to create
a prompt from two pieces of information: an description and a name.
The default constructor (if there is none provided by the method used)
creates a string "Enter I<description> for I<name>:". With the
-description "pass phrase" and the file name "foo.key", that becomes
+description "pass phrase" and the filename "foo.key", that becomes
"Enter pass phrase for foo.key:". Other methods may create whatever
string and may include encodings that will be processed by the other
method functions.
diff --git a/doc/man3/X509V3_get_d2i.pod b/doc/man3/X509V3_get_d2i.pod
index ac560b21e9..f42bc4006e 100644
--- a/doc/man3/X509V3_get_d2i.pod
+++ b/doc/man3/X509V3_get_d2i.pod
@@ -78,7 +78,7 @@ of a certificate a CRL or a CRL entry respectively.
=head1 NOTES
In almost all cases an extension can occur at most once and multiple
-occurrences is an error. Therefore the B<idx> parameter is usually B<NULL>.
+occurrences is an error. Therefore, the B<idx> parameter is usually B<NULL>.
The B<flags> parameter may be one of the following values.
diff --git a/doc/man3/X509_ALGOR_dup.pod b/doc/man3/X509_ALGOR_dup.pod
index 6612354508..ceef19a3b5 100644
--- a/doc/man3/X509_ALGOR_dup.pod
+++ b/doc/man3/X509_ALGOR_dup.pod
@@ -35,7 +35,7 @@ X509_ALGOR_set_md() sets the B<AlgorithmIdentifier> B<alg> to appropriate
values for the message digest B<md>.
X509_ALGOR_cmp() compares B<a> and B<b> and returns 0 if they have identical
-encodings and non-zero otherwise.
+encodings and nonzero otherwise.
X509_ALGOR_copy() copies the source values into the dest structs; making
a duplicate of each (and free any thing pointed to from within *dest).
@@ -50,7 +50,7 @@ X509_ALGOR_set0() and X509_ALGOR_copy() return 1 on success or 0 on error.
X509_ALGOR_get0() and X509_ALGOR_set_md() return no values.
X509_ALGOR_cmp() returns 0 if the two parameters have identical encodings and
-non-zero otherwise.
+nonzero otherwise.
=head1 HISTORY
diff --git a/doc/man3/X509_LOOKUP_hash_dir.pod b/doc/man3/X509_LOOKUP_hash_dir.pod
index dd41f78b12..8700b2bd17 100644
--- a/doc/man3/X509_LOOKUP_hash_dir.pod
+++ b/doc/man3/X509_LOOKUP_hash_dir.pod
@@ -80,7 +80,7 @@ upon each lookup, so that newer CRLs are as soon as they appear in
the directory.
The directory should contain one certificate or CRL per file in PEM format,
-with a file name of the form I<hash>.I<N> for a certificate, or
+with a filename of the form I<hash>.I<N> for a certificate, or
I<hash>.B<r>I<N> for a CRL.
The I<hash> is the value returned by the L<X509_NAME_hash(3)> function applied
to the subject name for certificates or issuer name for CRLs.
diff --git a/doc/man3/X509_LOOKUP_meth_new.pod b/doc/man3/X509_LOOKUP_meth_new.pod
index a4e7466395..ad581d4b42 100644
--- a/doc/man3/X509_LOOKUP_meth_new.pod
+++ b/doc/man3/X509_LOOKUP_meth_new.pod
@@ -151,7 +151,7 @@ Implementations must add objects they find to the B<X509_STORE> object
using X509_STORE_add_cert() or X509_STORE_add_crl(). This increments
its reference count. However, the X509_STORE_CTX_get_by_subject()
function also increases the reference count which leads to one too
-many references being held. Therefore applications should
+many references being held. Therefore, applications should
additionally call X509_free() or X509_CRL_free() to decrement the
reference count again.
diff --git a/doc/man3/X509_STORE_CTX_get_error.pod b/doc/man3/X509_STORE_CTX_get_error.pod
index bdbf86ae96..1bded01794 100644
--- a/doc/man3/X509_STORE_CTX_get_error.pod
+++ b/doc/man3/X509_STORE_CTX_get_error.pod
@@ -38,7 +38,7 @@ it might be used in a verification callback to set an error based on additional
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.
@@ -79,7 +79,7 @@ verification error B<n>.
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.
diff --git a/doc/man3/X509_STORE_CTX_new.pod b/doc/man3/X509_STORE_CTX_new.pod
index c5042858be..4b5c11e385 100644
--- a/doc/man3/X509_STORE_CTX_new.pod
+++ b/doc/man3/X509_STORE_CTX_new.pod
@@ -52,7 +52,7 @@ by X509_verify_cert().
X509_STORE_CTX_new() returns a newly initialised B<X509_STORE_CTX> structure.
X509_STORE_CTX_cleanup() internally cleans up an B<X509_STORE_CTX> structure.
-The context can then be reused with an new call to X509_STORE_CTX_init().
+The context can then be reused with a new call to X509_STORE_CTX_init().
X509_STORE_CTX_free() completely frees up B<ctx>. After this call B<ctx>
is no longer valid.
@@ -80,7 +80,7 @@ X509_STORE_CTX_set0_verified_chain() sets the validated chain used
by B<ctx> to be B<chain>.
Ownership of the chain is transferred to B<ctx> and should not be
free'd by the caller.
-X509_STORE_CTX_get0_chain() returns a the internal pointer used by the
+X509_STORE_CTX_get0_chain() returns the internal pointer used by the
B<ctx> that contains the validated chain.
X509_STORE_CTX_set0_crls() sets a set of CRLs to use to aid certificate
@@ -133,7 +133,7 @@ should be made or reference counts increased instead.
=head1 RETURN VALUES
-X509_STORE_CTX_new() returns an newly allocates context or B<NULL> is an
+X509_STORE_CTX_new() returns a newly allocated context or B<NULL> if an
error occurred.
X509_STORE_CTX_init() returns 1 for success or 0 if an error occurred.
diff --git a/doc/man3/X509_STORE_CTX_set_verify_cb.pod b/doc/man3/X509_STORE_CTX_set_verify_cb.pod
index 7cd661f215..cf3fe092c5 100644
--- a/doc/man3/X509_STORE_CTX_set_verify_cb.pod
+++ b/doc/man3/X509_STORE_CTX_set_verify_cb.pod
@@ -48,7 +48,7 @@ The verification callback can be used to customise the operation of certificate
verification, either by overriding error conditions or logging errors for
debugging purposes.
-However a verification callback is B<not> essential and the default operation
+However, a verification callback is B<not> essential and the default operation
is often sufficient.
The B<ok> parameter to the callback indicates the value the callback should
diff --git a/doc/man3/X509_VERIFY_PARAM_set_flags.pod b/doc/man3/X509_VERIFY_PARAM_set_flags.pod
index a87b71d92a..66620344ff 100644
--- a/doc/man3/X509_VERIFY_PARAM_set_flags.pod
+++ b/doc/man3/X509_VERIFY_PARAM_set_flags.pod
@@ -129,7 +129,7 @@ interoperable, though it will, for example, reject MD5 signatures or RSA keys
shorter than 1024 bits.
X509_VERIFY_PARAM_set1_host() sets the expected DNS hostname to
-B<name> clearing any previously specified host name or names. If
+B<name> clearing any previously specified hostname or names. If
B<name> is NULL, or empty the list of hostnames is cleared, and
name checks are not performed on the peer certificate. If B<name>
is NUL-terminated, B<namelen> may be zero, otherwise B<namelen>
diff --git a/doc/man3/X509_check_ca.pod b/doc/man3/X509_check_ca.pod
index 38f0811dd0..ea8008a69f 100644
--- a/doc/man3/X509_check_ca.pod
+++ b/doc/man3/X509_check_ca.pod
@@ -24,7 +24,7 @@ B<keyUsage> extension with bit B<keyCertSign> set, but without
B<basicConstraints>, and 5 if it has outdated Netscape Certificate Type
extension telling that it is CA certificate.
-Actually, any non-zero value means that this certificate could have been
+Actually, any nonzero value means that this certificate could have been
used to sign other certificates.
=head1 SEE ALSO
diff --git a/doc/man3/X509_check_host.pod b/doc/man3/X509_check_host.pod
index dba6a6976e..0e27dda845 100644
--- a/doc/man3/X509_check_host.pod
+++ b/doc/man3/X509_check_host.pod
@@ -19,13 +19,13 @@ X509_check_host, X509_check_email, X509_check_ip, X509_check_ip_asc - X.509 cert
=head1 DESCRIPTION
The certificate matching functions are used to check whether a
-certificate matches a given host name, email address, or IP address.
+certificate matches a given hostname, email address, or IP address.
The validity of the certificate and its trust level has to be checked by
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,
@@ -37,7 +37,7 @@ Per section 6.4.2 of RFC 6125, B<name> values representing international
domain names must be given in A-label form. The B<namelen> argument
must be the number of characters in the name string or zero in which
case the length is calculated with strlen(B<name>). When B<name> starts
-with a dot (e.g ".example.com"), it will be matched by a certificate
+with a dot (e.g. ".example.com"), it will be matched by a certificate
valid for any sub-domain of B<name>, (see also
B<X509_CHECK_FLAG_SINGLE_LABEL_SUBDOMAINS> below).
diff --git a/doc/man3/X509_check_purpose.pod b/doc/man3/X509_check_purpose.pod
index bc38138743..6af9e79815 100644
--- a/doc/man3/X509_check_purpose.pod
+++ b/doc/man3/X509_check_purpose.pod
@@ -35,7 +35,7 @@ For non-CA checks
=over 4
-=item -1 an error condition has occured
+=item -1 an error condition has occurred
=item E<32>1 if the certificate was created to perform the purpose represented by I<id>
@@ -47,7 +47,7 @@ For CA checks the below integers could be returned with the following meanings:
=over 4
-=item -1 an error condition has occured
+=item -1 an error condition has occurred
=item E<32>0 not a CA or does not have the purpose represented by I<id>
diff --git a/doc/man3/X509v3_get_ext_by_NID.pod b/doc/man3/X509v3_get_ext_by_NID.pod
index c81d463650..20f1793645 100644
--- a/doc/man3/X509v3_get_ext_by_NID.pod
+++ b/doc/man3/X509v3_get_ext_by_NID.pod
@@ -71,7 +71,7 @@ the extension is found its index is returned otherwise B<-1> is returned.
X509v3_get_ext_by_critical() is similar to X509v3_get_ext_by_NID() except it
looks for an extension of criticality B<crit>. A zero value for B<crit>
-looks for a non-critical extension a non-zero value looks for a critical
+looks for a non-critical extension a nonzero value looks for a critical
extension.
X509v3_delete_ext() deletes the extension with index B<loc> from B<x>. The
diff --git a/doc/man3/d2i_X509.pod b/doc/man3/d2i_X509.pod
index a8319bd471..245df0c8d9 100644
--- a/doc/man3/d2i_X509.pod
+++ b/doc/man3/d2i_X509.pod
@@ -436,8 +436,8 @@ The actual TYPE structure passed to i2d_TYPE() must be a valid
populated B<TYPE> structure -- it B<cannot> simply be fed with an
empty structure such as that returned by TYPE_new().
-The encoded data is in binary form and may contain embedded zeroes.
-Therefore any FILE pointers or BIOs should be opened in binary mode.
+The encoded data is in binary form and may contain embedded zeros.
+Therefore, any FILE pointers or BIOs should be opened in binary mode.
Functions such as strlen() will B<not> return the correct length
of the encoded structure.
diff --git a/doc/man5/config.pod b/doc/man5/config.pod
index 7a0459d993..3cc2d73a52 100644
--- a/doc/man5/config.pod
+++ b/doc/man5/config.pod
@@ -435,7 +435,7 @@ the value.
The escaping isn't quite right: if you want to use sequences like B<\n>
you can't use any quote escaping on the same line.
-Files are loaded in a single pass. This means that an variable expansion
+Files are loaded in a single pass. This means that a variable expansion
will only work if the variables referenced are defined earlier in the
file.
diff --git a/doc/man5/x509v3_config.pod b/doc/man5/x509v3_config.pod
index 803b12b3ed..9407d8beda 100644
--- a/doc/man5/x509v3_config.pod
+++ b/doc/man5/x509v3_config.pod
@@ -60,8 +60,8 @@ The following sections describe each supported extension in detail.
This is a multi valued extension which indicates whether a certificate is
a CA certificate. The first (mandatory) name is B<CA> followed by B<TRUE> or
-B<FALSE>. If B<CA> is B<TRUE> then an optional B<pathlen> name followed by an
-non-negative value can be included.
+B<FALSE>. If B<CA> is B<TRUE> then an optional B<pathlen> name followed by a
+nonnegative value can be included.
For example:
diff --git a/doc/man7/SM2.pod b/doc/man7/SM2.pod
index c8fceffa1c..73960fe70b 100644
--- a/doc/man7/SM2.pod
+++ b/doc/man7/SM2.pod
@@ -33,7 +33,7 @@ Then an ID should be set by calling:
EVP_PKEY_CTX_set1_id(pctx, id, id_len);
When calling the EVP_DigestSignInit() or EVP_DigestVerifyInit() functions, a
-pre-allocated B<EVP_PKEY_CTX> should be assigned to the B<EVP_MD_CTX>. This is
+preallocated B<EVP_PKEY_CTX> should be assigned to the B<EVP_MD_CTX>. This is
done by calling:
EVP_MD_CTX_set_pkey_ctx(mctx, pctx);
diff --git a/doc/man7/evp.pod b/doc/man7/evp.pod
index e493dacd23..cd2df206cb 100644
--- a/doc/man7/evp.pod
+++ b/doc/man7/evp.pod
@@ -25,7 +25,7 @@ functions.
Symmetric encryption is available with the L<B<EVP_Encrypt>I<XXX>|EVP_EncryptInit(3)>
functions. The L<B<EVP_Digest>I<XXX>|EVP_DigestInit(3)> functions provide message digests.
-The B<EVP_PKEY>I<XXX> functions provide a high level interface to
+The B<EVP_PKEY>I<XXX> functions provide a high-level interface to
asymmetric algorithms. To create a new EVP_PKEY see
L<EVP_PKEY_new(3)>. EVP_PKEYs can be associated
with a private key of a particular algorithm by using the functions
@@ -43,7 +43,7 @@ The EVP_PKEY functions support the full range of asymmetric algorithm operations
=item For signing and verifying see L<EVP_PKEY_sign(3)>,
L<EVP_PKEY_verify(3)> and L<EVP_PKEY_verify_recover(3)>.
However, note that
-these functions do not perform a digest of the data to be signed. Therefore
+these functions do not perform a digest of the data to be signed. Therefore,
normally you would use the L<EVP_DigestSignInit(3)>
functions for this purpose.
@@ -72,12 +72,12 @@ as defaults, then the various EVP functions will automatically use those
implementations automatically in preference to built in software
implementations. For more information, consult the engine(3) man page.
-Although low level algorithm specific functions exist for many algorithms
+Although low-level algorithm specific functions exist for many algorithms
their use is discouraged. They cannot be used with an ENGINE and ENGINE
-versions of new algorithms cannot be accessed using the low level functions.
+versions of new algorithms cannot be accessed using the low-level functions.
Also makes code harder to adapt to new algorithms and some options are not
-cleanly supported at the low level and some operations are more efficient
-using the high level interface.
+cleanly supported at the low-level and some operations are more efficient
+using the high-level interface.
=head1 SEE ALSO
diff --git a/doc/man7/ossl_store.pod b/doc/man7/ossl_store.pod
index 6e75abd314..e9652cff14 100644
--- a/doc/man7/ossl_store.pod
+++ b/doc/man7/ossl_store.pod
@@ -15,7 +15,7 @@ ossl_store - Store retrieval functions
=head2 General
A STORE is a layer of functionality to retrieve a number of supported
-objects from a repository of any kind, addressable as a file name or
+objects from a repository of any kind, addressable as a filename or
as a URI.
The functionality supports the pattern "open a channel to the
More information about the openssl-commits
mailing list