merge upstream 0.71 tag (part 1)

https://git.tartarus.org/?p=simon/putty.git;a=commit;h=abfc751c3ee7d57bf3f127a458c40bb4ca2b6996

15 files changed, 743 insertions, 138 deletions

diff --git a/DOC/CONFIG.BUT b/DOC/CONFIG.BUT
index bd12efb2..96323ce6 100644
--- a/DOC/CONFIG.BUT
+++ b/DOC/CONFIG.BUT
@@ -246,6 +246,15 @@ warned that the log file may not always be up to date as a result
 (although it will of course be flushed when it is closed, for instance
 at the end of a session).
 
+\S{config-logheader} \I{log file, header}\q{Include header}
+
+\cfg{winhelp-topic}{logging.header}
+
+This option allows you to choose whether to include a header line
+with the date and time when the log file is opened. It may be useful to
+disable this if the log file is being used as realtime input to other
+programs that don't expect the header line.
+
 \S{config-logssh} Options specific to \i{SSH packet log}ging
 
 These options only apply if SSH packet data is being logged.
@@ -1381,31 +1390,47 @@ Note that this option only applies to line-drawing characters which
 characters that were received as Unicode code points will paste as
 Unicode always.
 
-\H{config-selection} The Selection panel
+\S{config-utf8linedraw} Combining VT100 line-drawing with UTF-8
 
-The Selection panel allows you to control the way \i{copy and paste}
-work in the PuTTY window.
+\cfg{winhelp-topic}{translation.utf8linedraw}
 
-\S{config-rtfpaste} Pasting in \i{Rich Text Format}
+If PuTTY is configured to treat data from the server as encoded in
+UTF-8, then by default it disables the older VT100-style system of
+control sequences that cause the lower-case letters to be temporarily
+replaced by line drawing characters.
 
-\cfg{winhelp-topic}{selection.rtf}
+The rationale is that in UTF-8 mode you don't need those control
+sequences anyway, because all the line-drawing characters they access
+are available as Unicode characters already, so there's no need for
+applications to put the terminal into a special state to get at them.
 
-If you enable \q{Paste to clipboard in RTF as well as plain text},
-PuTTY will write formatting information to the clipboard as well as
-the actual text you copy. The effect of this is
-that if you paste into (say) a word processor, the text will appear
-in the word processor in the same \i{font}, \i{colour}, and style 
-(e.g. bold, underline) PuTTY was using to display it.
+Also, it removes a risk of the terminal \e{accidentally} getting into
+that state: if you accidentally write uncontrolled binary data to a
+non-UTF-8 terminal, it can be surprisingly common to find that your
+next shell prompt appears as a sequence of line-drawing characters and
+then you have to remember or look up how to get out of that mode. So
+by default, UTF-8 mode simply doesn't \e{have} a confusing mode like
+that to get into, accidentally or on purpose.
 
-This option can easily be inconvenient, so by default it is
-disabled.
+However, not all applications will see it that way. Even UTF-8
+terminal users will still sometimes have to run software that tries to
+print line-drawing characters in the old-fashioned way. So the
+configuration option \q{Enable VT100 line drawing even in UTF-8 mode}
+puts PuTTY into a hybrid mode in which it understands the VT100-style
+control sequences that change the meaning of the ASCII lower case
+letters, \e{and} understands UTF-8.
+
+\H{config-selection} The Selection panel
+
+The Selection panel allows you to control the way \i{copy and paste}
+work in the PuTTY window.
 
 \S{config-mouse} Changing the actions of the mouse buttons
 
 \cfg{winhelp-topic}{selection.buttons}
 
 PuTTY's copy and paste mechanism is by default modelled on the Unix
-\c{xterm} application. The X Window System uses a three-button mouse,
+\i\c{xterm} application. The X Window System uses a three-button mouse,
 and the convention is that the \i{left button} \I{selecting text}selects,
 the \i{right button} extends an existing selection, and the
 \i{middle button} pastes.
@@ -1469,13 +1494,112 @@ select a rectangular block. Using the \q{Default selection mode}
 control, you can set \i{rectangular selection} as the default, and then
 you have to hold down Alt to get the \e{normal} behaviour.
 
-\S{config-charclasses} Configuring \i{word-by-word selection}
+\S{config-clipboards} Assigning copy and paste actions to clipboards
+
+Here you can configure which clipboard(s) are written or read by
+PuTTY's various copy and paste actions.
+
+The X Window System (which underlies most Unix graphical interfaces)
+provides multiple clipboards (or \q{\i{selections}}), and many
+applications support more than one of them by a different user
+interface mechanism.
+
+The two most commonly used selections are called \cq{\i{PRIMARY}} and
+\cq{\I{CLIPBOARD selection}CLIPBOARD}; in applications supporting both,
+the usual behaviour is that \cw{PRIMARY} is used by mouse-only actions
+(selecting text automatically copies it to \cw{PRIMARY}, and
+\i{middle-clicking} pastes from \cw{PRIMARY}), whereas \cw{CLIPBOARD}
+is used by explicit Copy and Paste menu items or keypresses such as
+\i{Ctrl-C} and \i{Ctrl-V}.
+
+On other platforms such as Windows, where there is a single system
+clipboard, PuTTY provides a second clipboard-like facility by permitting
+you to paste the text you last selected in \e{this window}, whether or
+not it is currently also in the system clipboard. This is not enabled
+by default.
+
+\S2{config-selection-autocopy} \q{Auto-copy selected text}
+
+\cfg{winhelp-topic}{selection.autocopy}
+
+The checkbox \q{Auto-copy selected text to system clipboard} controls
+whether or not selecting text in the PuTTY terminal window
+automatically has the side effect of copying it to the system
+clipboard, without requiring a separate user interface action.
+
+On X, the wording of this option is changed slightly so that
+\cq{CLIPBOARD} is mentioned in place of the \q{system clipboard}. Text
+selected in the terminal window will \e{always} be automatically
+placed in the \cw{PRIMARY} selection, but if you tick this box, it
+will \e{also} be placed in \cq{CLIPBOARD} at the same time.
+
+\S2{config-selection-clipactions} Choosing a clipboard for UI actions
+
+\cfg{winhelp-topic}{selection.clipactions}
+
+PuTTY has three user-interface actions which can be configured to
+paste into the terminal (not counting menu items). You can click
+whichever mouse button (if any) is configured to paste (see
+\k{config-mouse}); you can press \i{Shift-Ins}; or you can press
+\i{Ctrl-Shift-V}, although that action is not enabled by default.
+
+You can configure which of the available clipboards each of these
+actions pastes from (including turning the paste action off
+completely). On platforms with a single system clipboard, the
+available options are to paste from that clipboard or to paste from
+PuTTY's internal memory of the \i{last selected text} within that
+window. On X, the standard options are \cw{CLIPBOARD} or \cw{PRIMARY}.
+
+(\cw{PRIMARY} is conceptually similar in that it \e{also} refers to
+the last selected text \dash just across all applications instead of
+just this window.)
 
-\cfg{winhelp-topic}{selection.charclasses}
+The two keyboard options each come with a corresponding key to copy
+\e{to} the same clipboard. Whatever you configure Shift-Ins to paste
+from, \i{Ctrl-Ins} will copy to the same location; similarly,
+\i{Ctrl-Shift-C} will copy to whatever Ctrl-Shift-V pastes from.
 
