Commit bd45afb5 authored by Damien Miller's avatar Damien Miller

- djm@cvs.openbsd.org 2008/06/28 07:25:07

     [PROTOCOL]
     spelling fixes
parent 8639920a
......@@ -31,6 +31,9 @@
- jmc@cvs.openbsd.org 2008/06/26 21:11:46
[ssh.1]
add VisualHostKey to the list of options listed in -o;
- djm@cvs.openbsd.org 2008/06/28 07:25:07
[PROTOCOL]
spelling fixes
20080628
- (djm) [RFC.nroff contrib/cygwin/Makefile contrib/suse/openssh.spec]
......@@ -4451,4 +4454,4 @@
OpenServer 6 and add osr5bigcrypt support so when someone migrates
passwords between UnixWare and OpenServer they will still work. OK dtucker@
$Id: ChangeLog,v 1.5030 2008/06/29 14:04:31 djm Exp $
$Id: ChangeLog,v 1.5031 2008/06/29 14:04:57 djm Exp $
......@@ -86,9 +86,9 @@ Note that this is not a general defence against compromised clients
5. connection: Tunnel forward extension "tun@openssh.com"
OpenSSH supports layer 2 and layer 3 tunneling via the "tun@openssh.com"
OpenSSH supports layer 2 and layer 3 tunnelling via the "tun@openssh.com"
channel type. This channel type supports forwarding of network packets
with datagram boundaries entact between endpoints equipped with
with datagram boundaries intact between endpoints equipped with
interfaces like the BSD tun(4) device. Tunnel forwarding channels are
requested by the client with the following packet:
......@@ -142,13 +142,13 @@ The contents of the "data" field for layer 3 packets is:
uint32 packet length
byte[packet length] frame
The "frame" field contains an IEEE 802.3 ethernet frame, including
The "frame" field contains an IEEE 802.3 Ethernet frame, including
header.
6. sftp: Reversal of arguments to SSH_FXP_SYMLINK
When OpenSSH's sftp-server was implemented, the order of the arguments
to the SSH_FXP_SYMLINK method was inadvertendly reversed. Unfortunately,
to the SSH_FXP_SYMLINK method was inadvertently reversed. Unfortunately,
the reversal was not noticed until the server was widely deployed. Since
fixing this to follow the specification would cause incompatibility, the
current order was retained. For correct operation, clients should send
......@@ -177,7 +177,7 @@ Each extension reports its integer version number as an ASCII encoded
string, e.g. "1". The version will be incremented if the extension is
ever changed in an incompatible way. The server MAY advertise the same
extension with multiple versions (though this is unlikely). Clients MUST
check the version number before attemping to use the extension.
check the version number before attempting to use the extension.
8. sftp: Extension request "posix-rename@openssh.com"
......@@ -207,7 +207,7 @@ pathname, and is formatted as follows:
string "statvfs@openssh.com"
string path
The "fstatvfs@openssh.com" operates on an open filehandle:
The "fstatvfs@openssh.com" operates on an open file handle:
uint32 id
string "fstatvfs@openssh.com"
......@@ -237,4 +237,4 @@ The values of the f_flag bitmask are as follows:
This extension is advertised in the SSH_FXP_VERSION hello with version
"2".
$OpenBSD: PROTOCOL,v 1.7 2008/06/12 05:15:41 djm Exp $
$OpenBSD: PROTOCOL,v 1.8 2008/06/28 07:25:07 djm Exp $
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment