[openssl] master update
matthias.st.pierre at ncp-e.com
matthias.st.pierre at ncp-e.com
Sat Jul 4 23:50:52 UTC 2020
The branch master has been updated
via 8c1cbc72105ffd493b48e65f8f5fd3657dedb28c (commit)
from 3a19f1a9dd16f5855a7e2a42cd3e7f136f849bd3 (commit)
- Log -----------------------------------------------------------------
commit 8c1cbc72105ffd493b48e65f8f5fd3657dedb28c
Author: Gustaf Neumann <neumann at wu-wien.ac.at>
Date: Mon Jun 29 21:13:07 2020 +0200
Fix typos and repeated words
CLA: trivial
Reviewed-by: Shane Lontis <shane.lontis at oracle.com>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre at ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/12320)
-----------------------------------------------------------------------
Summary of changes:
.github/PULL_REQUEST_TEMPLATE.md | 2 +-
INSTALL.md | 14 +++++++-------
NEWS.md | 14 +++++++-------
NOTES.ANDROID | 4 ++--
NOTES.VMS | 2 +-
NOTES.WIN | 6 +++---
doc/internal/man3/OPENSSL_SA.pod | 2 +-
doc/internal/man3/s2i_ASN1_UTF8STRING.pod | 2 +-
doc/internal/man7/DERlib.pod | 4 ++--
doc/internal/man7/EVP_PKEY.pod | 5 ++---
doc/internal/man7/build.info.pod | 2 +-
doc/man1/openssl-ca.pod.in | 2 +-
doc/man1/openssl-cmp.pod.in | 2 +-
doc/man1/openssl-dsa.pod.in | 2 +-
doc/man1/openssl-enc.pod.in | 2 +-
doc/man1/openssl-pkcs12.pod.in | 2 +-
doc/man1/openssl-pkcs8.pod.in | 2 +-
doc/man1/openssl-pkeyutl.pod.in | 2 +-
doc/man1/openssl-s_client.pod.in | 6 +++---
doc/man1/openssl-s_server.pod.in | 4 ++--
doc/man1/openssl-s_time.pod.in | 4 ++--
doc/man1/openssl-sess_id.pod.in | 2 +-
doc/man1/openssl.pod | 2 +-
doc/man3/ASN1_INTEGER_get_int64.pod | 2 +-
doc/man3/ASN1_STRING_length.pod | 2 +-
doc/man3/ASN1_TYPE_get.pod | 2 +-
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_ctrl.pod | 2 +-
doc/man3/BIO_s_bio.pod | 2 +-
doc/man3/BIO_set_callback.pod | 2 +-
doc/man3/CMS_verify.pod | 2 +-
doc/man3/CRYPTO_THREAD_run_once.pod | 2 +-
doc/man3/DH_set_method.pod | 2 +-
doc/man3/DSA_set_method.pod | 2 +-
doc/man3/DTLSv1_listen.pod | 2 +-
doc/man3/ECDSA_SIG_new.pod | 2 +-
doc/man3/EC_GROUP_new.pod | 2 +-
doc/man3/EC_POINT_new.pod | 2 +-
doc/man3/ENGINE_add.pod | 16 ++++++++--------
doc/man3/EVP_DigestInit.pod | 4 ++--
doc/man3/EVP_DigestSignInit.pod | 6 +++---
doc/man3/EVP_DigestVerifyInit.pod | 6 +++---
doc/man3/EVP_EncodeInit.pod | 2 +-
doc/man3/EVP_EncryptInit.pod | 8 ++++----
doc/man3/EVP_KDF.pod | 2 +-
doc/man3/EVP_OpenInit.pod | 2 +-
doc/man3/EVP_PKEY_CTX_new.pod | 2 +-
doc/man3/EVP_PKEY_derive.pod | 2 +-
doc/man3/EVP_PKEY_fromdata.pod | 2 +-
doc/man3/EVP_PKEY_sign.pod | 2 +-
doc/man3/EVP_PKEY_verify.pod | 2 +-
doc/man3/EVP_PKEY_verify_recover.pod | 2 +-
doc/man3/EVP_RAND.pod | 6 +++---
doc/man3/EVP_SealInit.pod | 2 +-
doc/man3/EVP_SignInit.pod | 4 ++--
doc/man3/EVP_VerifyInit.pod | 4 ++--
doc/man3/EVP_set_default_properties.pod | 2 +-
doc/man3/OPENSSL_LH_COMPFUNC.pod | 2 +-
doc/man3/OPENSSL_config.pod | 2 +-
doc/man3/OPENSSL_ia32cap.pod | 2 +-
doc/man3/OPENSSL_s390xcap.pod | 2 +-
doc/man3/OSSL_CMP_log_open.pod | 4 ++--
doc/man3/OSSL_PARAM_int.pod | 4 ++--
doc/man3/OSSL_SERIALIZER_CTX_new_by_EVP_PKEY.pod | 2 +-
doc/man3/PEM_read_bio_PrivateKey.pod | 4 ++--
doc/man3/PKCS7_verify.pod | 2 +-
doc/man3/RAND_DRBG_set_callbacks.pod | 4 ++--
doc/man3/RSA_private_encrypt.pod | 4 ++--
doc/man3/RSA_set_method.pod | 2 +-
doc/man3/SRP_create_verifier.pod | 2 +-
doc/man3/SSL_CONF_cmd.pod | 6 +++---
doc/man3/SSL_CTX_set1_curves.pod | 2 +-
doc/man3/SSL_CTX_set_generate_session_id.pod | 4 ++--
doc/man3/SSL_CTX_set_options.pod | 2 +-
doc/man3/SSL_CTX_set_psk_client_callback.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 +-
doc/man3/SSL_CTX_set_tlsext_servername_callback.pod | 2 +-
doc/man3/SSL_CTX_use_psk_identity_hint.pod | 2 +-
doc/man3/SSL_get_all_async_fds.pod | 4 ++--
doc/man3/SSL_get_error.pod | 4 ++--
doc/man3/SSL_pending.pod | 2 +-
doc/man3/SSL_read.pod | 2 +-
doc/man3/SSL_read_early_data.pod | 4 ++--
doc/man3/SSL_set_bio.pod | 8 +++-----
doc/man3/UI_create_method.pod | 2 +-
doc/man3/X509V3_get_d2i.pod | 2 +-
doc/man3/X509_LOOKUP_meth_new.pod | 2 +-
doc/man3/X509_STORE_CTX_new.pod | 6 +++---
doc/man3/X509_STORE_CTX_set_verify_cb.pod | 2 +-
doc/man3/X509_check_host.pod | 2 +-
doc/man3/X509_check_purpose.pod | 4 ++--
doc/man3/d2i_X509.pod | 2 +-
doc/man5/x509v3_config.pod | 2 +-
doc/man7/EVP_KDF-KRB5KDF.pod | 2 +-
doc/man7/EVP_PKEY-DH.pod | 2 +-
doc/man7/EVP_PKEY-X25519.pod | 2 +-
doc/man7/evp.pod | 12 ++++++------
doc/man7/provider-base.pod | 4 ++--
fuzz/README.md | 2 +-
util/find-doc-nits | 1 +
107 files changed, 170 insertions(+), 172 deletions(-)
diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
index 191d9c9174..85cfb3741c 100644
--- a/.github/PULL_REQUEST_TEMPLATE.md
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@@ -5,7 +5,7 @@ Contributors guide: https://github.com/openssl/openssl/blob/master/CONTRIBUTING.
Other than that, provide a description above this comment if there isn't one already
-If this fixes a github issue, make sure to have a line saying 'Fixes #XXXX' (without quotes) in the commit message.
+If this fixes a GitHub issue, make sure to have a line saying 'Fixes #XXXX' (without quotes) in the commit message.
-->
##### Checklist
diff --git a/INSTALL.md b/INSTALL.md
index 6989410e87..5686415ad8 100644
--- a/INSTALL.md
+++ b/INSTALL.md
@@ -167,7 +167,7 @@ Use the following commands to build OpenSSL:
### Windows
If you are using Visual Studio, open a Developer Command Prompt and
-and issue the following commands to build OpenSSL.
+issue the following commands to build OpenSSL.
$ perl Configure
$ nmake
@@ -192,7 +192,7 @@ paragraphs carefully before you install OpenSSL.
For security reasons the default system location is by default not writable
for unprivileged users. So for the final installation step administrative
privileges are required. The default system location and the procedure to
-obtain administrative privileges depends on the operating sytem.
+obtain administrative privileges depends on the operating system.
It is recommended to compile and test OpenSSL with normal user privileges
and use administrative privileges only for the final installation step.
@@ -482,8 +482,8 @@ be a hex string no more than 64 characters.
Enable and Disable Features
---------------------------
-Feature options always come in pairs, an option to enable feature `xxxx`, and
-and option to disable it:
+Feature options always come in pairs, an option to enable feature
+`xxxx`, and an option to disable it:
[ enable-xxxx | no-xxxx ]
@@ -852,7 +852,7 @@ Don't build with support for multi-threaded applications.
### threads
Build with support for multi-threaded applications. Most platforms will enable
-this by default. However if on a platform where this is not the case then this
+this by default. However, if on a platform where this is not the case then this
will usually require additional system-dependent options!
See [Notes on multi-threading](#notes-on-multi-threading) below.
@@ -1457,7 +1457,7 @@ described here. Examine the Makefiles themselves for the full list.
Only install the OpenSSL man pages (Unix only).
install_html_docs
- Only install the OpenSSL html documentation.
+ Only install the OpenSSL HTML documentation.
list-tests
Prints a list of all the self test names.
@@ -1683,7 +1683,7 @@ to deliver random bytes and a "PRNG not seeded error" will occur.
The seeding method can be configured using the `--with-rand-seed` option,
which can be used to specify a comma separated list of seed methods.
-However in most cases OpenSSL will choose a suitable default method,
+However, in most cases OpenSSL will choose a suitable default method,
so it is not necessary to explicitly provide this option. Note also
that not all methods are available on all platforms.
diff --git a/NEWS.md b/NEWS.md
index 1d36a903f1..9985bbfd05 100644
--- a/NEWS.md
+++ b/NEWS.md
@@ -27,7 +27,7 @@ OpenSSL 3.0
will not be accidentially used.
* The algorithm specific public key command line applications have
been deprecated. These include dhparam, gendsa and others. The pkey
- alternatives should be used intead: pkey, pkeyparam and genpkey.
+ alternatives should be used instead: pkey, pkeyparam and genpkey.
* X509 certificates signed using SHA1 are no longer allowed at security
level 1 or higher. The default security level for TLS is 1, so
certificates signed using SHA1 are by default no longer trusted to
@@ -57,12 +57,12 @@ OpenSSL 3.0
* Removed the heartbeat message in DTLS feature.
* Added EVP_KDF, an EVP layer KDF API, and a generic EVP_PKEY to EVP_KDF
bridge.
- * All of the low level MD2, MD4, MD5, MDC2, RIPEMD160, SHA1, SHA224,
+ * All of the low-level MD2, MD4, MD5, MDC2, RIPEMD160, SHA1, SHA224,
SHA256, SHA384, SHA512 and Whirlpool digest functions have been
deprecated.
- * All of the low level AES, Blowfish, Camellia, CAST, DES, IDEA, RC2,
+ * All of the low-level AES, Blowfish, Camellia, CAST, DES, IDEA, RC2,
RC4, RC5 and SEED cipher functions have been deprecated.
- * All of the low level DH, DSA, ECDH, ECDSA and RSA public key functions
+ * All of the low-level DH, DSA, ECDH, ECDSA and RSA public key functions
have been deprecated.
* SSL 3, TLS 1.0, TLS 1.1, and DTLS 1.0 only work at security level 0.
@@ -681,7 +681,7 @@ OpenSSL 1.0.0
Known issues in OpenSSL 1.0.0m:
* EAP-FAST and other applications using tls_session_secret_cb
- wont resume sessions. Fixed in 1.0.0n-dev
+ won't resume sessions. Fixed in 1.0.0n-dev
* Compilation failure of s3_pkt.c on some platforms due to missing
`<limits.h>` include. Fixed in 1.0.0n-dev
@@ -1189,7 +1189,7 @@ OpenSSL 0.9.x
* Enhanced chain verification using key identifiers.
* New sign and verify options to 'dgst' application.
* Support for DER and PEM encoded messages in 'smime' application.
- * New 'rsautl' application, low level RSA utility.
+ * New 'rsautl' application, low-level RSA utility.
* MD4 now included.
* Bugfix for SSL rollback padding check.
* Support for external crypto devices [1].
@@ -1241,7 +1241,7 @@ OpenSSL 0.9.x
* BIGNUM library bug fixes
* Faster DSA parameter generation
* Enhanced support for Alpha Linux
- * Experimental MacOS support
+ * Experimental macOS support
### Major changes between OpenSSL 0.9.3 and OpenSSL 0.9.4 [9 Aug 1999]
diff --git a/NOTES.ANDROID b/NOTES.ANDROID
index 0173eca73b..087d5e6f49 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.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 5151107707..683e40671e 100644
--- a/NOTES.WIN
+++ b/NOTES.WIN
@@ -18,7 +18,7 @@
For this option you can use Cygwin.
- Visual C++ native builds, a.k.a. VC-*
+ Visual C++ native builds, aka VC-*
=====================================
Requirement details
@@ -100,7 +100,7 @@
is, of course, to choose a different set of directories by using
--prefix and --openssldir when configuring.
- Special notes for Universal Windows Platform builds, a.k.a. VC-*-UWP
+ Special notes for Universal Windows Platform builds, aka VC-*-UWP
--------------------------------------------------------------------
- UWP targets only support building the static and dynamic libraries.
@@ -119,7 +119,7 @@
MSYS2 provides GNU tools, a Unix-like command prompt,
and a UNIX compatibility layer for applications.
- However in this context it is only used for building OpenSSL.
+ However, in this context it is only used for building OpenSSL.
The resulting OpenSSL does not rely on MSYS2 to run and is fully native.
Requirement details
diff --git a/doc/internal/man3/OPENSSL_SA.pod b/doc/internal/man3/OPENSSL_SA.pod
index 1a6e027418..cc775830e9 100644
--- a/doc/internal/man3/OPENSSL_SA.pod
+++ b/doc/internal/man3/OPENSSL_SA.pod
@@ -69,7 +69,7 @@ elements. After this call I<sa> is no longer valid.
B<ossl_sa_I<TYPE>_doall>() calls the function I<leaf> for each element in I<sa>
in ascending index order. The index position, within the sparse array,
of each item is passed as the first argument to the leaf function and a
-pointer to the associated value is is passed as the second argument.
+pointer to the associated value is passed as the second argument.
B<ossl_sa_I<TYPE>_doall_arg>() calls the function I<leaf> for each element in
I<sa> in ascending index order. The index position, within the sparse
diff --git a/doc/internal/man3/s2i_ASN1_UTF8STRING.pod b/doc/internal/man3/s2i_ASN1_UTF8STRING.pod
index 9b806eb80b..b6d1375189 100644
--- a/doc/internal/man3/s2i_ASN1_UTF8STRING.pod
+++ b/doc/internal/man3/s2i_ASN1_UTF8STRING.pod
@@ -18,7 +18,7 @@ s2i_ASN1_UTF8STRING
=head1 DESCRIPTION
These functions convert OpenSSL objects to and from their ASN.1/string
-representation. This function is used for B<X509v3> extentions.
+representation. This function is used for B<X509v3> extensions.
=head1 NOTES
diff --git a/doc/internal/man7/DERlib.pod b/doc/internal/man7/DERlib.pod
index 7b0e7225f0..2577df0caa 100644
--- a/doc/internal/man7/DERlib.pod
+++ b/doc/internal/man7/DERlib.pod
@@ -7,7 +7,7 @@ DERlib - internal OpenSSL DER library
=head1 DESCRIPTION
OpenSSL contains an internal small DER reading and writing library,
-as an alternative to the publically known i2d and d2i functions. It's
+as an alternative to the publicly known i2d and d2i functions. It's
solely constituted of functions that work as building blocks to create
more similar functions to encode and decode larger structures.
@@ -47,7 +47,7 @@ which is defined like this in ASN.1 terms:
r INTEGER,
s INTEGER }
-With the DER library, this is the correspoding code, given two OpenSSL
+With the DER library, this is the corresponding code, given two OpenSSL
B<BIGNUM>s I<r> and I<s>:
int ok = DER_w_begin_sequence(pkt, -1)
diff --git a/doc/internal/man7/EVP_PKEY.pod b/doc/internal/man7/EVP_PKEY.pod
index a37ca9eecc..00d4df57f5 100644
--- a/doc/internal/man7/EVP_PKEY.pod
+++ b/doc/internal/man7/EVP_PKEY.pod
@@ -19,12 +19,11 @@ private/public key key pairs, but has had other uses as well.
=for comment "uses" could as well be "abuses"...
-It can contain the legacy form of keys -- i.e. pointers to the low
-level key types, such as B<RSA>, B<DSA> and B<EC> --, but also the
+It can contain the legacy form of keys -- i.e. pointers to the low-level key types, such as B<RSA>, B<DSA> and B<EC> --, but also the
provided form of keys -- i.e. pointers to provider side key data.
Those two forms are mutually exclusive; an B<EVP_PKEY> instance can't
contain both a key in legacy form and in provided form. Regardless of
-form, this key is commonly refered to as the "origin".
+form, this key is commonly referred to as the "origin".
An B<EVP_PKEY> also contains a cache of provider side copies of the
key, each adapted for the provider that is going to use that copy to
diff --git a/doc/internal/man7/build.info.pod b/doc/internal/man7/build.info.pod
index 2049868fc6..5a2fdd13ed 100644
--- a/doc/internal/man7/build.info.pod
+++ b/doc/internal/man7/build.info.pod
@@ -610,7 +610,7 @@ B<SCRIPTS>.
For OpenSSL::Template documentation,
C<perldoc -o man util/perl/OpenSSL/Template.pm>
-L<Text::Temlate|https://metacpan.org/pod/Text::Template>
+L<Text::Template|https://metacpan.org/pod/Text::Template>
=head1 COPYRIGHT
diff --git a/doc/man1/openssl-ca.pod.in b/doc/man1/openssl-ca.pod.in
index 22a0cb40d8..519f5f4eed 100644
--- a/doc/man1/openssl-ca.pod.in
+++ b/doc/man1/openssl-ca.pod.in
@@ -253,7 +253,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/openssl-cmp.pod.in b/doc/man1/openssl-cmp.pod.in
index 0d05e7fb98..b148afb2dc 100644
--- a/doc/man1/openssl-cmp.pod.in
+++ b/doc/man1/openssl-cmp.pod.in
@@ -1104,7 +1104,7 @@ This prints information about all received ITAV B<infoType>s to stdout.
For CMP client invocations, in particular for certificate enrollment,
usually many parameters need to be set, which is tedious and error-prone to do
on the command line.
-Therefore the client offers the possibility to read
+Therefore, the client offers the possibility to read
options from sections of the OpenSSL config file, usually called B<openssl.cnf>.
The values found there can still be extended and even overridden by any
subsequently loaded sections and on the command line.
diff --git a/doc/man1/openssl-dsa.pod.in b/doc/man1/openssl-dsa.pod.in
index f3d1a9423c..2db0407821 100644
--- a/doc/man1/openssl-dsa.pod.in
+++ b/doc/man1/openssl-dsa.pod.in
@@ -62,7 +62,7 @@ The input and formats; the default is B<PEM>.
See L<openssl(1)/Format Options> for details.
Private keys are a sequence of B<ASN.1 INTEGERS>: the version (zero), B<p>,
-B<q>, B<g>, and the public and and private key components. Public keys
+B<q>, B<g>, and the public and private key components. Public keys
are a B<SubjectPublicKeyInfo> structure with the B<DSA> type.
The B<PEM> format also accepts PKCS#8 data.
diff --git a/doc/man1/openssl-enc.pod.in b/doc/man1/openssl-enc.pod.in
index 6971de51ad..dcbeb8877b 100644
--- a/doc/man1/openssl-enc.pod.in
+++ b/doc/man1/openssl-enc.pod.in
@@ -241,7 +241,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/openssl-pkcs12.pod.in b/doc/man1/openssl-pkcs12.pod.in
index da5214d563..7d0629b376 100644
--- a/doc/man1/openssl-pkcs12.pod.in
+++ b/doc/man1/openssl-pkcs12.pod.in
@@ -244,7 +244,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> I<digest>
diff --git a/doc/man1/openssl-pkcs8.pod.in b/doc/man1/openssl-pkcs8.pod.in
index 0729302053..719e3d9168 100644
--- a/doc/man1/openssl-pkcs8.pod.in
+++ b/doc/man1/openssl-pkcs8.pod.in
@@ -248,7 +248,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/openssl-pkeyutl.pod.in b/doc/man1/openssl-pkeyutl.pod.in
index d823f0b851..2bcbb54c57 100644
--- a/doc/man1/openssl-pkeyutl.pod.in
+++ b/doc/man1/openssl-pkeyutl.pod.in
@@ -43,7 +43,7 @@ B<openssl> B<pkeyutl>
=head1 DESCRIPTION
-This command can be used to perform low level public key
+This command can be used to perform low-level public key
operations using any supported algorithm.
=head1 OPTIONS
diff --git a/doc/man1/openssl-s_client.pod.in b/doc/man1/openssl-s_client.pod.in
index 367e59e925..e8f73cdb99 100644
--- a/doc/man1/openssl-s_client.pod.in
+++ b/doc/man1/openssl-s_client.pod.in
@@ -192,7 +192,7 @@ When used with the B<-proxy> flag, the program will attempt to authenticate
with the specified proxy using basic (base64) authentication.
NB: Basic authentication is insecure; the credentials are sent to the proxy
in easily reversible base64 encoding before any TLS/SSL session is established.
-Therefore these credentials are easily recovered by anyone able to sniff/trace
+Therefore, these credentials are easily recovered by anyone able to sniff/trace
the network. Use with caution.
=item B<-proxy_pass> I<arg>
@@ -854,14 +854,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 this command, 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/openssl-s_server.pod.in b/doc/man1/openssl-s_server.pod.in
index 28ef15ea56..07cde67cde 100644
--- a/doc/man1/openssl-s_server.pod.in
+++ b/doc/man1/openssl-s_server.pod.in
@@ -433,9 +433,9 @@ For more information on shutting down a connection, see L<SSL_shutdown(3)>.
=item B<-id_prefix> I<val>
Generate SSL/TLS session IDs prefixed by I<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<-verify_return_error>
diff --git a/doc/man1/openssl-s_time.pod.in b/doc/man1/openssl-s_time.pod.in
index 0f9f055591..90e54f03c2 100644
--- a/doc/man1/openssl-s_time.pod.in
+++ b/doc/man1/openssl-s_time.pod.in
@@ -157,14 +157,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<openssl-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<openssl-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/openssl-sess_id.pod.in b/doc/man1/openssl-sess_id.pod.in
index 1318283028..67cc0e7e2d 100644
--- a/doc/man1/openssl-sess_id.pod.in
+++ b/doc/man1/openssl-sess_id.pod.in
@@ -136,7 +136,7 @@ This is the return code when an SSL client certificate is verified.
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/openssl.pod b/doc/man1/openssl.pod
index dee181d264..dbab509be4 100644
--- a/doc/man1/openssl.pod
+++ b/doc/man1/openssl.pod
@@ -1125,7 +1125,7 @@ a string and leading or trailing spaces.
=item B<esc_2254>
Escape the "special" characters in a field as required by RFC 2254 in a field.
-That is, the B<NUL> character and and of C<()*>.
+That is, the B<NUL> character and of C<()*>.
=item B<esc_ctrl>
diff --git a/doc/man3/ASN1_INTEGER_get_int64.pod b/doc/man3/ASN1_INTEGER_get_int64.pod
index 53a9143800..49f7ca3ac0 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 e3cf8bb2d0..909a3af1ca 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_TYPE_get.pod b/doc/man3/ASN1_TYPE_get.pod
index a7a3083aa1..c34572345f 100644
--- a/doc/man3/ASN1_TYPE_get.pod
+++ b/doc/man3/ASN1_TYPE_get.pod
@@ -68,7 +68,7 @@ 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 nonzero. Technically if both parameters are NULL the two
-types could be absent OPTIONAL fields and so should match, however passing
+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.
diff --git a/doc/man3/ASYNC_WAIT_CTX_new.pod b/doc/man3/ASYNC_WAIT_CTX_new.pod
index 62eef297d8..ad6fe31a55 100644
--- a/doc/man3/ASYNC_WAIT_CTX_new.pod
+++ b/doc/man3/ASYNC_WAIT_CTX_new.pod
@@ -67,7 +67,7 @@ associated with that job in I<*fd>. The number of file descriptors returned will
be stored in I<*numfds>. It is the caller's responsibility to ensure that
sufficient memory has been allocated in I<*fd> to receive all the file
descriptors. Calling ASYNC_WAIT_CTX_get_all_fds() with a NULL I<fd> value will
-return no file descriptors but will still populate I<*numfds>. Therefore
+return no file descriptors but will still populate I<*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
@@ -195,7 +195,7 @@ ASYNC_WAIT_CTX_get_status() returns the engine status.
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 d4c6a19e61..24ef7fcbf2 100644
--- a/doc/man3/ASYNC_start_job.pod
+++ b/doc/man3/ASYNC_start_job.pod
@@ -170,7 +170,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 adea85e1c9..b4a335076d 100644
--- a/doc/man3/BF_encrypt.pod
+++ b/doc/man3/BF_encrypt.pod
@@ -68,7 +68,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 73c2819985..bcd83b5a14 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 404dd77e08..e1fe5a8e0d 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_ctrl.pod b/doc/man3/BIO_ctrl.pod
index c8e3386375..5cff74f10e 100644
--- a/doc/man3/BIO_ctrl.pod
+++ b/doc/man3/BIO_ctrl.pod
@@ -123,7 +123,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_s_bio.pod b/doc/man3/BIO_s_bio.pod
index 0f4ea77d6d..a5a66c5e8f 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
diff --git a/doc/man3/BIO_set_callback.pod b/doc/man3/BIO_set_callback.pod
index eb329f527b..975fef78d2 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/CMS_verify.pod b/doc/man3/CMS_verify.pod
index a3dfb420b0..d56540290f 100644
--- a/doc/man3/CMS_verify.pod
+++ b/doc/man3/CMS_verify.pod
@@ -98,7 +98,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 ab7ff878be..dd0d21a9de 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/DH_set_method.pod b/doc/man3/DH_set_method.pod
index ef8dbbcb4c..4782a766d4 100644
--- a/doc/man3/DH_set_method.pod
+++ b/doc/man3/DH_set_method.pod
@@ -52,7 +52,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.
diff --git a/doc/man3/DSA_set_method.pod b/doc/man3/DSA_set_method.pod
index 0895e7ad0b..2a3f111b31 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(3)> for information on constructing custom DSA_METHOD
diff --git a/doc/man3/DTLSv1_listen.pod b/doc/man3/DTLSv1_listen.pod
index ebbb9b8bc6..cb4c73d41a 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.
diff --git a/doc/man3/ECDSA_SIG_new.pod b/doc/man3/ECDSA_SIG_new.pod
index f9f62543d8..6b31cbaf0a 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
diff --git a/doc/man3/EC_GROUP_new.pod b/doc/man3/EC_GROUP_new.pod
index 76fed3b246..2866b32c33 100644
--- a/doc/man3/EC_GROUP_new.pod
+++ b/doc/man3/EC_GROUP_new.pod
@@ -99,7 +99,7 @@ I<params>.
EC_GROUP_set_curve() sets the curve parameters I<p>, I<a> and I<b>. For a curve
over Fp I<p> is the prime for the field. For a curve over F2^m I<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, I<a> and I<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 84b11ee0c0..83b61feb7f 100644
--- a/doc/man3/EC_POINT_new.pod
+++ b/doc/man3/EC_POINT_new.pod
@@ -156,7 +156,7 @@ above maps in such rare circumstances.
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 307540d3e1..1d07f5df83 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,7 +252,7 @@ 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 nonzero to indicate that the ENGINE is now operational and will
have allocated a new B<functional> reference to the ENGINE. All functional
@@ -260,7 +260,7 @@ 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
@@ -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/EVP_DigestInit.pod b/doc/man3/EVP_DigestInit.pod
index 370b685bf8..3308ebe500 100644
--- a/doc/man3/EVP_DigestInit.pod
+++ b/doc/man3/EVP_DigestInit.pod
@@ -101,7 +101,7 @@ EVP_MD_do_all_provided
=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 digest-specific functions.
The B<EVP_MD> type is a structure for digest method implementation.
@@ -536,7 +536,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 68391dd1ff..69dec1c74d 100644
--- a/doc/man3/EVP_DigestSignInit.pod
+++ b/doc/man3/EVP_DigestSignInit.pod
@@ -23,7 +23,7 @@ EVP_DigestSignFinal, 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.
Input data is digested first before the signing takes place.
EVP_DigestSignInit_ex() sets up signing context I<ctx> to use a digest with the
@@ -37,7 +37,7 @@ the properties to be used during the fetch.
The I<pkey> algorithm is used to fetch a B<EVP_SIGNATURE> method implicitly, to
be used for the actual signing. See L<provider(7)/Implicit fetch> for
-more information about implict fetches.
+more information about implicit fetches.
The OpenSSL default and legacy providers support fetching digests and can fetch
those digests from any available provider. The OpenSSL fips provider also
@@ -138,7 +138,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 617178bd19..9ea0014a5a 100644
--- a/doc/man3/EVP_DigestVerifyInit.pod
+++ b/doc/man3/EVP_DigestVerifyInit.pod
@@ -22,7 +22,7 @@ EVP_DigestVerifyFinal, 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.
Input data is digested first before the signature verification takes place.
EVP_DigestVerifyInit_ex() sets up verification context B<ctx> to use a digest
@@ -36,7 +36,7 @@ for the properties to be used during the fetch.
The I<pkey> algorithm is used to fetch a B<EVP_SIGNATURE> method implicitly, to
be used for the actual signing. See L<provider(7)/Implicit fetch> for
-more information about implict fetches.
+more information about implicit fetches.
The OpenSSL default and legacy providers support fetching digests and can fetch
those digests from any available provider. The OpenSSL fips provider also
@@ -130,7 +130,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 0a8cbaab71..b0d00fa4b5 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 88d0e7dabc..36efb4090d 100644
--- a/doc/man3/EVP_EncryptInit.pod
+++ b/doc/man3/EVP_EncryptInit.pod
@@ -165,7 +165,7 @@ EVP_CIPHER_do_all_provided
=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.
The B<EVP_CIPHER> type is a structure for cipher method implementation.
@@ -558,7 +558,7 @@ 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
+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.
@@ -642,10 +642,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_KDF.pod b/doc/man3/EVP_KDF.pod
index 7d6228a73d..5bf7994de8 100644
--- a/doc/man3/EVP_KDF.pod
+++ b/doc/man3/EVP_KDF.pod
@@ -48,7 +48,7 @@ EVP_KDF_gettable_params - EVP KDF routines
=head1 DESCRIPTION
-The EVP KDF routines are a high level interface to Key Derivation Function
+The EVP KDF routines are a high-level interface to Key Derivation Function
algorithms and should be used instead of algorithm-specific functions.
After creating a B<EVP_KDF_CTX> for the required algorithm using
diff --git a/doc/man3/EVP_OpenInit.pod b/doc/man3/EVP_OpenInit.pod
index b9a7aee738..b84f767245 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_new.pod b/doc/man3/EVP_PKEY_CTX_new.pod
index c3fc4c55ca..2634ee4a20 100644
--- a/doc/man3/EVP_PKEY_CTX_new.pod
+++ b/doc/man3/EVP_PKEY_CTX_new.pod
@@ -57,7 +57,7 @@ If I<ctx> is NULL, nothing is done.
=head2 On B<EVP_PKEY_CTX>
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_derive.pod b/doc/man3/EVP_PKEY_derive.pod
index 1bce4f3844..5bfb316382 100644
--- a/doc/man3/EVP_PKEY_derive.pod
+++ b/doc/man3/EVP_PKEY_derive.pod
@@ -19,7 +19,7 @@ EVP_PKEY_derive_init() initializes a public key algorithm context I<ctx> for
shared secret derivation using the algorithm given when the context was created
using L<EVP_PKEY_CTX_new(3)> or variants thereof. The algorithm is used to
fetch a B<EVP_KEYEXCH> method implicitly, see L<provider(7)/Implicit fetch> for
-more information about implict fetches.
+more information about implicit fetches.
EVP_PKEY_derive_set_peer() sets the peer key: this will normally
be a public key.
diff --git a/doc/man3/EVP_PKEY_fromdata.pod b/doc/man3/EVP_PKEY_fromdata.pod
index 526109386e..e3003674e3 100644
--- a/doc/man3/EVP_PKEY_fromdata.pod
+++ b/doc/man3/EVP_PKEY_fromdata.pod
@@ -22,7 +22,7 @@ The functions described here are used to create new keys from user
provided key data, such as I<n>, I<e> and I<d> for a minimal RSA
keypair.
-These functions use an B<EVP_PKEY_CTX> context, which should primarly
+These functions use an B<EVP_PKEY_CTX> context, which should primarily
be created with L<EVP_PKEY_CTX_new_from_name(3)> or
L<EVP_PKEY_CTX_new_id(3)>.
diff --git a/doc/man3/EVP_PKEY_sign.pod b/doc/man3/EVP_PKEY_sign.pod
index a11c1c6813..bd65bd9237 100644
--- a/doc/man3/EVP_PKEY_sign.pod
+++ b/doc/man3/EVP_PKEY_sign.pod
@@ -20,7 +20,7 @@ EVP_PKEY_sign_init() initializes a public key algorithm context I<ctx> for
signing using the algorithm given when the context was created
using L<EVP_PKEY_CTX_new(3)> or variants thereof. The algorithm is used to
fetch a B<EVP_SIGNATURE> method implicitly, see L<provider(7)/Implicit fetch>
-for more information about implict fetches.
+for more information about implicit fetches.
The EVP_PKEY_sign() function performs a public key signing operation
using I<ctx>. The data to be signed is specified using the I<tbs> and
diff --git a/doc/man3/EVP_PKEY_verify.pod b/doc/man3/EVP_PKEY_verify.pod
index b44da85c4c..c41525246a 100644
--- a/doc/man3/EVP_PKEY_verify.pod
+++ b/doc/man3/EVP_PKEY_verify.pod
@@ -20,7 +20,7 @@ EVP_PKEY_verify_init() initializes a public key algorithm context I<ctx> for
signing using the algorithm given when the context was created
using L<EVP_PKEY_CTX_new(3)> or variants thereof. The algorithm is used to
fetch a B<EVP_SIGNATURE> method implicitly, see L<provider(7)/Implicit fetch>
-for more information about implict fetches.
+for more information about implicit fetches.
The EVP_PKEY_verify() function performs a public key verification operation
using I<ctx>. The signature is specified using the I<sig> and
diff --git a/doc/man3/EVP_PKEY_verify_recover.pod b/doc/man3/EVP_PKEY_verify_recover.pod
index 8be999333b..bde2d3a8c1 100644
--- a/doc/man3/EVP_PKEY_verify_recover.pod
+++ b/doc/man3/EVP_PKEY_verify_recover.pod
@@ -20,7 +20,7 @@ EVP_PKEY_verify_recover_init() initializes a public key algorithm context
I<ctx> for signing using the algorithm given when the context was created
using L<EVP_PKEY_CTX_new(3)> or variants thereof. The algorithm is used to
fetch a B<EVP_SIGNATURE> method implicitly, see L<provider(7)/Implicit fetch>
-for more information about implict fetches.
+for more information about implicit fetches.
The EVP_PKEY_verify_recover() function recovers signed data
using I<ctx>. The signature is specified using the I<sig> and
diff --git a/doc/man3/EVP_RAND.pod b/doc/man3/EVP_RAND.pod
index c79f5e6548..5cf62fa359 100644
--- a/doc/man3/EVP_RAND.pod
+++ b/doc/man3/EVP_RAND.pod
@@ -71,7 +71,7 @@ EVP_RAND_STATE_ERROR - EVP RAND routines
=head1 DESCRIPTION
-The EVP RAND routines are a high level interface to random number generators
+The EVP RAND routines are a high-level interface to random number generators
both deterministic and not.
If you just want to generate random bytes then you don't need to use
these functions: just call RAND_bytes() or RAND_priv_bytes().
@@ -204,7 +204,7 @@ States defined by the OpenSSL DRBGs are:
=item *
-EVP_RAND_STATE_UNINITIALISED: this DRBG is currently uninitalised.
+EVP_RAND_STATE_UNINITIALISED: this DRBG is currently uninitialised.
The instantiate call will change this to the ready state.
=item *
@@ -343,7 +343,7 @@ EVP_RAND_CTX_free() does not return a value.
EVP_RAND_nonce() returns the length of the nonce.
-EVP_RAND_strength() returns the strenght of the random number generator in bits.
+EVP_RAND_strength() returns the strength of the random number generator in bits.
EVP_RAND_gettable_params(), EVP_RAND_gettable_ctx_params() and
EVP_RAND_settable_ctx_params() return an array of OSSL_PARAMs.
diff --git a/doc/man3/EVP_SealInit.pod b/doc/man3/EVP_SealInit.pod
index 73d9bb7531..35f2d876ae 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 4bdd4fbe50..13bba5b507 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 50afdcf8ce..deb9b387de 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/EVP_set_default_properties.pod b/doc/man3/EVP_set_default_properties.pod
index 9135742bb2..e22f5c3e99 100644
--- a/doc/man3/EVP_set_default_properties.pod
+++ b/doc/man3/EVP_set_default_properties.pod
@@ -41,7 +41,7 @@ property for the given I<libctx>.
=head1 RETURN VALUES
EVP_set_default_properties() and EVP_default_properties_enable_fips() return 1
-on success, or 0 on failure. An error is placed on the the error stack if a
+on success, or 0 on failure. An error is placed on the error stack if a
failure occurs.
EVP_default_properties_is_fips_enabled() returns 1 if the 'fips=yes' default
diff --git a/doc/man3/OPENSSL_LH_COMPFUNC.pod b/doc/man3/OPENSSL_LH_COMPFUNC.pod
index 412a4f8800..c1eb68d081 100644
--- a/doc/man3/OPENSSL_LH_COMPFUNC.pod
+++ b/doc/man3/OPENSSL_LH_COMPFUNC.pod
@@ -203,7 +203,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 b75c137087..bc5510fac9 100644
--- a/doc/man3/OPENSSL_config.pod
+++ b/doc/man3/OPENSSL_config.pod
@@ -43,7 +43,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 d7c40d0b41..f3192454e3 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_s390xcap.pod b/doc/man3/OPENSSL_s390xcap.pod
index 6d5326191c..3eb5d1ad8a 100644
--- a/doc/man3/OPENSSL_s390xcap.pod
+++ b/doc/man3/OPENSSL_s390xcap.pod
@@ -179,7 +179,7 @@ Disables the vector facility:
OPENSSL_s390xcap="stfle:~0:~0:~0x4000000000000000"
-Disables the KM-XTS-AES and and the KIMD-SHAKE function codes:
+Disables the KM-XTS-AES and the KIMD-SHAKE function codes:
OPENSSL_s390xcap="km:~0x2800:~0;kimd:~0xc000000:~0"
diff --git a/doc/man3/OSSL_CMP_log_open.pod b/doc/man3/OSSL_CMP_log_open.pod
index 0f67f2ae18..fdc416c0cf 100644
--- a/doc/man3/OSSL_CMP_log_open.pod
+++ b/doc/man3/OSSL_CMP_log_open.pod
@@ -68,7 +68,7 @@ a severity level, and
a message string describing the nature of the event, terminated by '\n'.
Even when an activity is successful some warnings may be useful and some degree
-of auditing may be required. Therefore the logging facility supports a severity
+of auditing may be required. Therefore, the logging facility supports a severity
level and the callback function has a B<level> parameter indicating such a
level, such that error, warning, info, debug, etc. can be treated differently.
The callback is activated only when the severity level is sufficient according
@@ -76,7 +76,7 @@ to the current level of verbosity, which by default is OSSL_CMP_LOG_INFO.
The callback function may itself do non-trivial tasks like writing to
a log file or remote stream, which in turn may fail.
-Therefore the function should return 1 on success and 0 on failure.
+Therefore, the function should return 1 on success and 0 on failure.
OSSL_CMP_log_open() initializes the CMP-specific logging facility to output
everything to STDOUT. It fails if the integrated tracing is disabled or STDIO
diff --git a/doc/man3/OSSL_PARAM_int.pod b/doc/man3/OSSL_PARAM_int.pod
index 7aa6b9377f..6712a07327 100644
--- a/doc/man3/OSSL_PARAM_int.pod
+++ b/doc/man3/OSSL_PARAM_int.pod
@@ -187,12 +187,12 @@ OSSL_PARAM_construct_octet_string() is a function that constructs an OCTET
string OSSL_PARAM structure.
A parameter with name B<key>, storage B<buf> and size B<bsize> is created.
-OSSL_PARAM_construct_utf8_ptr() is a function that constructes a UTF string
+OSSL_PARAM_construct_utf8_ptr() is a function that constructs a UTF string
pointer OSSL_PARAM structure.
A parameter with name B<key>, storage pointer B<*buf> and size B<bsize>
is created.
-OSSL_PARAM_construct_octet_ptr() is a function that constructes an OCTET string
+OSSL_PARAM_construct_octet_ptr() is a function that constructs an OCTET string
pointer OSSL_PARAM structure.
A parameter with name B<key>, storage pointer B<*buf> and size B<bsize>
is created.
diff --git a/doc/man3/OSSL_SERIALIZER_CTX_new_by_EVP_PKEY.pod b/doc/man3/OSSL_SERIALIZER_CTX_new_by_EVP_PKEY.pod
index fa4ba0df4d..43dddbce02 100644
--- a/doc/man3/OSSL_SERIALIZER_CTX_new_by_EVP_PKEY.pod
+++ b/doc/man3/OSSL_SERIALIZER_CTX_new_by_EVP_PKEY.pod
@@ -121,7 +121,7 @@ name, thus making for the naming pattern
B<OSSL_SERIALIZER_CTX_new_by_I<TYPE>>() when new types are handled.
B<PUBKEY>, B<PrivateKey> and B<Parameters> in the macro names match
-the B<I<TYPE>> part of of B<PEM_write_bio_I<TYPE>> functions as well
+the B<I<TYPE>> part of B<PEM_write_bio_I<TYPE>> functions as well
as B<i2d_I<TYPE>_bio> functions.
=head1 SEE ALSO
diff --git a/doc/man3/PEM_read_bio_PrivateKey.pod b/doc/man3/PEM_read_bio_PrivateKey.pod
index 9b03d1a874..65ba8a8a83 100644
--- a/doc/man3/PEM_read_bio_PrivateKey.pod
+++ b/doc/man3/PEM_read_bio_PrivateKey.pod
@@ -215,7 +215,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.
@@ -402,7 +402,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 200464faeb..e43a769cb0 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_set_callbacks.pod b/doc/man3/RAND_DRBG_set_callbacks.pod
index 543b3cc911..53022c8194 100644
--- a/doc/man3/RAND_DRBG_set_callbacks.pod
+++ b/doc/man3/RAND_DRBG_set_callbacks.pod
@@ -64,7 +64,7 @@ callbacks using RAND_DRBG_get_callback_data().
The ownership of the context data remains with the caller, i.e., it is the
caller's responsibility to keep it available as long as it is needed by the
callbacks and free it after use.
-For more information about the the callback data see the NOTES section.
+For more information about the callback data see the NOTES section.
Setting the callbacks or the callback data is allowed only if the DRBG has
not been initialized yet.
@@ -91,7 +91,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/RSA_private_encrypt.pod b/doc/man3/RSA_private_encrypt.pod
index 9f83d50845..eaa7715bfb 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
@@ -24,7 +24,7 @@ Both of the functions described on this page are deprecated.
Applications should instead use L<EVP_PKEY_encrypt_init(3)>,
L<EVP_PKEY_encrypt(3)>, L<EVP_PKEY_decrypt_init(3)> and L<EVP_PKEY_decrypt(3)>.
-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 88ea74921d..884765ce97 100644
--- a/doc/man3/RSA_set_method.pod
+++ b/doc/man3/RSA_set_method.pod
@@ -58,7 +58,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/SRP_create_verifier.pod b/doc/man3/SRP_create_verifier.pod
index b235fb6a4a..18c7308533 100644
--- a/doc/man3/SRP_create_verifier.pod
+++ b/doc/man3/SRP_create_verifier.pod
@@ -75,7 +75,7 @@ non-NULL value on success:
not be freed.
SRP_check_known_gN_param() returns the text representation of the group id
-(ie. the prime bit size) or NULL if the arguments are not valid SRP group parameters.
+(i.e. the prime bit size) or NULL if the arguments are not valid SRP group parameters.
This value should not be freed.
SRP_get_default_gN() returns NULL if I<id> is not a valid group size,
diff --git a/doc/man3/SSL_CONF_cmd.pod b/doc/man3/SSL_CONF_cmd.pod
index b060449390..753d6778df 100644
--- a/doc/man3/SSL_CONF_cmd.pod
+++ b/doc/man3/SSL_CONF_cmd.pod
@@ -141,7 +141,7 @@ for the B<key_share> sent by a client in a TLSv1.3 B<ClientHello>.
The B<groups> 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>, B<ffdhe2048>) or an OpenSSL OID name
-(e.g B<prime256v1>). Group names are case sensitive. The list should be
+(e.g. B<prime256v1>). Group names are case sensitive. The list should be
in order of preference with the most preferred group first.
Currently supported groups for B<TLSv1.3> are B<P-256>, B<P-384>, B<P-521>,
@@ -160,7 +160,7 @@ by servers.
The B<groups> 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> I<ciphers>
@@ -372,7 +372,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>, B<ffdhe2048>) or an OpenSSL OID name
-(e.g B<prime256v1>). Group names are case sensitive. The list should be in
+(e.g. B<prime256v1>). Group names are case sensitive. The list should be in
order of preference with the most preferred group first.
Currently supported groups for B<TLSv1.3> are B<P-256>, B<P-384>, B<P-521>,
diff --git a/doc/man3/SSL_CTX_set1_curves.pod b/doc/man3/SSL_CTX_set1_curves.pod
index b65f1b4816..5eebb2b933 100644
--- a/doc/man3/SSL_CTX_set1_curves.pod
+++ b/doc/man3/SSL_CTX_set1_curves.pod
@@ -35,7 +35,7 @@ SSL_set1_curves, SSL_set1_curves_list, SSL_get1_curves, SSL_get_shared_curve
For all of the functions below that set the supported groups there must be at
least one group in the list. A number of these functions identify groups via a
-unique integer NID value. However support for some groups may be added by
+unique integer NID value. However, support for some groups may be added by
external providers. In this case there will be no NID assigned for the group.
When setting such groups applications should use the "list" form of these
functions (i.e. SSL_CTX_set1_groups_list() and SSL_set1_groups_list).
diff --git a/doc/man3/SSL_CTX_set_generate_session_id.pod b/doc/man3/SSL_CTX_set_generate_session_id.pod
index d90b138f81..79b58de5ff 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_options.pod b/doc/man3/SSL_CTX_set_options.pod
index 24bf66ad85..1bf19ecd23 100644
--- a/doc/man3/SSL_CTX_set_options.pod
+++ b/doc/man3/SSL_CTX_set_options.pod
@@ -167,7 +167,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
diff --git a/doc/man3/SSL_CTX_set_psk_client_callback.pod b/doc/man3/SSL_CTX_set_psk_client_callback.pod
index c7e51f7441..23bab17317 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_session_cache_mode.pod b/doc/man3/SSL_CTX_set_session_cache_mode.pod
index 21a782d0f2..a4c5edbf02 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 ccc10a7e14..6b2bd70364 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 e7b82606c7..6bb12cddc3 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 a8af75f508..0ab84665bf 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 0c271b1f11..a0a4bd6367 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 69f7e9d4f8..e3802b74f0 100644
--- a/doc/man3/SSL_CTX_use_psk_identity_hint.pod
+++ b/doc/man3/SSL_CTX_use_psk_identity_hint.pod
@@ -126,7 +126,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_get_all_async_fds.pod b/doc/man3/SSL_get_all_async_fds.pod
index c0cf3f6fb7..d6ef72b0de 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 B<SSL>
object is currently waiting for asynchronous work to complete (i.e.
B<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
+the 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 I<*numfds> and the file descriptors themselves
are in I<*fds>. The I<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 07466731eb..0f2b10989e 100644
--- a/doc/man3/SSL_get_error.pod
+++ b/doc/man3/SSL_get_error.pod
@@ -74,7 +74,7 @@ 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.
+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.
@@ -84,7 +84,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 adc995212a..196912b6be 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 f5c02a35ad..b934df0d6a 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
diff --git a/doc/man3/SSL_read_early_data.pod b/doc/man3/SSL_read_early_data.pod
index 460a436eaa..13c3bcf6a6 100644
--- a/doc/man3/SSL_read_early_data.pod
+++ b/doc/man3/SSL_read_early_data.pod
@@ -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
@@ -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_set_bio.pod b/doc/man3/SSL_set_bio.pod
index 1c1ec6e7d3..9d9219c4b1 100644
--- a/doc/man3/SSL_set_bio.pod
+++ b/doc/man3/SSL_set_bio.pod
@@ -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.
@@ -78,10 +78,8 @@ and no references are consumed for the B<wbio>.
If the B<rbio> and B<wbio> parameters are different and the B<wbio>
is the same as the
previously set value and the old B<rbio> and B<wbio> values were different
-to each
-other then one reference is consumed for the B<rbio> and one reference
-is consumed
-for the B<wbio>.
+to each other, then one reference is consumed for the B<rbio> and one
+reference is consumed for the B<wbio>.
=back
diff --git a/doc/man3/UI_create_method.pod b/doc/man3/UI_create_method.pod
index 5508446d4f..8d15f1b029 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/X509V3_get_d2i.pod b/doc/man3/X509V3_get_d2i.pod
index 2b10f7527c..981eab14b8 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_LOOKUP_meth_new.pod b/doc/man3/X509_LOOKUP_meth_new.pod
index 9143607d9f..2021749935 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_new.pod b/doc/man3/X509_STORE_CTX_new.pod
index bc765c354b..e34be08b89 100644
--- a/doc/man3/X509_STORE_CTX_new.pod
+++ b/doc/man3/X509_STORE_CTX_new.pod
@@ -61,7 +61,7 @@ X509_STORE_CTX_new() is the same as X509_STORE_CTX_new_with_libctx() except that
the default library context and a NULL property query string are used.
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 I<ctx>. After this call I<ctx>
is no longer valid.
@@ -89,7 +89,7 @@ X509_STORE_CTX_set0_verified_chain() sets the validated chain used
by I<ctx> to be I<chain>.
Ownership of the chain is transferred to I<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
I<ctx> that contains the validated chain.
X509_STORE_CTX_set0_crls() sets a set of CRLs to use to aid certificate
@@ -142,7 +142,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 allocates context or B<NULL> is 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 3c081e1de7..cfde5ab5ba 100644
--- a/doc/man3/X509_STORE_CTX_set_verify_cb.pod
+++ b/doc/man3/X509_STORE_CTX_set_verify_cb.pod
@@ -50,7 +50,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_check_host.pod b/doc/man3/X509_check_host.pod
index 7732cb80f3..459c37652d 100644
--- a/doc/man3/X509_check_host.pod
+++ b/doc/man3/X509_check_host.pod
@@ -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/d2i_X509.pod b/doc/man3/d2i_X509.pod
index fdf6c1d669..971339bba0 100644
--- a/doc/man3/d2i_X509.pod
+++ b/doc/man3/d2i_X509.pod
@@ -472,7 +472,7 @@ populated B<I<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 zeros.
-Therefore any FILE pointers or BIOs should be opened in binary mode.
+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/x509v3_config.pod b/doc/man5/x509v3_config.pod
index 1fbef74615..45c4d92cf6 100644
--- a/doc/man5/x509v3_config.pod
+++ b/doc/man5/x509v3_config.pod
@@ -167,7 +167,7 @@ Examples:
This is a string extension with one of two legal values. If it is the word
B<hash>, then OpenSSL will follow the process in RFC 5280 to calculate the
hash value.
-Otherwise, the value should be a hex string to output directly, however this
+Otherwise, the value should be a hex string to output directly, however, this
is strongly discouraged.
Example:
diff --git a/doc/man7/EVP_KDF-KRB5KDF.pod b/doc/man7/EVP_KDF-KRB5KDF.pod
index 192ca3f34b..29a8c0f7b8 100644
--- a/doc/man7/EVP_KDF-KRB5KDF.pod
+++ b/doc/man7/EVP_KDF-KRB5KDF.pod
@@ -48,7 +48,7 @@ A context for KRB5KDF can be obtained by calling:
The output length of the KRB5KDF derivation is specified via the I<keylen>
parameter to the L<EVP_KDF_derive(3)> function, and MUST match the key
-length for the chosen cipher or an error is returned. Moreover the
+length for the chosen cipher or an error is returned. Moreover, the
constant's length must not exceed the block size of the cipher.
Since the KRB5KDF output length depends on the chosen cipher, calling
L<EVP_KDF_size(3)> to obtain the requisite length returns the correct length
diff --git a/doc/man7/EVP_PKEY-DH.pod b/doc/man7/EVP_PKEY-DH.pod
index f640753bfe..45d7c6ed5f 100644
--- a/doc/man7/EVP_PKEY-DH.pod
+++ b/doc/man7/EVP_PKEY-DH.pod
@@ -105,7 +105,7 @@ For "group" this can be any one of 2048, 3072, 4096, 6144 or 8192.
=item "priv_len" (B<OSSL_PKEY_PARAM_DH_PRIV_LEN>) <integer>
An optional value to set the maximum length of the generated private key.
-The default valure used if this is not set is the maximum value of
+The default value used if this is not set is the maximum value of
BN_num_bits(I<q>)). The minimum value that this can be set to is 2 * s.
Where s is the security strength of the key which has values of
112, 128, 152, 176 and 200 for key sizes of 2048, 3072, 4096, 6144 and 8192.
diff --git a/doc/man7/EVP_PKEY-X25519.pod b/doc/man7/EVP_PKEY-X25519.pod
index 2937f247f5..63760389c9 100644
--- a/doc/man7/EVP_PKEY-X25519.pod
+++ b/doc/man7/EVP_PKEY-X25519.pod
@@ -29,7 +29,7 @@ support the following.
=item "group" (B<OSSL_PKEY_PARAM_GROUP_NAME>) <UTF8 string>
This is only supported by X25519 and X448. The group name must be "x25519" or
-"x448" repsectively for those algorithms. This is only present for consistency
+"x448" respectively for those algorithms. This is only present for consistency
with other key exchange algorithms and is typically not needed.
=item "pub" (B<OSSL_PKEY_PARAM_PUB_KEY>) <octet string>
diff --git a/doc/man7/evp.pod b/doc/man7/evp.pod
index 3e810f3d3f..2a3a1a91dc 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/provider-base.pod b/doc/man7/provider-base.pod
index 35e9f6f614..d61645f961 100644
--- a/doc/man7/provider-base.pod
+++ b/doc/man7/provider-base.pod
@@ -237,7 +237,7 @@ it a set of B<OSSL_PARAM>s and the caller supplied argument I<arg>. The
B<OSSL_PARAM>s should provide details about the capability with the name given
in the I<capability> argument relevant for the provider context I<provctx>. If a
provider supports multiple capabilities with the given name then it may call the
-callback multipe times (one for each capability). Capabilities can be useful for
+callback multiple times (one for each capability). Capabilities can be useful for
describing the services that a provider can offer. For further details see the
L</CAPABILITIES> section below. It should return 1 on success or 0 on error.
@@ -346,7 +346,7 @@ L<OSSL_PARAM_int(3)>.
=head1 CAPABILITIES
-Capabilties describe some of the services that a provider can offer.
+Capabilities describe some of the services that a provider can offer.
Applications can query the capabilities to discover those services.
=head3 "TLS-GROUP" Capability
diff --git a/fuzz/README.md b/fuzz/README.md
index c8dbf454b0..a713f85325 100644
--- a/fuzz/README.md
+++ b/fuzz/README.md
@@ -154,7 +154,7 @@ Minimizing the corpus
---------------------
When you have gathered corpus data from more than one fuzzer run
-or for any other reason want to to minimize the data
+or for any other reason want to minimize the data
in some corpus subdirectory `fuzz/corpora/DIR` this can be done as follows:
mkdir fuzz/corpora/NEWDIR
diff --git a/util/find-doc-nits b/util/find-doc-nits
index a54d75458c..d2317459ec 100755
--- a/util/find-doc-nits
+++ b/util/find-doc-nits
@@ -551,6 +551,7 @@ sub functionname_check {
# This is from http://man7.org/linux/man-pages/man7/man-pages.7.html
my %preferred_words = (
+ 'a.k.a.' => 'aka',
'bitmask' => 'bit mask',
'builtin' => 'built-in',
#'epoch' => 'Epoch', # handled specially, below
More information about the openssl-commits
mailing list