-PuTTY will select a word at a time in the terminal window if you
-\i{double-click} to begin the drag. This panel allows you to control
-precisely what is considered to be a word.
+On X, you can also enter a selection name of your choice. For example,
+there is a rarely-used standard selection called \cq{\i{SECONDARY}}, which
+Emacs (for example) can work with if you hold down the Meta key while
+dragging to select or clicking to paste; if you configure a PuTTY
+keyboard action to access this clipboard, then you can interoperate
+with other applications' use of it. Another thing you could do would
+be to invent a clipboard name yourself, to create a special clipboard
+shared \e{only} between instances of PuTTY, or between just instances
+configured in that particular way.
+
+\S{config-paste-ctrl-char} \q{Permit control characters in pasted text}
+
+\cfg{winhelp-topic}{selection.pastectrl}
+
+It is possible for the clipboard to contain not just text (with
+newlines and tabs) but also control characters such as ESC which could
+have surprising effects if pasted into a terminal session, depending
+on what program is running on the server side. Copying text from a
+mischievous web page could put such characters onto the clipboard.
+
+By default, PuTTY filters out the more unusual control characters,
+only letting through the more obvious text-formatting characters
+(newlines, tab, backspace, and DEL).
+
+Setting this option stops this filtering; on paste, any character on
+the clipboard is sent to the session uncensored. This might be useful
+if you are deliberately using control character pasting as a simple
+form of scripting, for instance.
+
+\H{config-selection-copy} The Copy panel
+
+The Copy configuration panel controls behaviour specifically related to
+copying from the terminal window to the clipboard.
+
+\S{config-charclasses} Character classes
+
+\cfg{winhelp-topic}{copy.charclasses}
+
+PuTTY will \I{word-by-word selection}select a word at a time in the
+terminal window if you \i{double-click} to begin the drag. This section
+allows you to control precisely what is considered to be a word.
 
 Each character is given a \e{class}, which is a small number
 (typically 0, 1 or 2). PuTTY considers a single word to be any
@@ -1511,6 +1635,20 @@ terminal (see \k{reset-terminal}). However, if you modify this
 option in mid-session using \q{Change Settings}, it will take effect
 immediately.
 
+\S{config-rtfcopy} Copying in \i{Rich Text Format}
+
+\cfg{winhelp-topic}{copy.rtf}
+
+If you enable \q{Copy to clipboard in RTF as well as plain text},
+PuTTY will write formatting information to the clipboard as well as
+the actual text you copy. The effect of this is
+that if you paste into (say) a word processor, the text will appear
+in the word processor in the same \i{font}, \i{colour}, and style 
+(e.g. bold, underline) PuTTY was using to display it.
+
+This option can easily be inconvenient, so by default it is
+disabled.
+
 \H{config-colours} The Colours panel
 
 The Colours panel allows you to control PuTTY's use of \i{colour}.
@@ -1549,6 +1687,15 @@ If you do not see \cq{colors#256} in the output, you may need to
 change your terminal setting. On modern Linux machines, you could
 try \cq{xterm-256color}.
 
+\S{config-truecolour} \q{Allow terminal to use 24-bit colour}
+
+\cfg{winhelp-topic}{colours.truecolour}
+
+This option is enabled by default. If it is disabled, PuTTY will
+ignore any control sequences sent by the server which use the control
+sequences supported by modern terminals to specify arbitrary 24-bit
+RGB colour value.
+
 \S{config-boldcolour} \q{Indicate bolded text by changing...}
 
 \cfg{winhelp-topic}{colours.bold}
@@ -1821,9 +1968,10 @@ PuTTY will prompt for a username at the time you make a connection.
 In some environments, such as the networks of large organisations
 implementing \i{single sign-on}, a more sensible default may be to use
 the name of the user logged in to the local operating system (if any);
-this is particularly likely to be useful with \i{GSSAPI} authentication
-(see \k{config-ssh-auth-gssapi}). This control allows you to change
-the default behaviour.
+this is particularly likely to be useful with \i{GSSAPI} key exchange
+and user authentication (see \k{config-ssh-auth-gssapi} and
+\k{config-ssh-gssapi-kex}). This control allows you to change the default
+behaviour.
 
 The current system username is displayed in the dialog as a
 convenience. It is not saved in the configuration; if a saved session
@@ -2440,10 +2588,47 @@ well-known groups, if possible.
 effort on the part of the client, and somewhat less on the part of
 the server, than Diffie-Hellman key exchange.
 
+\b \q{GSSAPI key exchange}: see \k{config-ssh-gssapi-kex}.
+
 If the first algorithm PuTTY finds is below the \q{warn below here}
 line, you will see a warning box when you make the connection, similar
 to that for cipher selection (see \k{config-ssh-encryption}).
 
+\S2{config-ssh-gssapi-kex} GSSAPI-based key exchange
+
+PuTTY supports a set of key exchange methods that also incorporates
+GSSAPI-based authentication. They are enabled with the
+\q{Attempt GSSAPI key exchange} checkbox (which also appears on the
+\q{GSSAPI} panel).
+
+PuTTY can only perform the GSSAPI-authenticated key exchange methods
+when using Kerberos V5, and not other GSSAPI mechanisms. If the user
+running PuTTY has current Kerberos V5 credentials, then PuTTY will
+select the GSSAPI key exchange methods in preference to any of the
+ordinary SSH key exchange methods configured in the preference list.
+
+The advantage of doing GSSAPI authentication as part of the SSH key
+exchange is apparent when you are using credential delegation (see
+\k{config-ssh-auth-gssapi-delegation}). The SSH key exchange can be
+repeated later in the session, and this allows your Kerberos V5
+credentials (which are typically short-lived) to be automatically
+re-delegated to the server when they are refreshed on the client.
+(This feature is commonly referred to as \q{\i{cascading credentials}}.)
+
+If your server doesn't support GSSAPI key exchange, it may still
+support GSSAPI in the SSH user authentication phase. This will still
+let you log in using your Kerberos credentials, but will only allow
+you to delegate the credentials that are active at the beginning of
+the session; they can't be refreshed automatically later, in a
+long-running session.
+
+Another effect of GSSAPI key exchange is that it replaces the usual
+SSH mechanism of permanent host keys described in \k{gs-hostkey}.
+So if you use this method, then you won't be asked any interactive
+questions about whether to accept the server's host key. Instead, the
+Kerberos exchange will verify the identity of the host you connect to,
+at the same time as verifying your identity to it.
+
 \S{config-ssh-kex-rekey} \ii{Repeat key exchange}
 
 \cfg{winhelp-topic}{ssh.kex.repeat}
@@ -2486,6 +2671,14 @@ purposes, rekeys have much the same properties as keepalives.
 should bear that in mind when deciding whether to turn them off.)
 Note, however, the the SSH \e{server} can still initiate rekeys.
 
+\b \q{Minutes between GSSAPI checks}, if you're using GSSAPI key
+exchange, specifies how often the GSSAPI credential cache is checked
+to see whether new tickets are available for delegation, or current
+ones are near expiration. If forwarding of GSSAPI credentials is
+enabled, PuTTY will try to rekey as necessary to keep the delegated
+credentials from expiring. Frequent checks are recommended; rekeying
+only happens when needed.
+
 \b \q{Max data before rekey} specifies the amount of data (in bytes)
 that is permitted to flow in either direction before a rekey is
 initiated. If this is set to zero, PuTTY will not rekey due to
@@ -2839,15 +3032,28 @@ machine, which in principle can authenticate in many different ways
 but in practice is usually used with the \i{Kerberos} \i{single sign-on}
 protocol to implement \i{passwordless login}.
 
-GSSAPI is only available in the SSH-2 protocol.
+GSSAPI authentication is only available in the SSH-2 protocol.
+
+PuTTY supports two forms of GSSAPI-based authentication. In one of
+them, the SSH key exchange happens in the normal way, and GSSAPI is
+only involved in authenticating the user. The checkbox labelled
+\q{Attempt GSSAPI authentication} controls this form.
 
