[openssl-commits] [web] master update

Rich Salz rsalz at openssl.org
Sat Jul 9 14:43:29 UTC 2016


The branch master has been updated
       via  0a8349f479ea52acab7c73525838c7656fe57af2 (commit)
       via  c8f9586932d60d254389b1064f4374baff8c0ea6 (commit)
      from  a0c1d3d6671b58a6ccbfdffbc6ffc014ec55f39e (commit)


- Log -----------------------------------------------------------------
commit 0a8349f479ea52acab7c73525838c7656fe57af2
Author: Rich Salz <rsalz at akamai.com>
Date:   Sat Jul 9 10:43:18 2016 -0400

    Typo fixes from FdaSilvaYY

commit c8f9586932d60d254389b1064f4374baff8c0ea6
Author: FdaSilvaYY <fdasilvayy at gmail.com>
Date:   Sat Jul 9 09:19:15 2016 +0200

    Fix some typo

-----------------------------------------------------------------------

Summary of changes:
 docs/faq.txt             | 4 ++--
 docs/fipsnotes.html      | 2 +-
 docs/standards.html      | 6 +++---
 news/changelog.html      | 2 +-
 policies/cla.html        | 2 +-
 policies/codingstyle.txt | 2 +-
 policies/secpolicy.html  | 4 ++--
 7 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/docs/faq.txt b/docs/faq.txt
index 569890a..8bbabcb 100644
--- a/docs/faq.txt
+++ b/docs/faq.txt
@@ -414,7 +414,7 @@ whatever name they choose.
 
 The ways to print out the oneline format of the DN (Distinguished Name) have
 been extended in version 0.9.7 of OpenSSL. Using the new X509_NAME_print_ex()
-interface, the "-nameopt" option could be introduded. See the manual
+interface, the "-nameopt" option could be introduced. See the manual
 page of the "openssl x509" command line tool for details. The old behaviour
 has however been left as default for the sake of compatibility.
 
@@ -466,7 +466,7 @@ The purpose of this extension is to identify the authority certificate B. This
 can be done either by including the subject key identifier of B or its issuer
 name and serial number.
 
-In this latter case because it is identifying certifcate B it must contain the
+In this latter case because it is identifying certificate B it must contain the
 issuer name and serial number of B.
 
 It is often wrongly assumed that it should contain the subject name of B. If it
diff --git a/docs/fipsnotes.html b/docs/fipsnotes.html
index c3726b1..ec9a39c 100644
--- a/docs/fipsnotes.html
+++ b/docs/fipsnotes.html
@@ -58,7 +58,7 @@
 	    above summary does not adequately address.  You have been
 	    warned!</p>
 
-	    <h2><a name="privatelable">The "Private Label" Validation</a></h2>
+	    <h2><a name="privatelabel">The "Private Label" Validation</a></h2>
 
 	    <p>We refer to validations based directly on the OpenSSL FIPS
 	    Object Module as "private label" validations.  These are also
diff --git a/docs/standards.html b/docs/standards.html
index cfda3a9..9234652 100644
--- a/docs/standards.html
+++ b/docs/standards.html
@@ -75,11 +75,11 @@
               href="https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=pkcs11">PKCS#11:</a>
             Standards for Cryptographic Tokens</li>
               <li><a href="https://tools.ietf.org/html/rfc4346">RFC 4346:</a>
-              The Transport Layer Security (TLS) Protocol Vresion 1.1</li>
+              The Transport Layer Security (TLS) Protocol Version 1.1</li>
               <li><a href="https://tools.ietf.org/html/rfc5208">RFC 5208</a>:
               PKCS#8: Private-Key Information Syntax Specification Version 1.2</li>
               <li><a href="https://tools.ietf.org/html/rfc5246">RFC 5246:</a>
-              The Transport Layer Security (TLS) Protocol Vresion 1.2</li>
+              The Transport Layer Security (TLS) Protocol Version 1.2</li>
               <li><a href="https://tools.ietf.org/html/rfc6962">RFC 6962</a>:
               Certificate Transparency</li>
               <li><a href="https://tools.ietf.org/html/rfc7292">RFC 7292</a>:
@@ -195,7 +195,7 @@
 	  </div>
 	  <footer>
 	    You are here: <a href="/">Home</a>
-	    : <a href=".">Dcoumentation</a>
+	    : <a href=".">Documentation</a>
 	    : <a href="">Standards</a>
 	    <br/><a href="/sitemap.txt">Sitemap</a>
 	  </footer>
diff --git a/news/changelog.html b/news/changelog.html
index 6cdc9fa..b21a738 100644
--- a/news/changelog.html
+++ b/news/changelog.html
@@ -21,7 +21,7 @@
             </p>
             <p>
             This is the changelog for the master branch, the one that is
-            currenty in active development.
+            currently in active development.
 	    The plain-text version of this document is available
 	    here: <a href="changelog.txt">changelog.txt</a>
             </p>
diff --git a/policies/cla.html b/policies/cla.html
index a13319c..e9526bc 100644
--- a/policies/cla.html
+++ b/policies/cla.html
@@ -17,7 +17,7 @@
 	    we will soon require almost every
 	    contributor to have a signed Contributor License Agreement (CLA)
 	    on file.  We are following the practice of
-	    <a href="https://www.apache.org">the Apache Sofware Foundation</a>.
+	    <a href="https://www.apache.org">the Apache Software Foundation</a>.
 	    You can see their CLA policy
 	    <a href="https://www.apache.org/licenses/#clas">here</a>.
 	  Or, you can just read the following paragraphs :)
diff --git a/policies/codingstyle.txt b/policies/codingstyle.txt
index 2333cfb..9be0b7d 100644
--- a/policies/codingstyle.txt
+++ b/policies/codingstyle.txt
@@ -352,7 +352,7 @@ The preferred style for long (multi-line) comments is:
      * with beginning and ending almost-blank lines.
      */
 
-Note the initial hypen to prevent indent from modifying the comment.
+Note the initial hyphen to prevent indent from modifying the comment.
 Use this if the comment has particular formatting that must be preserved.
 
 It's also important to comment data, whether they are basic types or
diff --git a/policies/secpolicy.html b/policies/secpolicy.html
index e75ca67..c17f08a 100644
--- a/policies/secpolicy.html
+++ b/policies/secpolicy.html
@@ -157,7 +157,7 @@
 	    because past experience has shown that they can add value to our
 	    understanding of the issue and the ability to test patches.  In
 	    cases where protocols are affected this is the best way to
-	    mitigate the risk that a poorly reviewed update causes signficiant
+	    mitigate the risk that a poorly reviewed update causes significant
 	    breakage, or to detect if issues are being exploited in the wild.
 	    We have a strict policy on what these organisations and
 	    individuals can do with the information and will review the need
@@ -168,7 +168,7 @@
 	    <p>Where we are planning an update that fixes security issues
 	    we will notify the openssl-announce list and update the home
 	    page to give our scheduled update release date and time and
-	    the severity of issues being fixed by the update.  No futher
+	    the severity of issues being fixed by the update.  No further
 	    information about the issues will be given.  This is to aid
 	    organisations that need to ensure they have staff available
 	    to handle triaging our announcement and what it means to


More information about the openssl-commits mailing list