[openssh-commits] [openssh] 03/04: upstream: Fix some typos and an incorrect word in docs. Patch from

[git+noreply at mindrot.org]

This is an automated email from the git hooks/post-receive script.

dtucker pushed a commit to branch master
in repository openssh.

commit 0001576a096f788d40c2c0a39121cff51bf961ad
Author: dtucker at openbsd.org <dtucker at openbsd.org>
Date:   Fri Feb 21 00:04:43 2020 +0000

    upstream: Fix some typos and an incorrect word in docs. Patch from
    
    itoama at live.jp via github PR#172.
    
    OpenBSD-Commit-ID: 166ee8f93a7201fef431b9001725ab8b269d5874
---
 PROTOCOL                  | 6 +++---
 PROTOCOL.chacha20poly1305 | 4 ++--
 PROTOCOL.u2f              | 4 ++--
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/PROTOCOL b/PROTOCOL
index f75c1c0a..c702fca4 100644
--- a/PROTOCOL
+++ b/PROTOCOL
@@ -194,7 +194,7 @@ layer 2 frames or layer 3 packets. It may take one of the following values:
 	SSH_TUNMODE_ETHERNET     2		/* layer 2 frames */
 
 The "tunnel unit number" specifies the remote interface number, or may
-be 0x7fffffff to allow the server to automatically chose an interface. A
+be 0x7fffffff to allow the server to automatically choose an interface. A
 server that is not willing to open a client-specified unit should refuse
 the request with a SSH_MSG_CHANNEL_OPEN_FAILURE error. On successful
 open, the server should reply with SSH_MSG_CHANNEL_OPEN_SUCCESS.
@@ -298,7 +298,7 @@ Upon receiving this message, a client should check which of the
 supplied host keys are present in known_hosts.
 
 Note that the server may send key types that the client does not
-support. The client should disgregard such keys if they are received.
+support. The client should disregard such keys if they are received.
 
 If the client identifies any keys that are not present for the host,
 it should send a "hostkeys-prove at openssh.com" message to request the
@@ -496,4 +496,4 @@ OpenSSH's connection multiplexing uses messages as described in
 PROTOCOL.mux over a Unix domain socket for communications between a
 master instance and later clients.
 
-$OpenBSD: PROTOCOL,v 1.36 2018/10/02 12:51:58 djm Exp $
+$OpenBSD: PROTOCOL,v 1.37 2020/02/21 00:04:43 dtucker Exp $
diff --git a/PROTOCOL.chacha20poly1305 b/PROTOCOL.chacha20poly1305
index 9ce2a1e3..0bfff28d 100644
--- a/PROTOCOL.chacha20poly1305
+++ b/PROTOCOL.chacha20poly1305
@@ -34,7 +34,7 @@ Detailed Construction
 The chacha20-poly1305 at openssh.com cipher requires 512 bits of key
 material as output from the SSH key exchange. This forms two 256 bit
 keys (K_1 and K_2), used by two separate instances of chacha20.
-The first 256 bits consitute K_2 and the second 256 bits become
+The first 256 bits constitute K_2 and the second 256 bits become
 K_1.
 
 The instance keyed by K_1 is a stream cipher that is used only
@@ -103,5 +103,5 @@ References
 [3] "ChaCha20 and Poly1305 based Cipher Suites for TLS", Adam Langley
     http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-03
 
-$OpenBSD: PROTOCOL.chacha20poly1305,v 1.4 2018/04/10 00:10:49 djm Exp $
+$OpenBSD: PROTOCOL.chacha20poly1305,v 1.5 2020/02/21 00:04:43 dtucker Exp $
 
diff --git a/PROTOCOL.u2f b/PROTOCOL.u2f
index 748111d5..45995870 100644
--- a/PROTOCOL.u2f
+++ b/PROTOCOL.u2f
@@ -142,7 +142,7 @@ choose not to include this information in the public key or save it by
 default.
 
 Attestation information is useful for out-of-band key and certificate
-registration worksflows, e.g. proving to a CA that a key is backed
+registration workflows, e.g. proving to a CA that a key is backed
 by trusted hardware before it will issue a certificate. To support this
 case, OpenSSH optionally allows retaining the attestation information
 at the time of key generation. It will take the following format:
@@ -169,7 +169,7 @@ is signed over a blob that consists of:
 	byte[]		extensions
 	byte[32]	SHA256(message)
 
-No extensons are yet defined for SSH use. If any are defined in the future,
+No extensions are yet defined for SSH use. If any are defined in the future,
 it will be possible to infer their presence from the contents of the "flags"
 value.
 

-- 
To stop receiving notification emails like this one, please contact
djm at mindrot.org.