-The topmost control on the GSSAPI subpanel is the checkbox labelled
-\q{Attempt GSSAPI authentication}. If this is disabled, GSSAPI will
-not be attempted at all and the rest of this panel is unused. If it
-is enabled, GSSAPI authentication will be attempted, and (typically)
-if your client machine has valid Kerberos credentials loaded, then
-PuTTY should be able to authenticate automatically to servers that
-support Kerberos logins.
+In the other method, GSSAPI-based authentication is combined with the
+SSH key exchange phase. If this succeeds, then the SSH authentication
+step has nothing left to do. See \k{config-ssh-gssapi-kex} for more
+information about this method. The checkbox labelled \q{Attempt GSSAPI
+key exchange} controls this form. (The same checkbox appears on the
+\q{Kex} panel.)
+
+If one or both of these controls is enabled, then GSSAPI
+authentication will be attempted in one form or the other, and
+(typically) if your client machine has valid Kerberos credentials
+loaded, then PuTTY should be able to authenticate automatically to
+servers that support Kerberos logins.
+
+If both of those checkboxes are disabled, PuTTY will not try any form
+of GSSAPI at all, and the rest of this panel will be unused.
 
 \S{config-ssh-auth-gssapi-delegation} \q{Allow GSSAPI credential
 delegation}
@@ -2875,6 +3081,10 @@ administrator of one server is likely to already have access to the
 other services too; so this would typically be less of a risk than
 SSH agent forwarding.
 
+If your connection is not using GSSAPI key exchange, it is possible
+for the delegation to expire during your session. See
+\k{config-ssh-gssapi-kex} for more information.
+
 \S{config-ssh-auth-gssapi-libraries} Preference order for GSSAPI
 libraries
 
@@ -2885,11 +3095,11 @@ method to be accessed through the same interface. Therefore, more
 than one authentication library may exist on your system which can
 be accessed using GSSAPI.
 
-PuTTY contains native support for a few well-known such libraries,
-and will look for all of them on your system and use whichever it
-finds. If more than one exists on your system and you need to use a
-specific one, you can adjust the order in which it will search using
-this preference list control.
+PuTTY contains native support for a few well-known such libraries
+(including Windows' \i{SSPI}), and will look for all of them on your system
+and use whichever it finds. If more than one exists on your system and
+you need to use a specific one, you can adjust the order in which it
+will search using this preference list control.
 
 One of the options in the preference list is to use a user-specified
 GSSAPI library. If the library you want to use is not mentioned by
diff --git a/DOC/FAQ.BUT b/DOC/FAQ.BUT
index cd3254a8..6fc174a8 100644
--- a/DOC/FAQ.BUT
+++ b/DOC/FAQ.BUT
@@ -173,17 +173,21 @@ time by double-clicking or using \c{REGEDIT}.
 \S{faq-server}{Question} Will you write an SSH server for the PuTTY
 suite, to go with the client?
 
-No. The only reason we might want to would be if we could easily
-re-use existing code and significantly cut down the effort. We don't
-believe this is the case; there just isn't enough common ground
-between an SSH client and server to make it worthwhile.
-
-If someone else wants to use bits of PuTTY in the process of writing
-a Windows SSH server, they'd be perfectly welcome to of course, but
-I really can't see it being a lot less effort for us to do that than
-it would be for us to write a server from the ground up. We don't
-have time, and we don't have motivation. The code is available if
-anyone else wants to try it.
+Not one that you'd want to use.
+
+While much of the protocol and networking code can be made common
+between a client and server, to make a \e{useful} general-purpose
+server requires all sorts of fiddly new code like interacting with OS
+authentication databases and the like.
+
+A special-purpose SSH server (called \i{Uppity}) can now be built from
+the PuTTY source code, and indeed it is not usable as a
+general-purpose server; it exists mainly as a test harness.
+
+If someone else wants to use this as a basis for writing a
+general-purpose SSH server, they'd be perfectly welcome to of course;
+but we don't have time, and we don't have motivation. The code is
+available if anyone else wants to try it.
 
 \S{faq-pscp-ascii}{Question} Can PSCP or PSFTP transfer files in
 \i{ASCII} mode?
@@ -419,6 +423,56 @@ You can ask PuTTY to delete all this data; see \k{faq-cleanup}.
 On Unix, PuTTY stores all of this data in a directory \cw{~/.putty}
 by default.
 
+\S{faq-trust-sigils} Why do small PuTTY icons appear next to the login
+prompts?
+
+As of PuTTY 0.71, some lines of text in the terminal window are marked
+with a small copy of the PuTTY icon (as far as pixels allow).
+
+This is to show trustworthiness. When the PuTTY icon appears next to a
+line of text, it indicates that that line of text was generated by
+PuTTY itself, and not generated by the server and sent to PuTTY.
+
+Text that comes from the server does not have this icon, and we've
+arranged that the server should not be able to fake it. (There's no
+control sequence the server can send which will make PuTTY draw its
+own icon, and if the server tries to move the cursor back up to a line
+that \e{already} has an icon and overwrite the text, the icon will
+disappear.)
+
+This lets you tell the difference between (for example) a legitimate
+prompt in which PuTTY itself asks you for your private key passphrase,
+and a fake prompt in which the server tries to send the identical text
+to trick you into telling \e{it} your private key passphrase.
+
+\S{faq-plink-pause} Why has Plink started saying \q{Press Return to
+begin session}?
+
+As of PuTTY 0.71, if you use Plink for an interactive SSH session,
+then after the login phase has finished, it will present a final
+interactive prompt saying \q{Access granted. Press Return to begin
+session}.
+
+This is another defence against servers trying to mimic the real
+authentication prompts after the session has started. When you pass
+through that prompt, you know that everything after it is generated by
+the server and not by Plink itself, so any request for your private
+key passphrase should be treated with suspicion.
+
+In Plink, we can't use the defence described in \k{faq-trust-sigils}:
+Plink is running \e{in} the terminal, so anything it can write into
+the terminal, the server could write in the same way after the session
+starts. And we can't just print a separator line without a pause,
+because then the server could simply move the cursor back up to it and
+overwrite it (probably with a brief flicker, but you might easily miss
+that). The only robust defence anyone has come up with involves this
+pause.
+
+If you trust your server not to be abusive, you can turn this off. It
+will also not appear in various other circumstances where Plink can be
+confident it isn't necessary. See \k{plink-option-antispoof} for
+details.
+
 \H{faq-howto} HOWTO questions
 
 \S{faq-login}{Question} What login name / password should I use?
@@ -1002,6 +1056,26 @@ appropriate kind of binaries in \cw{SYSTEM32}. Thus, operations in
 the PuTTY suite that involve it accessing its own executables, such as
 \i{\q{New Session}} and \q{Duplicate Session}, will not work.
 
+\S{faq-iutf8}{Question} After I upgraded PuTTY to 0.68, I can no longer
+connect to my embedded device or appliance.
+
+If your SSH server has started unexpectedly closing SSH connections
+after you enter your password, and it worked before 0.68, you may have
+a buggy server that objects to certain SSH protocol extensions.
+
+The SSH protocol recently gained a new \q{terminal mode}, \cw{IUTF8},
+which PuTTY sends by default; see \k{config-ttymodes}. This is the
+first new terminal mode since the SSH-2 protocol was defined. While
+servers are supposed to ignore modes they don't know about, some buggy
+servers will unceremoniously close the connection if they see anything
+they don't recognise. SSH servers in embedded devices, network
+appliances, and the like seem to disproportionately have this bug.
+
+If you think you have such a server, from 0.69 onwards you can disable
+sending of the \cw{IUTF8} mode: on the SSH / TTY panel, select
+\cw{IUTF8} on the list, select \q{Nothing}, and press \q{Set}. (It's
+not possible to disable sending this mode in 0.68.)
+
 \H{faq-secure} Security questions
 
 \S{faq-publicpc}{Question} Is it safe for me to download PuTTY and
diff --git a/DOC/INDEX.BUT b/DOC/INDEX.BUT
index 0877ee90..debd2ab2 100644
--- a/DOC/INDEX.BUT
+++ b/DOC/INDEX.BUT
@@ -73,7 +73,7 @@ from SSH and Telnet
 \IM{three-button mouse} mouse, three-button
 
 \IM{left mouse button}{left button} left mouse button
-\IM{middle mouse button}{middle button} middle mouse button
+\IM{middle mouse button}{middle button}{middle-clicking} middle mouse button
 \IM{right mouse button}{right button} right mouse button
 
 \IM{selecting words}{word-by-word selection} selecting whole words
@@ -92,6 +92,18 @@ from SSH and Telnet
 \IM{right mouse button, with Ctrl} right mouse button, with Ctrl
 \IM{right mouse button, with Ctrl} Ctrl, with right mouse button
 
+\IM{selections} selections, multiple
+\IM{selections} clipboards, multiple
+
+\IM{PRIMARY} \c{PRIMARY} selection
+\IM{PRIMARY} selection, \c{PRIMARY}
+
+\IM{CLIPBOARD selection} \c{CLIPBOARD} selection
+\IM{CLIPBOARD selection} selection, \c{CLIPBOARD}
+
+\IM{SECONDARY} \c{SECONDARY} selection
+\IM{SECONDARY} selection, \c{SECONDARY}
+
 \IM{system menu} system menu
 \IM{system menu} menu, system
 \IM{system menu} window menu
@@ -342,6 +354,11 @@ saved sessions from
 \IM{remote-controlled printing} printing, remote-controlled
 \IM{remote-controlled printing} passthrough printing
 
+\IM{Control-H} Control-H
+\IM{Control-H} Ctrl-H
+\IM{Control-?} Control-?
+\IM{Control-?} Ctrl-?
+
 \IM{Home and End keys} Home key
 \IM{Home and End keys} End key
 
@@ -857,6 +874,9 @@ saved sessions from
 \IM{GSSAPI credential delegation} credential delegation, GSSAPI
 \IM{GSSAPI credential delegation} delegation, of GSSAPI credentials
 
+\IM{cascading credentials} cascading credentials
+\IM{cascading credentials} credentials, cascading
+
 \IM{SYSTEM32} \cw{SYSTEM32} directory, on Windows
 
 \IM{32-bit Windows} 32-bit Windows
diff --git a/DOC/LICENCE.BUT b/DOC/LICENCE.BUT
index 6bd52ee4..d4255751 100644
--- a/DOC/LICENCE.BUT
+++ b/DOC/LICENCE.BUT
@@ -3,9 +3,9 @@
 
 \A{licence} PuTTY \ii{Licence}
 
-PuTTY is \i{copyright} 1997-2017 Simon Tatham.
+PuTTY is \i{copyright} 1997-2019 Simon Tatham.
 
-Portions copyright Robert de Bath, Joris van Rantwijk, Delian Delchev, Andreas Schultz, Jeroen Massar, Wez Furlong, Nicolas Barry, Justin Bradford, Ben Harris, Malcolm Smith, Ahmad Khalifa, Markus Kuhn, Colin Watson, Christopher Staite, and CORE SDI S.A.
+Portions copyright Robert de Bath, Joris van Rantwijk, Delian Delchev, Andreas Schultz, Jeroen Massar, Wez Furlong, Nicolas Barry, Justin Bradford, Ben Harris, Malcolm Smith, Ahmad Khalifa, Markus Kuhn, Colin Watson, Christopher Staite, Lorenz Diener, Christian Brabandt, Jeff Smith, Pavel Kryukov, Maxim Kuznetsov, Svyatoslav Kuzmich, Nico Williams, Viktor Dukhovni, and CORE SDI S.A.
 
 Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the \q{Software}), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
 
