Potentially-incompatible changes

================================

This release includes a number of changes that may affect existing
configurations:

 * ssh-keygen(1): write OpenSSH format private keys by default
   instead of using OpenSSL's PEM format. The OpenSSH format,
   supported in OpenSSH releases since 2014 and described in the
   PROTOCOL.key file in the source distribution, offers substantially
   better protection against offline password guessing and supports
   key comments in private keys. If necessary, it is possible to write
   old PEM-style keys by adding "-m PEM" to ssh-keygen's arguments
   when generating or updating a key.

 * sshd(8): remove internal support for S/Key multiple factor
   authentication. S/Key may still be used via PAM or BSD auth.

 * ssh(1): remove vestigal support for running ssh(1) as setuid. This
   used to be required for hostbased authentication and the (long
   gone) rhosts-style authentication, but has not been necessary for
   a long time. Attempting to execute ssh as a setuid binary, or with
   uid != effective uid will now yield a fatal error at runtime.

 * sshd(8): the semantics of PubkeyAcceptedKeyTypes and the similar
   HostbasedAcceptedKeyTypes options have changed. These now specify
   signature algorithms that are accepted for their respective
   authentication mechanism, where previously they specified accepted
   key types. This distinction matters when using the RSA/SHA2
   signature algorithms "rsa-sha2-256", "rsa-sha2-512" and their
   certificate counterparts. Configurations that override these
   options but omit these algorithm names may cause unexpected
   authentication failures (no action is required for configurations
   that accept the default for these options).

 * sshd(8): the precedence of session environment variables has
   changed. ~/.ssh/environment and environment="..." options in
   authorized_keys files can no longer override SSH_* variables set
   implicitly by sshd.

 * ssh(1)/sshd(8): the default IPQoS used by ssh/sshd has changed.
   They will now use DSCP AF21 for interactive traffic and CS1 for
   bulk.  For a detailed rationale, please see the commit message:
   https://cvsweb.openbsd.org/src/usr.bin/ssh/readconf.c#rev1.284

crypto/external/bsd/openssh/dist/PROTOCOL.chacha20poly1305

@@ -16,7 +16,7 @@ that computes a 128 bit integrity tag given a message and a single-use
 The chacha20-poly1305@openssh.com combines these two primitives into an
 authenticated encryption mode. The construction used is based on that
 proposed for TLS by Adam Langley in [3], but differs in the layout of
-data passed to the MAC and in the addition of encyption of the packet
+data passed to the MAC and in the addition of encryption of the packet
 lengths.
 
 Negotiation
@@ -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.3 2016/05/03 13:10:24 djm Exp $
+$OpenBSD: PROTOCOL.chacha20poly1305,v 1.4 2018/04/10 00:10:49 djm Exp $
 

crypto/external/bsd/openssh/dist/PROTOCOL.krl

@@ -145,7 +145,7 @@ This section may appear multiple times.
 5. KRL signature sections
 
 The KRL_SECTION_SIGNATURE section serves a different purpose to the
-preceeding ones: to provide cryptographic authentication of a KRL that
+preceding ones: to provide cryptographic authentication of a KRL that
 is retrieved over a channel that does not provide integrity protection.
 Its format is slightly different to the previously-described sections:
 in order to simplify the signature generation, it includes as a "body"
@@ -166,4 +166,4 @@ Implementations that retrieve KRLs over untrusted channels must verify
 signatures. Signature sections are optional for KRLs distributed by
 trusted means.
 
-$OpenBSD: PROTOCOL.krl,v 1.3 2015/01/30 01:10:33 djm Exp $
+$OpenBSD: PROTOCOL.krl,v 1.4 2018/04/10 00:10:49 djm Exp $