Fix spelling errors in manpages
authorJosh Soref <jsoref@users.noreply.github.com>
Fri, 19 May 2017 00:16:38 +0000 (00:16 +0000)
committerRich Salz <rsalz@openssl.org>
Sun, 11 Jun 2017 20:21:33 +0000 (16:21 -0400)
spelling: algorithm
spelling: anyway
spelling: assigned
spelling: authenticated
spelling: callback
spelling: certificate
spelling: compatibility
spelling: configuration
spelling: digest
spelling: encrypted
spelling: function
spelling: output
spelling: receive
spelling: renegotiation
spelling: signing
spelling: similar
spelling: string

(Merged from https://github.com/openssl/openssl/pull/3580)Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3580)

16 files changed:
doc/man1/cms.pod
doc/man3/BIO_set_callback.pod
doc/man3/EVP_DigestSignInit.pod
doc/man3/EVP_DigestVerifyInit.pod
doc/man3/PKCS7_sign.pod
doc/man3/PKCS7_sign_add_signer.pod
doc/man3/SSL_CTX_config.pod
doc/man3/SSL_CTX_set_early_cb.pod
doc/man3/SSL_CTX_set_record_padding_callback.pod
doc/man3/SSL_key_update.pod
doc/man3/SSL_read_early_data.pod
doc/man3/SSL_write.pod
doc/man3/X509_get0_notBefore.pod
doc/man3/d2i_X509.pod
doc/man5/x509v3_config.pod
doc/man7/RSA-PSS.pod

index 21e5bde..c63ac45 100644 (file)
@@ -185,7 +185,7 @@ output an error.
 =item B<-EncryptedData_encrypt>
 
 Encrypt content using supplied symmetric key and algorithm using a CMS
-B<EncrytedData> type and output the content.
+B<EncryptedData> type and output the content.
 
 =item B<-sign_receipt>
 
index ac017e7..c6a6267 100644 (file)
@@ -20,8 +20,8 @@ BIO_callback_fn_ex, BIO_callback_fn
  void BIO_set_callback_ex(BIO *b, BIO_callback_fn_ex callback);
  BIO_callback_fn_ex BIO_get_callback_ex(const BIO *b);
 
- void BIO_set_callback(BIO *b, BIO_callack_fn cb);
- BIO_callack_fn BIO_get_callback(BIO *b);
+ void BIO_set_callback(BIO *b, BIO_callback_fn cb);
+ BIO_callback_fn BIO_get_callback(BIO *b);
  void BIO_set_callback_arg(BIO *b, char *arg);
  char *BIO_get_callback_arg(const BIO *b);
 
@@ -37,7 +37,7 @@ operation.
 
 BIO_set_callback() and BIO_get_callback() set and retrieve the old format BIO
 callback. New code should not use these functions, but they are retained for
-backwards compatbility. Any callback set via BIO_set_callback_ex() will get
+backwards compatibility. Any callback set via BIO_set_callback_ex() will get
 called in preference to any set by BIO_set_callback().
 
 BIO_set_callback_arg() and BIO_get_callback_arg() are macros which can be
index 4990eee..1f1a06c 100644 (file)
@@ -41,7 +41,7 @@ call is successful the signature is written to B<sig> and the amount of data
 written to B<siglen>.
 
 EVP_DigestSign() signs B<tbslen> bytes of data at B<tbs> and places the
-signature in B<sig> and its length in B<siglen> in a simiilar way to
+signature in B<sig> and its length in B<siglen> in a similar way to
 EVP_DigestSignFinal().
 
 =head1 RETURN VALUES
index a1f0473..481cea5 100644 (file)
@@ -35,7 +35,7 @@ using a macro.
 EVP_DigestVerifyFinal() verifies the data in B<ctx> against the signature in
 B<sig> of length B<siglen>.
 
-EVP_DogestVerify() verifies B<tbslen> bytes at B<tbs> against the signature
+EVP_DigestVerify() verifies B<tbslen> bytes at B<tbs> against the signature
 in B<sig> of length B<siglen>.
 
 =head1 RETURN VALUES
@@ -57,7 +57,7 @@ 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
 transparent to the algorithm used and much more flexible.
 
-EVP_DigesVerify() is a one shot operation which verifies a single block of
+EVP_DigestVerify() is a one shot operation which verifies a single block of
 data in one function. For algorithms that support streaming it is equivalent
 to calling EVP_DigestVerifyUpdate() and EVP_DigestVerifyFinal(). For
 algorithms which do not support streaming (e.g. PureEdDSA) it is the only way
index 567d7db..c1df5f1 100644 (file)
@@ -47,7 +47,7 @@ required by the S/MIME specifications) if B<PKCS7_BINARY> is set no translation
 occurs. This option should be used if the supplied data is in binary format
 otherwise the translation will corrupt it.
 