diff --git a/DOC/MAKEFILE b/DOC/MAKEFILE
index cb079fb5..fd5ca531 100644
--- a/DOC/MAKEFILE
+++ b/DOC/MAKEFILE
@@ -44,14 +44,16 @@ INPUTS = $(patsubst %,%.but,$(CHAPTERS))
 HALIBUT = halibut
 
 index.html: $(INPUTS)
-	$(HALIBUT) --text --html --winhelp --chm $(INPUTS)
+	$(HALIBUT) --text --html --chm $(INPUTS)
 
-# During formal builds it's useful to be able to build these ones alone.
-putty.hlp: $(INPUTS)
-	$(HALIBUT) --winhelp $(INPUTS)
+# During formal builds it's useful to be able to build this one alone.
 putty.chm: $(INPUTS)
 	$(HALIBUT) --chm $(INPUTS)
 
+# We don't ship this any more.
+putty.hlp: $(INPUTS)
+	$(HALIBUT) --winhelp $(INPUTS)
+
 putty.info: $(INPUTS)
 	$(HALIBUT) --info $(INPUTS)
 
diff --git a/DOC/MAN-PL.BUT b/DOC/MAN-PL.BUT
index 9f411871..179a926a 100644
--- a/DOC/MAN-PL.BUT
+++ b/DOC/MAN-PL.BUT
@@ -93,6 +93,20 @@ very useful in this context.)
 
 \dd Disable interactive prompts.
 
+\dt \cw{-sanitise-stderr}
+
+\dt \cw{-sanitise-stdout}
+
+\dt \cw{-no-sanitise-stderr}
+
+\dt \cw{-no-sanitise-stdout}
+
+\dd By default, Plink can choose to filter control characters if that
+seems appropriate, to prevent remote processes sending confusing escape
+sequences. These options override Plink's default behaviour to enable
+or disabling such filtering on the standard error and standard output
+channels.
+
 \dt \cw{-pw} \e{password}
 
 \dd Set remote password to \e{password}. \e{CAUTION:} this will likely
@@ -182,6 +196,15 @@ which of the agent's keys to use. }
 \dd Allow use of an authentication agent. (This option is only necessary
 to override a setting in a saved session.)
 
+\dt \cw{\-noshare}
+
+\dd Don't test and try to share an existing connection, always make
+a new connection.
+
+\dt \cw{\-share}
+
+\dd Test and try to share an existing connection.
+
 \dt \cw{\-hostkey} \e{key}
 
 \dd Specify an acceptable host public key. This option may be specified
diff --git a/DOC/MAN-PSCP.BUT b/DOC/MAN-PSCP.BUT
index 6c703e13..515e541f 100644
--- a/DOC/MAN-PSCP.BUT
+++ b/DOC/MAN-PSCP.BUT
@@ -94,6 +94,13 @@ very useful in this context.)
 
 \dd Disable interactive prompts.
 
+\dt \cw{-no-sanitise-stderr}
+
+\dd By default, PSCP will filter control characters from the standard error
+channel from the server, to prevent remote processes sending confusing
+escape sequences. This option forces the standard error channel to not be
+filtered.
+
 \dt \cw{-pw} \e{password}
 
 \dd Set remote password to \e{password}. \e{CAUTION:} this will likely
diff --git a/DOC/MAN-PSFT.BUT b/DOC/MAN-PSFT.BUT
index 51f30d3a..c1329d0e 100644
--- a/DOC/MAN-PSFT.BUT
+++ b/DOC/MAN-PSFT.BUT
@@ -82,6 +82,13 @@ very useful in this context.)
 
 \dd Disable interactive prompts.
 
+\dt \cw{-no-sanitise-stderr}
+
+\dd By default, PSFTP will filter control characters from the standard error
+channel from the server, to prevent remote processes sending confusing
+escape sequences. This option forces the standard error channel to not be
+filtered.
+
 \dt \cw{-pw} \e{password}
 
 \dd Set remote password to \e{password}. \e{CAUTION:} this will likely
diff --git a/DOC/PGPKEYS.BUT b/DOC/PGPKEYS.BUT
index 71143af2..2206849a 100644
--- a/DOC/PGPKEYS.BUT
+++ b/DOC/PGPKEYS.BUT
@@ -16,6 +16,11 @@ option), such that if you have an executable you trust, you can use
 it to establish a trust path, for instance to a newer version
 downloaded from the Internet.
 
+As of release 0.67, the Windows executables and installer also contain
+built-in signatures that are automatically verified by Windows' own
+mechanism (\q{\i{Authenticode}}). The keys used for that are different,
+and are not covered here.
+
 (Note that none of the keys, signatures, etc mentioned here have
 anything to do with keys used with SSH - they are purely for verifying
 the origin of files distributed by the PuTTY team.)
