From 407bf88a959cce39bc284ce77f71d017c2c7c9e1 Mon Sep 17 00:00:00 2001 From: Simon Tatham Date: Tue, 28 Feb 2023 18:58:14 +0000 Subject: [PATCH] Document our long-standing workarounds policy. For years I've been following the principle that before I'll add auto-detection of an SSH server bug, I want the server maintainer to have fixed the bug, so that the list of affected version numbers triggering the workaround is complete, and to provide an incentive for implementations to gradually converge on rightness. *Finally*, I've got round to documenting that policy in public, for the Feedback page! (cherry picked from commit b5645f79ddadeecfe15c4db24b64a0afc48fca4a) --- doc/config.but | 3 +++ doc/feedback.but | 48 ++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 51 insertions(+) diff --git a/doc/config.but b/doc/config.but index 9770697d..56eac575 100644 --- a/doc/config.but +++ b/doc/config.but @@ -3521,6 +3521,9 @@ not available for bugs that \e{cannot} be detected from the server version, e.g. because they must be acted on before the server version is known.) +(The PuTTY project has a defined policy about when we're prepared to +add auto-detection for a bug workaround. See \k{feedback-workarounds}.) + \S{config-ssh-bug-ignore2} \q{Chokes on SSH-2 \i{ignore message}s} An ignore message (SSH_MSG_IGNORE) is a message in the SSH protocol diff --git a/doc/feedback.but b/doc/feedback.but index b7aa9c87..d4f58c09 100644 --- a/doc/feedback.but +++ b/doc/feedback.but @@ -297,6 +297,54 @@ high-quality software to the users comes first.) way to get a feature implemented quickly, if it's a big one that we don't have time to do ourselves. +\H{feedback-workarounds} Workarounds for SSH server bugs + +It's normal for SSH implementations to automatically enable +workarounds for each other's bugs, using the software version strings +that are exchanged at the start of the connection. Typically an SSH +client will have a list of server version strings that it believes to +have particular bugs, and auto-enable the appropriate set of +workarounds when it sees one of those strings. (And servers will have +a similar list of workarounds for \e{client} software they believe to +be buggy.) + +If you've found a bug in an SSH server, and you'd like us to add an +auto-detected workaround for it, our policy is that \s{the server +implementor should fix it first}. + +If the server implementor has fixed it in the latest version, and can +give us a complete description of the version strings that go with the +bug, then we're happy to use those version strings as a trigger to +automatically enable our workaround (assuming one is possible). We +\e{won't} accept requests to auto-enable workarounds for an open-ended +set of version strings, such as \q{any version of FooServer, including +future ones not yet released}. + +The aim of this policy is to encourage implementors to gradually +converge on the actual standardised SSH protocol. If we enable people +to continue violating the spec, by installing open-ended workarounds +in PuTTY for bugs they're never going to fix, then we're contributing +to an ecosystem in which everyone carries on having bugs and everyone +else carries on having to work around them. + +An exception: if an SSH server is no longer maintained \e{at all} +(e.g. the company that produced it has gone out of business), and +every version of it that was ever released has a bug, then that's one +situation in which we may be prepared to add a workaround rule that +matches all versions of that software. (The aim is to stop +implementors from continuing to release software with the bug \dash +and if they're not releasing it \e{at all} any more, then that's +already done!) + +We do recognise that sometimes it will be difficult to get the server +maintainer to fix a bug, or even to answer support requests at all. Or +it might take them a very long time to get round to doing anything +about it. We're not completely unwilling to compromise: we're prepared +to add \e{manually enabled} workarounds to PuTTY even for bugs that an +implementation hasn't fixed yet. We just won't \e{automatically} +enable the workaround unless the server maintainer has also done their +part. + \H{feedback-support} \ii{Support requests} If you're trying to make PuTTY do something for you and it isn't