-The signedData structure includes several PKCS#7 autenticatedAttributes
+The signedData structure includes several PKCS#7 authenticatedAttributes
 including the signing time, the PKCS#7 content type and the supported list of
 ciphers in an SMIMECapabilities attribute. If B<PKCS7_NOATTR> is set then no
 authenticatedAttributes will be used. If B<PKCS7_NOSMIMECAP> is set then just
index 048a948..2bc6c40 100644 (file)
@@ -56,7 +56,7 @@ B<signcert> parameter though. This can reduce the size of the signature if the
 signers certificate can be obtained by other means: for example a previously
 signed message.
 
-The signedData structure includes several PKCS#7 autenticatedAttributes
+The signedData structure includes several PKCS#7 authenticatedAttributes
 including the signing time, the PKCS#7 content type and the supported list of
 ciphers in an SMIMECapabilities attribute. If B<PKCS7_NOATTR> is set then no
 authenticatedAttributes will be used. If B<PKCS7_NOSMIMECAP> is set then just
index 2506dd5..5b2aed7 100644 (file)
@@ -40,7 +40,8 @@ If the file "config.cnf" contains the following:
  testapp = test_sect
 
  [test_sect]
- # list of confuration modules
+ # list of configuration modules
+
  ssl_conf = ssl_sect
 
  [ssl_sect]
index 880576d..771e4ca 100644 (file)
@@ -82,7 +82,7 @@ SSL_early_isv2() returns 1 for SSLv2-format ClientHellos and 0 otherwise.
 
 SSL_early_get0_random(), SSL_early_get0_session_id(), SSL_early_get0_ciphers(),
 and SSL_early_get0_compression_methods() return the length of the corresponding
-ClientHello fields.  If zero is returned, the ouput pointer should not be
+ClientHello fields.  If zero is returned, the output pointer should not be
 assumed to be valid.
 
 SSL_early_get0_ext() returns 1 if the extension of type 'type' is present, and
index 9eea2bc..d0b2e30 100644 (file)
@@ -54,7 +54,7 @@ or SSL_set_record_padding_callback_arg().
 =head1 RETURN VALUES
 
 The SSL_CTX_get_record_padding_callback_arg() and SSL_get_record_padding_callback_arg()
-functions return the B<arg> value assignd in the corresponding set functions.
+functions return the B<arg> value assigned in the corresponding set functions.
 
 The SSL_CTX_set_block_padding() and SSL_set_block_padding() functions return 1 on success
 or 0 if B<block_size> is too large.
index 5b62234..7772b70 100644 (file)
@@ -74,7 +74,7 @@ new handshake. For historical reasons, DTLS clients will not attempt to resume
 the session in the new handshake.
 
 The SSL_renegotiate_pending() function returns 1 if a renegotiation or
-rengotiation request has been scheduled but not yet acted on, or 0 otherwise.
+renegotiation request has been scheduled but not yet acted on, or 0 otherwise.
 
 =head1 RETURN VALUES
 