@@ -53,31 +58,25 @@ The current issue of those keys are available for download from the
 PuTTY website, and are also available on PGP keyservers using the key
 IDs listed below.
 
-\dt \W{https://www.chiark.greenend.org.uk/~sgtatham/putty/keys/master-2015.asc}{\s{Master Key}}
+\dt \W{https://www.chiark.greenend.org.uk/~sgtatham/putty/keys/master-2018.asc}{\s{Master Key} (2018)}
 
-\dd RSA, 4096-bit. Key ID: \cw{4096R/04676F7C} (long version:
-\cw{4096R/AB585DC604676F7C}). Fingerprint:
-\cw{440D\_E3B5\_B7A1\_CA85\_B3CC\_\_1718\_AB58\_5DC6\_0467\_6F7C}
+\dd RSA, 4096-bit. Key ID: \cw{76BC7FE4EBFD2D9E}. Fingerprint:
+\cw{24E1\_B1C5\_75EA\_3C9F\_F752\_\_A922\_76BC\_7FE4\_EBFD\_2D9E}
 
-\dt \W{https://www.chiark.greenend.org.uk/~sgtatham/putty/keys/release-2015.asc}{\s{Release Key}}
+\dt \W{https://www.chiark.greenend.org.uk/~sgtatham/putty/keys/release-2018.asc}{\s{Release Key} (2018)}
 
-\dd RSA, 2048-bit. Key ID: \cw{2048R/B43434E4} (long version:
-\cw{2048R/9DFE2648B43434E4}). Fingerprint:
-\cw{0054\_DDAA\_8ADA\_15D2\_768A\_\_6DE7\_9DFE\_2648\_B434\_34E4}
+\dd RSA, 3072-bit. Key ID: \cw{6289A25F4AE8DA82}. Fingerprint:
+\cw{E273\_94AC\_A3F9\_D904\_9522\_\_E054\_6289\_A25F\_4AE8\_DA82}
 
-\dt \W{https://www.chiark.greenend.org.uk/~sgtatham/putty/keys/contact-2016.asc}{\s{Secure Contact Key}}
+\dt \W{https://www.chiark.greenend.org.uk/~sgtatham/putty/keys/snapshot-2018.asc}{\s{Snapshot Key} (2018)}
 
-\dd RSA, 2048-bit. Main key ID: \cw{2048R/8A0AF00B} (long version:
-\cw{2048R/C4FCAAD08A0AF00B}). Encryption subkey ID:
-\cw{2048R/50C2CF5C} (long version: \cw{2048R/9EB39CC150C2CF5C}).
-Fingerprint:
-\cw{8A26\_250E\_763F\_E359\_75F3\_\_118F\_C4FC\_AAD0\_8A0A\_F00B}
+\dd RSA, 3072-bit. Key ID: \cw{38BA7229B7588FD1}. Fingerprint:
+\cw{C92B\_52E9\_9AB6\_1DDA\_33DB\_\_2B7A\_38BA\_7229\_B758\_8FD1}
 
-\dt \W{https://www.chiark.greenend.org.uk/~sgtatham/putty/keys/snapshot-2015.asc}{\s{Snapshot Key}}
+\dt \W{https://www.chiark.greenend.org.uk/~sgtatham/putty/keys/contact-2018.asc}{\s{Secure Contact Key} (2018)}
 
-\dd RSA, 2048-bit. Key ID: \cw{2048R/D15F7E8A} (long version:
-\cw{2048R/EEF20295D15F7E8A}). Fingerprint:
-\cw{0A3B\_0048\_FE49\_9B67\_A234\_\_FEB6\_EEF2\_0295\_D15F\_7E8A}
+\dd RSA, 3072-bit. Key ID: \cw{657D487977F95C98}. Fingerprint:
+\cw{A680\_0082\_2998\_6E46\_22CA\_\_0E43\_657D\_4879\_77F9\_5C98}
 
 \H{pgpkeys-security} Security details
 
@@ -156,28 +155,53 @@ once.
 
 \H{pgpkeys-rollover} Key rollover
 
-Our current keys were generated in September 2015, except for the
-Secure Contact Key which was generated in February 2016 (we didn't
-think of it until later).
+Our current keys were generated in August 2018.
+
+Each new Master Key is signed with the old one, to show that it really
+is owned by the same people and not substituted by an attacker.
+
+Each new Master Key also signs the previous Release Keys, in case
+you're trying to verify the signatures on a release prior to the
+rollover and can find a chain of trust to those keys from any of the
+people who have signed our new Master Key.
+
+Each release is signed with the Release Key that was current at the
+time of release. We don't go back and re-sign old releases with newly
+generated keys.
+
+The details of all previous keys are given here.
+
+\s{Key generated in 2016} (when we first introduced the Secure Contact Key)
 
-Prior to that, we had a much older set of keys generated in 2000. For
-each of the key types above (other than the Secure Contact Key), we
-provided both an RSA key \e{and} a DSA key (because at the time we
-generated them, RSA was not in practice available to everyone, due to
-export restrictions).
+\dt \W{https://www.chiark.greenend.org.uk/~sgtatham/putty/keys/contact-2016.asc}{\s{Secure Contact Key} (2016)}
 
-The new Master Key is signed with both of the old ones, to show that
-it really is owned by the same people and not substituted by an
-attacker. Also, we have retrospectively signed the old Release Keys
-with the new Master Key, in case you're trying to verify the
-signatures on a release prior to the rollover and can find a chain of
-trust to those keys from any of the people who have signed our new
-Master Key.
+\dd RSA, 2048-bit. Main key ID: \cw{2048R/8A0AF00B} (long version:
+\cw{2048R/C4FCAAD08A0AF00B}). Encryption subkey ID:
+\cw{2048R/50C2CF5C} (long version: \cw{2048R/9EB39CC150C2CF5C}).
+Fingerprint:
+\cw{8A26\_250E\_763F\_E359\_75F3\_\_118F\_C4FC\_AAD0\_8A0A\_F00B}
+
+\s{Keys generated in the 2015 rollover}
+
+\dt \W{https://www.chiark.greenend.org.uk/~sgtatham/putty/keys/master-2015.asc}{\s{Master Key} (2015)}
+
+\dd RSA, 4096-bit. Key ID: \cw{4096R/04676F7C} (long version:
+\cw{4096R/AB585DC604676F7C}). Fingerprint:
+\cw{440D\_E3B5\_B7A1\_CA85\_B3CC\_\_1718\_AB58\_5DC6\_0467\_6F7C}
+
+\dt \W{https://www.chiark.greenend.org.uk/~sgtatham/putty/keys/release-2015.asc}{\s{Release Key} (2015)}
+
+\dd RSA, 2048-bit. Key ID: \cw{2048R/B43434E4} (long version:
+\cw{2048R/9DFE2648B43434E4}). Fingerprint:
+\cw{0054\_DDAA\_8ADA\_15D2\_768A\_\_6DE7\_9DFE\_2648\_B434\_34E4}
+
+\dt \W{https://www.chiark.greenend.org.uk/~sgtatham/putty/keys/snapshot-2015.asc}{\s{Snapshot Key} (2015)}
 
-Future releases will be signed with the up-to-date keys shown above.
-Releases prior to the rollover are signed with the old Release Keys.
+\dd RSA, 2048-bit. Key ID: \cw{2048R/D15F7E8A} (long version:
+\cw{2048R/EEF20295D15F7E8A}). Fingerprint:
+\cw{0A3B\_0048\_FE49\_9B67\_A234\_\_FEB6\_EEF2\_0295\_D15F\_7E8A}
 
-For completeness, those old keys are given here:
+\s{Original keys generated in 2000} (two sets, RSA and DSA)
 
 \dt \W{https://www.chiark.greenend.org.uk/~sgtatham/putty/keys/master-rsa.asc}{\s{Master Key} (original RSA)}
 
diff --git a/DOC/PLINK.BUT b/DOC/PLINK.BUT
index 459ceadf..f9af18d1 100644
--- a/DOC/PLINK.BUT
+++ b/DOC/PLINK.BUT
@@ -41,7 +41,7 @@ use Plink:
 
 \c Z:\sysosd>plink
 \c Plink: command-line connection utility
-\c Release 0.70
+\c Release 0.71
 \c Usage: plink [options] [user@]host [command]
 \c        ("host" can also be a PuTTY saved session name)
 \c Options:
@@ -75,8 +75,13 @@ use Plink:
 \c   -i key    private key file for user authentication
 \c   -noagent  disable use of Pageant
 \c   -agent    enable use of Pageant
+\c   -noshare  disable use of connection sharing
+\c   -share    enable use of connection sharing
 \c   -hostkey aa:bb:cc:...
 \c             manually specify a host key (may be repeated)
+\c   -sanitise-stderr, -sanitise-stdout, -no-sanitise-stderr, -no-sanitise-stdout
+\c             do/don't strip control chars from standard output/error
+\c   -no-antispoof   omit anti-spoofing prompt after authentication
 \c   -m file   read remote command(s) from file
 \c   -s        remote command is an SSH subsystem (SSH-2 only)
 \c   -N        don't start a shell/command (SSH-2 only)
@@ -237,6 +242,28 @@ line.
 
 (This option is only meaningful with the SSH-2 protocol.)
 
+\S2{plink-option-share} \I{-share-plink}\c{-share}:
+Test and try to share an existing connection.
+
+This option tris to detect if an existing connection can be shared
+(See \k{config-ssh-sharing} for more information about SSH connection
+sharing.) and reuses that connection.
+
+A Plink invocation of the form:
+
+\c plink -share <session>
+\e              iiiiiiiii
+
+will test whether there is currently a viable \q{upstream} for the
+session in question, which can be specified using any syntax you'd
+normally use with Plink to make an actual connection (a host/port
+number, a bare saved session name, \c{-load}, etc). If no \q{upstream}
+viable session is found and \c{-share} is specified, this connection
+will be become the \q{upstream} connection for subsequent connection
+sharing tries.
+
+(This option is only meaningful with the SSH-2 protocol.)
+
 \S2{plink-option-shareexists} \I{-shareexists-plink}\c{-shareexists}:
 test for connection-sharing upstream
 
@@ -258,6 +285,90 @@ zero exit status if a usable \q{upstream} exists, nonzero otherwise.
 
 (This option is only meaningful with the SSH-2 protocol.)
 
+\S2{plink-option-sanitise} \I{-sanitise-stderr}\I{-sanitise-stdout}\I{-no-sanitise-stderr}\I{-no-sanitise-stdout}\c{-sanitise-}\e{stream}: control output sanitisation
+
+In some situations, Plink applies a sanitisation pass to the output
+received from the server, to strip out control characters such as
+backspace and the escape character.
+    
+The idea of this is to prevent remote processes from sending confusing
+escape sequences through the standard error channel when Plink is
+being used as a transport for something like \cw{git} or CVS. If the
+server actually wants to send an error message, it will probably be
+plain text; if the server abuses that channel to try to write over
+unexpected parts of your terminal display, Plink will try to stop it.
+
+By default, this only happens for output channels which are sent to a
+Windows console device, or a Unix terminal device. (Any output stream
+going somewhere else is likely to be needed by an 8-bit protocol and
+must not be tampered with at all.) It also stops happening if you tell
+Plink to allocate a remote pseudo-terminal (see \k{using-cmdline-pty}
+and \k{config-ssh-pty}), on the basis that in that situation you often
+\e{want} escape sequences from the server to go to your terminal.
+
+But in case Plink guesses wrong about whether you want this
+sanitisation, you can override it in either direction, using one of
+these options:
+
+\dd \c{-sanitise-stderr}
+
+\dt Sanitise server data written to Plink's standard error channel,
+regardless of terminals and consoles and remote ptys.
+
+\dd \c{-no-sanitise-stderr}
+
+\dt Do not sanitise server data written to Plink's standard error
+channel.
+
+\dd \c{-sanitise-stdout}
+
+\dt Sanitise server data written to Plink's standard output channel.
+
+\dd \c{-no-sanitise-stdout}
+
+\dt Do not sanitise server data written to Plink's standard output
+channel.
+
+\S2{plink-option-antispoof} \I{-no-antispoof}: turn off authentication spoofing protection prompt
+
+In SSH, some possible server authentication methods require user input
+(for example, password authentication, or entering a private key
+passphrase), and others do not (e.g. a private key held in Pageant).
+
+If you use Plink to run an interactive login session, and if Plink
+authenticates without needing any user interaction, and if the server
+is malicious or compromised, it could try to trick you into giving it
+authentication data that should not go to the server (such as your
+private key passphrase), by sending what \e{looks} like one of Plink's
+local prompts, as if Plink had not already authenticated.
+
+To protect against this, Plink's default policy is to finish the
+authentication phase with a final trivial prompt looking like this:
+
+\c Access granted. Press Return to begin session.
+
+so that if you saw anything that looked like an authentication prompt
+\e{after} that line, you would know it was not from Plink.
+
+That extra interactive step is inconvenient. So Plink will turn it off
+in as many situations as it can:
+
+\b If Plink's standard input is not pointing at a console or terminal
+device \dash for example, if you're using Plink as a transport for
+some automated application like version control \dash then you
+\e{can't} type passphrases into the server anyway. In that situation,
+Plink won't try to protect you from the server trying to fool you into
+doing so.
+
+\b If Plink is in batch mode (see \k{plink-usage-batch}), then it
+\e{never} does any interactive authentication. So anything looking
+like an interactive authentication prompt is automatically suspect,
+and so Plink omits the anti-spoofing prompt.
+
+But if you still find the protective prompt inconvenient, and you
+trust the server not to try a trick like this, you can turn it off
+using the \cq{-no-antispoof} option.
+
 \H{plink-batch} Using Plink in \i{batch files} and \i{scripts}
 
 Once you have set up Plink to be able to log in to a remote server
diff --git a/DOC/PSCP.BUT b/DOC/PSCP.BUT
index 7b90810b..0ab4b73b 100644
--- a/DOC/PSCP.BUT
+++ b/DOC/PSCP.BUT
@@ -39,7 +39,7 @@ use PSCP:
 
 \c Z:\owendadmin>pscp
 \c PuTTY Secure Copy client
-\c Release 0.70
+\c Release 0.71
 \c Usage: pscp [options] [user@]host:source target
 \c        pscp [options] source [source...] [user@]host:target
 \c        pscp [options] -ls [user@]host:filespec
@@ -63,6 +63,7 @@ use PSCP:
 \c   -hostkey aa:bb:cc:...
 \c             manually specify a host key (may be repeated)
 \c   -batch    disable all interactive prompts
+\c   -no-sanitise-stderr  don't strip control chars from standard error
 \c   -proxycmd command
 \c             use 'command' as local proxy
 \c   -unsafe   allow server-side wildcards (DANGEROUS)
@@ -281,6 +282,15 @@ The \c{-sftp} option forces PSCP to use the SFTP protocol or quit.
 When this option is specified, PSCP looks harder for an SFTP server,
 which may allow use of SFTP with SSH-1 depending on server setup.
 
+\S2{pscp-option-sanitise} \I{-sanitise-stderr}\I{-no-sanitise-stderr}\c{-no-sanitise-stderr}: control error message sanitisation
+
+The \c{-no-sanitise-stderr} option will cause PSCP to pass through the
+server's standard-error stream literally, without stripping control
+characters from it first. This might be useful if the server were
+sending coloured error messages, but it also gives the server the
+ability to have unexpected effects on your terminal display. For more
+discussion, see \k{plink-option-sanitise}.
+
 \S{pscp-retval} \ii{Return value}
 
 PSCP returns an \i\cw{ERRORLEVEL} of zero (success) only if the files
diff --git a/DOC/PSFTP.BUT b/DOC/PSFTP.BUT
index 93bef742..cc4bb259 100644
--- a/DOC/PSFTP.BUT
+++ b/DOC/PSFTP.BUT
@@ -135,6 +135,15 @@ This may help PSFTP's behaviour when it is used in automated
 scripts: using \c{-batch}, if something goes wrong at connection
 time, the batch job will fail rather than hang.
 
+\S2{psftp-option-sanitise} \I{-sanitise-stderr}\I{-no-sanitise-stderr}\c{-no-sanitise-stderr}: control error message sanitisation
+
+The \c{-no-sanitise-stderr} option will cause PSFTP to pass through the
+server's standard-error stream literally, without stripping control
+characters from it first. This might be useful if the server were
+sending coloured error messages, but it also gives the server the
+ability to have unexpected effects on your terminal display. For more
+discussion, see \k{plink-option-sanitise}.
+
 \H{psftp-commands} Running PSFTP
 
 Once you have started your PSFTP session, you will see a \c{psftp>}
diff --git a/DOC/UDP.BUT b/DOC/UDP.BUT
index 9ca8ed3f..c853277d 100644
--- a/DOC/UDP.BUT
+++ b/DOC/UDP.BUT
@@ -33,22 +33,84 @@ All the modules in the main source directory - notably \e{all} of
 the code for the various back ends - are platform-generic. We want
 to keep them that way.
 
-This also means you should stick to what you are guaranteed by
-ANSI/ISO C (that is, the original C89/C90 standard, not C99). Try
-not to make assumptions about the precise size of basic types such
-as \c{int} and \c{long int}; don't use pointer casts to do
-endianness-dependent operations, and so on.
-
-(There are one or two aspects of ANSI C portability which we
-\e{don't} care about. In particular, we expect PuTTY to be compiled
-on 32-bit architectures \e{or bigger}; so it's safe to assume that
-\c{int} is at least 32 bits wide, not just the 16 you are guaranteed
-by ANSI C.  Similarly, we assume that the execution character
-encoding is a superset of the printable characters of ASCII, though
-we don't assume the numeric values of control characters,
-particularly \cw{'\\n'} and \cw{'\\r'}. Also, the X forwarding code
-assumes that \c{time_t} has the Unix format and semantics, i.e. an
-integer giving the number of seconds since 1970.)
+This also means you should stick to the C semantics guaranteed by the
+C standard: try not to make assumptions about the precise size of
+basic types such as \c{int} and \c{long int}; don't use pointer casts
+to do endianness-dependent operations, and so on.
+
+(Even \e{within} a platform front end you should still be careful of
+some of these portability issues. The Windows front end compiles on
+both 32- and 64-bit x86 and also Arm.)
+
+Our current choice of C standards version is \e{mostly} C99. With a
+couple of exceptions, you can assume that C99 features are available
+(in particular \cw{<stdint.h>}, \cw{<stdbool.h>} and \c{inline}), but
+you shouldn't use things that are new in C11 (such as \cw{<uchar.h>}
+or \cw{_Generic}).
+
+The exceptions to that rule are due to the need for Visual Studio
+compatibility:
+
+\b Don't use variable-length arrays. Visual Studio doesn't support
+them even now that it's adopted the rest of C99. We use \cw{-Wvla}
+when building with gcc and clang, to make it easier to avoid
+accidentally breaking that rule.
+
+\b For historical reasons, we still build with one older VS version
+which lacks \cw{<inttypes.h>}. So that file is included centrally in
+\c{defs.h}, and has a set of workaround definitions for the
+\cw{PRIx64}-type macros we use. If you need to use another one of
+those macros, you need to add a workaround definition in \c{defs.h},
+and don't casually re-include \cw{<inttypes.h>} anywhere else in the
+source file.
+
+Here are a few portability assumptions that we \e{do} currently allow
+(because we'd already have to thoroughly vet the existing code if they
+ever needed to change, and it doesn't seem worth doing that unless we
+really have to):
+
+\b You can assume \c{int} is \e{at least} 32 bits wide. (We've never
+tried to port PuTTY to a platform with 16-bit \cw{int}, and it doesn't
+look likely to be necessary in future.)
+
+\b Similarly, you can assume \c{char} is exactly 8 bits. (Exceptions
+to that are even less likely to be relevant to us than short
+\cw{int}.)
+
+\b You can assume that using \c{memset} to write zero bytes over a
+whole structure will have the effect of setting all its pointer fields
+to \cw{NULL}. (The standard itself guarantees this for \e{integer}
+fields, but not for pointers.)
+
+\b You can assume that \c{time_t} has POSIX semantics, i.e. that it
+represents an integer number of non-leap seconds since 1970-01-01
+00:00:00 UTC. (Times in this format are used in X authorisation, but
+we could work around that by carefully distinguishing local \c{time_t}
+from time values used in the wire protocol; but these semantics of
+\c{time_t} are also baked into the shared library API used by the
+GSSAPI authentication code, which would be much harder to change.)
+
+\b You can assume that the execution character encoding is a superset
+of the printable characters of ASCII. (In particular, it's fine to do
+arithmetic on a \c{char} value representing a Latin alphabetic
+character, without bothering to allow for EBCDIC or other
+non-consecutive encodings of the alphabet.)
+
+On the other hand, here are some particular things \e{not} to assume:
+
+\b Don't assume anything about the \e{signedness} of \c{char}. In
+particular, you \e{must} cast \c{char} values to \c{unsigned char}
+before passing them to any \cw{<ctype.h>} function (because those
+expect a non-negative character value, or \cw{EOF}). If you need a
+particular signedness, explicitly specify \c{signed char} or
+\c{unsigned char}, or use C99 \cw{int8_t} or \cw{uint8_t}.
+
+\b From past experience with MacOS, we're still a bit nervous about
+\cw{'\\n'} and \cw{'\\r'} potentially having unusual meanings on a
+given platform. So it's fine to say \c{\\n} in a string you're passing
+to \c{printf}, but in any context where those characters appear in a
+standardised wire protocol or a binary file format, they should be
+spelled \cw{'\\012'} and \cw{'\\015'} respectively.
 
 \H{udp-multi-backend} Multiple backends treated equally
 
@@ -138,9 +200,9 @@ construct. Use these wherever possible.
 
 \H{udp-multi-compiler} Independence of specific compiler
 
-Windows PuTTY can currently be compiled with any of four Windows
-compilers: MS Visual C, Borland's freely downloadable C compiler,
-the Cygwin / \cw{mingw32} GNU tools, and \cw{lcc-win32}.
+Windows PuTTY can currently be compiled with any of three Windows
+compilers: MS Visual C, the Cygwin / \cw{mingw32} GNU tools, and
+\cw{clang} (in MS compatibility mode).
 
 This is a really useful property of PuTTY, because it means people
 who want to contribute to the coding don't depend on having a
@@ -312,11 +374,12 @@ as well!
 source archive saying this, but many people don't seem to read it,
 so it's worth repeating here.)
 
-\H{udp-ssh-coroutines} Coroutines in \cw{ssh.c}
+\H{udp-ssh-coroutines} Coroutines in the SSH code
 
-Large parts of the code in \cw{ssh.c} are structured using a set of
-macros that implement (something close to) Donald Knuth's
-\q{coroutines} concept in C.
+Large parts of the code in the various SSH modules (in fact most of
+the protocol layers) are structured using a set of macros that
+implement (something close to) Donald Knuth's \q{coroutines} concept
+in C.
 
 Essentially, the purpose of these macros are to arrange that a
 function can call \cw{crReturn()} to return to its caller, and the
@@ -325,16 +388,31 @@ next time it is called control will resume from just after that
 
 This means that any local (automatic) variables declared in such a
 function will be corrupted every time you call \cw{crReturn}. If you
-need a variable to persist for longer than that, you \e{must} make
-it a field in one of the persistent state structures: either the
-local state structures \c{s} or \c{st} in each function, or the
-backend-wide structure \c{ssh}.
+need a variable to persist for longer than that, you \e{must} make it
+a field in some appropriate structure containing the persistent state
+of the coroutine \dash typically the main state structure for an SSH
+protocol layer.
 
 See
 \W{https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html}\c{https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html}
 for a more in-depth discussion of what these macros are for and how
 they work.
 
+Another caveat: most of these coroutines are not \e{guaranteed} to run
+to completion, because the SSH connection (or whatever) that they're
+part of might be interrupted at any time by an unexpected network
+event or user action. So whenever a coroutine-managed variable refers
+to a resource that needs releasing, you should also ensure that the
+cleanup function for its containing state structure can reliably
+release it even if the coroutine is aborted at an arbitrary point.
+
+For example, if an SSH packet protocol layer has to have a field that
+sometimes points to a piece of allocated memory, then you should
+ensure that when you free that memory you reset the pointer field to
+\cw{NULL}. Then, no matter when the protocol layer's cleanup function
+is called, it can reliably free the memory if there is any, and not
+crash if there isn't.
+
 \H{udp-compile-once} Single compilation of each source file
 
 The PuTTY build system for any given platform works on the following
diff --git a/DOC/USING.BUT b/DOC/USING.BUT
index 7d184b7c..515e3a4d 100644
--- a/DOC/USING.BUT
+++ b/DOC/USING.BUT
@@ -21,27 +21,31 @@ the \I{Windows clipboard}Windows \i{clipboard}, so that you can
 paste (for example) URLs into a web browser, or paste from a word
 processor or spreadsheet into your terminal session.
 
-PuTTY's copy and paste works entirely with the \i{mouse}. In order
-to copy text to the clipboard, you just click the \i{left mouse
-button} in the \i{terminal window}, and drag to \I{selecting text}select
-text. When you let go of the button, the text is \e{automatically}
-copied to the clipboard. You do not need to press Ctrl-C or
-Ctrl-Ins; in fact, if you do press Ctrl-C, PuTTY will send a Ctrl-C
-character down your session to the server where it will probably
-cause a process to be interrupted.
-
-Pasting is done using the right button (or the middle mouse button,
-if you have a \i{three-button mouse} and have set it up; see
+By default, PuTTY's copy and paste works entirely with the \i{mouse}.
+(This will be familiar to people who have used \i\c{xterm} on Unix.)
+In order to copy text to the clipboard, you just click the \i{left
+mouse button} in the \i{terminal window}, and drag to
+\I{selecting text}select text. When you let go of the button, the text
+is \e{automatically} copied to the clipboard. You do not need to press
+\i{Ctrl-C} or \i{Ctrl-Ins}; in fact, if you do press Ctrl-C, PuTTY will
+send a Ctrl-C character down your session to the server where it will
+probably cause a process to be interrupted.
+
+Pasting into PuTTY is done using the right button (or the middle mouse
+button, if you have a \i{three-button mouse} and have set it up; see
 \k{config-mouse}). (Pressing \i{Shift-Ins}, or selecting \q{Paste}
 from the \I{right mouse button, with Ctrl}Ctrl+right-click
 \i{context menu}, have the same effect.) When
 you click the \i{right mouse button}, PuTTY will read whatever is in
-the Windows clipboard and paste it into your session, \e{exactly} as
-if it had been typed at the keyboard. (Therefore, be careful of
-pasting formatted text into an editor that does automatic indenting;
-you may find that the spaces pasted from the clipboard plus the
-spaces added by the editor add up to too many spaces and ruin the
-formatting. There is nothing PuTTY can do about this.)
+the Windows clipboard and paste it into your session. By default, this
+behaves \e{exactly} as if the clipboard contents had been typed at the
+keyboard; therefore, be careful of pasting formatted text into an
+editor that does automatic \i{indenting}, as you may find that the spaces
+pasted from the clipboard plus the spaces added by the editor add up
+to too many spaces and ruin the formatting. (Some remote applications
+can ask PuTTY to identify text that is being pasted, to avoid this
+sort of problem; but if your application does not, there is nothing
+PuTTY can do to avoid this.)
 
 If you \i{double-click} the left mouse button, PuTTY will
 \I{selecting words}select a whole word. If you double-click, hold
@@ -69,6 +73,15 @@ middle mouse button to paste, then the right mouse button does this
 instead.) Click the button on the screen, and you can pick up the
 nearest end of the selection and drag it to somewhere else.
 
+If you are running PuTTY itself on Unix (not just using it to connect
+to a Unix system from Windows), by default you will likely have to use
+similar mouse actions in other applications to paste the text you
+copied from PuTTY, and to copy text for pasting into PuTTY; actions
+like \i{Ctrl-C} and Ctrl-V will likely not behave as you expect.
+\K{config-clipboards} explains why this is, and how you can change the
+behaviour. (On Windows there is only a single selection shared with other
+applications, so this confusion does not arise.)
+
 It's possible for the server to ask to \I{mouse reporting}handle mouse
 clicks in the PuTTY window itself.  If this happens, the \i{mouse pointer}
 will turn into an arrow, and using the mouse to copy and paste will only
@@ -76,6 +89,9 @@ work if you hold down Shift.  See \k{config-features-mouse} and
 \k{config-mouseshift} for details of this feature and how to configure
 it.
 
+You can customise much of this behaviour, for instance to enable copy
+and paste from the keyboard; see \k{config-selection}.
+
 \S{using-scrollback} \I{scrollback}Scrolling the screen back
 
 PuTTY keeps track of text that has scrolled up off the top of the
@@ -86,8 +102,10 @@ window to look back up the session \i{history} and find it again.
 
 As well as using the scrollbar, you can also page the scrollback up
 and down by pressing \i{Shift-PgUp} and \i{Shift-PgDn}. You can
-scroll a line at a time using \i{Ctrl-PgUp} and \i{Ctrl-PgDn}. These
-are still available if you configure the scrollbar to be invisible.
+scroll a line at a time using \i{Ctrl-PgUp} and \i{Ctrl-PgDn}, or
+to the top/bottom of the scrollback with \i{Ctrl-Shift-PgUp} and
+\i{Ctrl-Shift-PgDn}. These are still available if you configure the
+scrollbar to be invisible.
 
 By default the last 2000 lines scrolled off the top are
 preserved for you to look at. You can increase (or decrease) this
@@ -1042,3 +1060,15 @@ any processes started with Duplicate Session, New Session etc.
 (However, if you're invoking PuTTY tools explicitly, for instance as a
 proxy command, you'll need to arrange to pass them the
 \c{-restrict-acl} option yourself, if that's what you want.)
+
+If Pageant is started with the \c{-restrict-acl} option, and you use
+it to launch a PuTTY session from its System Tray submenu, then
+Pageant will \e{not} default to starting the PuTTY subprocess with a
+restricted ACL. This is because PuTTY is more likely to suffer reduced
+functionality as a result of restricted ACLs (e.g. screen reader
+software will have a greater need to interact with it), whereas
+Pageant stores the more critical information (hence benefits more from
+the extra protection), so it's reasonable to want to run Pageant but
+not PuTTY with the ACL restrictions. You can force Pageant to start
+subsidiary PuTTY processes with a restricted ACL if you also pass the
+\c{-restrict-putty-acl} option.
diff --git a/DOC/copy.but b/DOC/copy.but
index 72753368..29ad6437 100644
--- a/DOC/copy.but
+++ b/DOC/copy.but
@@ -1,5 +1,5 @@
 \# Generated by licence.pl from LICENCE.
 \# You should edit those files rather than editing this one.
 
-\define{shortcopyrightdetails} 1997-2017 Simon Tatham
+\define{shortcopyrightdetails} 1997-2019 Simon Tatham