2ce0b680c inadvertently removed this ability in trying to ensure that
everyone got the new IUTF8 mode by default; you could remove a mode from
the list in the UI, but this would just revert PuTTY to its default.
The UI and storage have been revamped; the storage format now explicitly
says when a mode is not to be sent, and the configuration UI always
shows all modes known to PuTTY; if a mode is not to be sent it now shows
up as "(don't send)" in the list.
Old saved settings are migrated so as to preserve previous removals of
longstanding modes, while automatically adding IUTF8.
(In passing, this removes a bug where pressing the 'Remove' button of
the previous UI would populate the value edit box with garbage.)
Conflicts in the FAQ are fixed by incorporating Jacob's rewritten
post-0.68 version. (But owing to considerable git confusion I haven't
managed to get his name on to this commit anywhere.)
This commit also updates the dumps of Plink's and PSCP's help output,
adding the -proxycmd option to both and the -shareexists option to
Plink.
(Or rather, _re_-adding the latter, since it was introduced in error
by commit 07af4ed10 due to a branch management error and hastily
removed again in 29e8c24f9. This time it really does match reality.)
Several places in the docs were labelled for review because they need
to change when 0.68's feature set comes in - no SSH-2 to SSH-1
fallback any more, but on the other hand, Unix Pageant now exists.
(In a XXX-REVIEW-BEFORE-RELEASE form.)
Also, note the effect of compilation with different Visual Studio
versions on Windows version compatibility in the source README, for the
sake of having it written down somewhere.
They were there mainly to distinguish from 16-bit Windows, which hasn't
been a thing since before a noticeable fraction of the userbase were
born, probably. These days the obvious comparison is with 64-bit
Windows.
Also tweak some wording to reflect that official PuTTY executables are
not necessarily 32-bit any more, and add some XXX-REVIEW-BEFORE-RELEASE
in the same vein.
As documented in bug 'win-process-acl-finesse', we've had enough
assorted complaints about it breaking various non-malicious pieces of
Windows process interaction (ranging from git->plink integration to
screen readers for the vision-impaired) that I think it's more
sensible to set the process back to its default level of protection.
This precaution was never a fully effective protection anyway, due to
the race condition at process startup; the only properly effective
defence would have been to prevent malware running under the same user
ID as PuTTY in the first place, so in that sense, nothing has changed.
But people who want the arguable defence-in-depth advantage of the ACL
restriction can now turn it on with the '-restrict-acl' command-line
option, and it's up to them whether they can live with the assorted
inconveniences that come with it.
In the course of this change, I've centralised a bit more of the
restriction code into winsecur.c, to avoid repeating the error
handling in multiple places.
This is equivalent to selecting 'Local' as the proxy type and entering
the argument string in the proxy command box, in the GUI.
I've pulled this out of all the other proxy options to promote to a
named command-line option, partly because it's the proxy option with
the most natural command-line expression in the first place (any shell
command you might want to use is already in the form of a single
string), and also because it has uses beyond end-user proxying
applications: in particular, replacing the network connection with a
local process is a convenient way to do testing in the style of
contrib/samplekex.py, avoiding the need to run a separate command to
make the test 'server' listen on a port.
Also try to upgrade the settings of people who haven't changed the
defaults; but anyone who has, or anyone who's used the pre-release
snapshots with elliptic-curve support, will have to review their
settings manually.
The UI now only has "1" and "2" options for SSH protocol version, which
behave like the old "1 only" and "2 only" options; old
SSH-N-with-fallback settings are interpreted as SSH-N-only.
This prevents any attempt at a protocol downgrade attack.
Most users should see no difference; those poor souls who still have to
work with SSH-1 equipment now have to explicitly opt in.
Both in a new section about reporting vulnerabilities, and in the
section about large attachments (since some large attachments will
surely contain confidential information from the sender).
I think the deterministic DSA system we've been using for ages can now
be considered proven in use, not to mention the fact that RFC 6979 and
the Ed25519 spec both give variants on the same idea. So I've removed
the 'don't use DSA if you can avoid it' warning.
Now we actually have enough of them to worry about, and especially
since some of the types we support are approved by organisations that
people might make their own decisions about whether to trust, it seems
worth having a config list for host keys the same way we have one for
kex types and ciphers.
To make room for this, I've created an SSH > Host Keys config panel,
and moved the existing host-key related configuration (manually
specified fingerprints) into there from the Kex panel.
It's too esoteric to be the first thing on the Auth panel; I've never
heard of any SSH server that supports it in the decade since I
implemented it. The only Google hits are lost souls mistakenly believing
they need it for passwordless public-key login and the like.