@@ -84,7 +84,7 @@ on success or 0 on error.
 SSL_get_key_update_type() returns the update type of the pending key update
 operation or SSL_KEY_UPDATE_NONE if there is none.
 
-SSL_renegotiate_pending() returns 1 if a renegotiation or rengotiation request
+SSL_renegotiate_pending() returns 1 if a renegotiation or renegotiation request
 has been scheduled but not yet acted on, or 0 otherwise.
 
 =head1 SEE ALSO
index dd57cef..38dffe5 100644 (file)
@@ -30,7 +30,7 @@ SSL_get_early_data_status
 
 =head1 DESCRIPTION
 
-These functions are used to send and recieve early data where TLSv1.3 has been
+These functions are used to send and receive early data where TLSv1.3 has been
 negotiated. Early data can be sent by the client immediately after its initial
 ClientHello without having to wait for the server to complete the handshake.
 Early data can only be sent if a session has previously been established with
@@ -152,7 +152,7 @@ connection immediately without further need to call a function such as
 L<SSL_accept(3)>. This can happen if the client is using a protocol version less
 than TLSv1.3. Applications can test for this by calling
 L<SSL_is_init_finished(3)>. Alternatively, applications may choose to call
-L<SSL_accept(3)> anway. Such a call will successfully return immediately with no
+L<SSL_accept(3)> anyway. Such a call will successfully return immediately with no
 further action taken.
 
 When a session is created between a server and a client the server will specify
index 2a75110..14b651a 100644 (file)
@@ -25,7 +25,7 @@ SSL_write_ex(), or SSL_write().
 If necessary, a write function will negotiate a TLS/SSL session, if not already
 explicitly performed by L<SSL_connect(3)> or L<SSL_accept(3)>. If the peer
 requests a re-negotiation, it will be performed transparently during
-the write functio operation. The behaviour of the write functions depends on the
+the write function operation. The behaviour of the write functions depends on the
 underlying BIO.
 
 For the transparent negotiation to succeed, the B<ssl> must have been
index 82502f6..0427d41 100644 (file)
@@ -36,7 +36,7 @@ the call.
 X509_getm_notBefore() and X509_getm_notAfter() are similar to
 X509_get0_notBefore() and X509_get0_notAfter() except they return
 non-constant mutable references to the associated date field of
-the certficate.
+the certificate.
 
 X509_set1_notBefore() and X509_set1_notAfter() set the B<notBefore>
 and B<notAfter> fields of B<x> to B<tm>. Ownership of the passed
index f78d020..c4d89a8 100644 (file)
@@ -465,7 +465,7 @@ Represents a PKCS#1 RSA public key structure.
 
 =item B<X509_ALGOR>
 
-Represents an B<AlogrithmIdentifier> structure as used in IETF RFC 6960 and
+Represents an B<AlgorithmIdentifier> structure as used in IETF RFC 6960 and
 elsewhere.
 
 =item B<X509_Name>
index 0662326..59c3e96 100644 (file)
@@ -350,7 +350,7 @@ Example:
  noticeNumbers=1,2,3,4
 
 The B<ia5org> option changes the type of the I<organization> field. In RFC2459
-it can only be of type DisplayText. In RFC3280 IA5Strring is also permissible.
+it can only be of type DisplayText. In RFC3280 IA5String is also permissible.
 Some software (for example some versions of MSIE) may require ia5org.
 
 ASN1 type of explicitText can be specified by prepending B<UTF8>,
index 719789a..b608561 100644 (file)
@@ -28,7 +28,7 @@ but with some restrictions described below.
 
 =head1 SIGNING AND VERIFICATION
 
-Siging and verification is similar to the B<RSA> algorithm except the
+Signing and verification is similar to the B<RSA> algorithm except the
 padding mode is always PSS. If the key in use has parameter restrictions then
 the corresponding signature parameters are set to the restrictions:
 for example, if the key can only be used with digest SHA256, MGF1 SHA256