PuTTY Known Bugs and Wish List

Home | Licence | FAQ | Docs | Download | Keys
Mirrors | Updates | Feedback | Changes | Wishlist

These items are clearly actual problems and I want them fixed.

• Socket buffering has no limit. If a peer sends data to PuTTY faster than PuTTY can send it out (perhaps because an SSH2 connection is presenting a zero window, or because the bandwidth isn't great, or whatever), PuTTY will buffer an arbitrary amount internally and grow without limit. What should happen is that PuTTY should pass blockages back to the sender: if it can't send on an SSH channel, it should stop _reading_ on the socket (or whatever) that's providing data to go down the channel.
• Fatal error handling is patchy and flaky. It's very easy to throw a fatal error, put up a message box, and then receive a Windows message containing yet more socket data. The MessageBox message loop then dispatches that message automatically and the back end is called reentrantly. Chaos ensues. Solution: the fatal error behaviour should be much more robust. Close _all_ sockets the instant a fatal error occurs; also set some global flags that prevent action messages from having any back end effect.
• Problems with various keyboard layouts. It would be hard for me to debug these myself because I'd have to be able to work in the same keymap as I was testing PuTTY in! If anybody can debug these problems it would be greatly appreciated.
  • The svorak (Swedish Dvorak) layout apparently gets a few control combinations wrong: ^W, ^V and ^Z.
  • On the Danish keyboard, apparently the tilde (~) is acting as a dead key and generating a code in itself; so if you hit ~ and then n, you get a ~ followed by a ñ.
  • There's been a report from a Korean user that Korean multi-byte input doesn't work.
  • A German user has reported that Caps Lock is more like Shift Lock - it affects a lot of keys other than alphabetics.
• PuTTY has trouble interoperating with the SCP variant in later ssh.com versions. It's not very clear why, but I suspect ssh.com of gratuitously changing the protocol.
• If PuTTY starts up with its window unselected, something slightly odd can happen with the cursor: it doesn't revert from box to block when the window gains focus.

Semi-bugs

These are things which might be bugs or might not, depending on your precise definition of what a bug is.

• PSCP ought to handle really really big (>2Gb) files.
• Better handling of the connection closing, and of SSH_MSG_DISCONNECT being received. Ideally we should maintain our own idea of when and whether we expect to see a closure, and only signal clean exit when a closure or disconnect arrives that we were expecting. If one arrives unexpectedly it should count as an ungraceful closure, display a dialog box containing the text out of MSG_DISCONNECT, and not close the window unless the user selected "Always".
• Opaque resizes under NT cause trouble when the user changes their mind and carefully drags the window back to the way it started out: the contents of the screen have been trashed and no resize event is sent to the server. Perhaps redisplay during resizing should be reimplemented in a way that doesn't change the terminal buffer's size at all.
• Port forwarding upgrade: it would be nice to be able to (at least try to) reconfigure forwardings in Change Settings.
• Apparently PuTTY doesn't correctly handle switching Windows keymaps in mid-session: the keymap in force when PuTTY starts up remains in force throughout. I have no idea what you have to do to fix this, so someone else will have to help me if it's ever going to be fixed.
• Window placement is non-ideal. PuTTY creates a "guess" window of arbitrary size and then measures the difference between its full and client-area sizes; this allows it to precisely calculate the correct real size, and resize the window. Sadly this scuppers Windows's default-placement scheme. Unsure what should be done about this, but clearly something should.
• It is claimed that MapVirtualKeyEx and ToAsciiEx don't work in Korean Win98 (although they're fine in other Korean Windows products); MapVirtualKey and ToAscii work fine. If anyone can reproduce this problem and work out a way for PuTTY to determine which pair of functions to use on any given system, that would be useful.

This list contains features I hope to get round to adding at some stage.

• While trying to establish the connection, put up at least some sort of window, so the user can tell whether there's a proto-PuTTY around or not. Also, make the connection using an asynchronous connect, so that users can kill PuTTY before it makes the connection.
• PSCP should allow cipher selection by other means than loading a PuTTY saved session.
• Pageant should offer a wider range of passphrase management options.
  • It should be possible to expire the passphrase on a key after a specified time, and also to load a key but defer requesting the passphrase until the key is first used.
  • Perhaps it should be possible for Pageant to remember the keys it has loaded and automatically reload them on restart.
• Perhaps, for people who don't like dialog boxes, messages like "connection closed" and fatal errors should be configurable to appear inside the window instead of popping up sudden message boxes. If we do this, we should probably include a means of distinguishing that sort of error output from anything the remote site can possibly send.
• Perhaps Shift-Backspace could do whichever of ^H and ^? normal Backspace _isn't_ doing. Apart from anything else this would make documentation of the Backspace functionality switch easier (we could invite users to try Shift-Backspace if just Backspace doesn't work, and this would be a clear indication that they needed to frob that switch).
• It would be quite cool if the right-button menu on Pageant's System tray icon could offer the option to start PuTTY (New Session plus the Saved Sessions menus). Of course Pageant would have to avoid offering these options if it couldn't find the PuTTY binary on startup.
• PuTTY should do something sensible if the user key it's given in the configuration matches one of the ones in Pageant. (In particular, if it tries the one in Pageant and the server refuses it, it shouldn't then try it again.)
• Several people seem to want margins between the PuTTY window border and the terminal contents. Configurable, of course.
• When selecting with the mouse, it might make sense for further incoming data to be buffered until the user lets go, so that they aren't trying to work with a moving target. This might also be nice when scrolling with the scrollbar.
• Rectangular-block selection. Not sure how it should be enabled: Shift-drag? Ctrl-drag? A config option?
• Allow the "ANSI Green" used for foregrounds to be different from the one used for backgrounds (for all values of "Green").
• Terminal settings that are modifiable from "Change Settings" but which only control an initial state should be handled better. Perhaps a sensible procedure would be that if the user changes such a setting, then when they hit Apply they get a message box: "You have modified the initial state of the Foo setting. This change will take effect the next time your terminal is reset. Do you want to force it to take effect immediately? [yes] [no]".
• Perhaps an inactive window should have a menu option to reactivate the session (like Duplicate Session but in the same window).
• A second font selection for 132-column mode. Perhaps, in general, the ability to select multiple fonts and switch between them quickly?
• A mode in which, when the window is resized, the terminal size stays fixed and the font changes, instead of the current behaviour where the font stays fixed and the terminal size changes.
• Perhaps the "log file name" config option should support some substitutions, for example date, time and hostname. That way a user could set up a single log-file preference, and always be assured of keeping all their logs.
• There have been various requests to have various config options available conveniently in the System menu instead of having to go all the way to Change Settings. A particularly common request is the ability to turn logging on and off quickly.
• PSCP should be able to send its log messages to stdout instead of stderr, since Windows doesn't provide any easy way to redirect stderr.
• More options for bell handling. A bell indicator in the Taskbar button, which stays around until you give the window focus (so you can keep many windows minimised and track bells in each of them). Also, selection of different sounds, preferably per-window.
• Wheel mice should be handled better. (Apparently the automatic scrolling doesn't work when the scrollbar is absent. Also, since the wheel is also the middle button, it might be nice to avoid rogue-paste problems somehow.)
• Ctrl-PgUp and Ctrl-PgDn to scroll by one line at a time.
• Command line options, in general. In particular, SSH protocol, cipher and compression selection in the auxiliary utilities (PSCP etc). The command-line utilities should also be able to specify an identity file using the standard option, because this might enable the WinCVS GUI identity-file chooser to work with Plink.
• Work out how to deal with ALT+numberpad input of arbitrary character codes.
• Support the Euro symbol, somehow. (Perhaps char 128 should just start being considered unprintable? Would that work sensibly?)
• Allow saving of the current screen+scrollback state to a file. Or printing it, possibly.
• It might be generous if we skipped whitespace when parsing IP addresses in the Host Name box.
• Possibly copy/paste should be implicit in the mouse only within one window. Not convinced.
• Perhaps (configurably) we could do the X trick of emulating the middle button when both buttons are pressed, to improve X exiles' experience of PuTTY's mouse handling.
• Some means of categorising saved sessions, for people who have lots.
• WM_PASTE and drag&drop support.
• Possibly support OpenSSH's host key policy: file each host key under a (hostname,IP) pair, so as to be able to deal with one hostname mapping to a cluster of several IPs with different host keys. First think through all the implications and work out whether we really want to do this. Also, for the benefit of really weird network setups, be able to explicitly _specify_ what name to store a host key under.
• Remapping of keypad-Delete to ^? as an option. Also, optional remapping of Home/End to ^A/^E. And one user wanted a user-definable F5 sequence. And several users want the block above the arrow keys to be mapped in the LK450 layout. Maybe a generic key remapping facility, though that would probably be horrible to implement...
• Perhaps copy and paste in the Windows style: ^C/^V or ShiftIns/CtrlIns. (Note that we already have ShiftIns as paste, so this would have to be a configurable option that disabled the existing copy-on-selection.) Also, perhaps, (copy) and paste options on the System menu.
• Make selection colours configurable rather than forcing them to be inverse-of-current. But still need inverse-of-current as an option. Come up with a sane UI for this and then implement it.
• Allow the user to select a different default colour for underlined text, and a different default background colour for bold text, and so on. Not everybody wants true WYSIWYG in attribute rendering. Also, consider the possibility of changing fonts for some of these criteria (might be useful for people with low vision).
• When you adjust the properties of a running session using the "Change Settings" menu option, it might be nice to be able to save the adjusted settings back to the saved-session slot you loaded from. (Only in circumstances where that makes sense, of course.) It might also be nice to be able to save the adjusted settings as a new session (which always makes sense).
• Some support for the generality of SSH 2, in the sense that it's not necessary to start a shell; you can make a connection and just do port forwarding, for example.
• ANSI printer control support.
• Think about pre-building a bitmap for better scrolling, or possibly just doing the old scroll optimisations over again and getting them right.
• Possibly line-end conversion in pscp. An option to turn it on, an option (enabled by default) to turn it off, and perhaps an option to try to auto-detect whether to turn it on or not. (Anyone know a good heuristic for distinguishing text from binary files? infozip has one, as does less; anyone want to comment on which is better or whether there are better still?)
• Port to other OSes: Unix/X (need a local-xterm back end), BeOS (likewise).
• Scrollback should automatically scroll if you try to drag-select off the top of the window (or off the bottom of the window when it's scrolled back), so you can easily select more than a screenful.
• Perhaps a screen-clear should push the previous screen contents into the scrollback?
• Toolbar, maybe. Certainly optional, if so.
• Optional status bar with various information on it. A visible indicator of whether the connection is secured or not (for the paranoids who aren't sure whether they remembered to hit the SSH button); a display of the cursor coordinates; whether the terminal bell is currently overloaded; some sort of visual representation of the host key perhaps. Anything else that springs to mind.
• Menu bar, to go with the toolbar. Definitely optional. Option for cut and paste to be in the Windows style and/or via the menu/tool bars.
• The default-foreground and default-background colour selection should have an option to go with the Windows colour scheme.
• Ability to configure some more of the terminal emulation features off, in addition to application keypad mode. Somebody, for example, was finding that the high/low screen feature was impeding his normal mode of use of more. Some people don't like xterm title sequences. Some people have found it disorienting and/or inconvenient that PuTTY is able to change its own size in response to an escape sequence. One person was startled by ^? being a destructive backspace. Other features to add to this list are welcomed.
• Possibly more encryptions? IDEA is out due to the patent restrictions being incompatible with the PuTTY licence; RC4 would probably be doable if anyone actually wants it; Twofish and Serpent would both be feasible.
• Ability to select a preference order of encryptions would be good: currently we support user selection of one encryption and always fall back to 3DES if that one's not available.
• The documentation needs finishing.
• Ability to connect to a serial port as well as a Telnet or SSH connection. Also, ability to run a local command interpreter in a pipe (probably an NT-only feature).
• Support for proxies. There are several types of proxy to consider:
  • SOCKS.
  • HTTP CONNECT style proxying (connect to the HTTP port and send something like "CONNECT hostname.example.com:22 HTTP/1.0", then parse the HTTP return headers and go)
  • Simple by-hand proxy: the kind where you telnet to the firewall and type "connect hostname.example.com 22", and then expect a connection to begin.
  We would also want the ability to define non-proxy zones (probably give the user the choice of DNS or IP address space).
• Ability to cache host keys and settings in a file as well as the registry, so that people can (for example) easily carry a complete PuTTY setup around on a floppy.
• Ability to store PuTTY host keys and settings in HKEY_ALL_USERS as well as HKEY_CURRENT_USER, so that sysadmins can set up a default set of host keys (for example, all the servers in a company) to spare some classes of user the constant "new host key" messages. Also so that sysadmins can provide a default set of saved sessions or local Default Settings (sensible local proxy support springs to mind once it's implemented) but this MUST be a default only and the user MUST be able to override all of it using settings in HKEY_CURRENT_USER.
• Perhaps PSCP (and possibly Plink and PSFTP and other potential command-line type tools) should be able to read some default command-line options from an environment variable? Note that if we did this we would also need to supply a negative form of _every_ option, so that a user could always choose to turn off an option that the environment variable had turned on.
• Scripting support, so you can have PuTTY perform automatic tasks. (Such as remembering your password for you, although I don't recommend this on grounds of security!)
• Extract all the user-visible text to a single location, so it can be easily replaced with a set of translations into other languages. It's not yet clear whether we want to do this at compile time, post-compile time, or using a Windows string resource (probably not the latter since we will eventually be porting to non-Windows environments).

Implausible feature wish list

These are features I will probably never get round to adding myself. I wouldn't be opposed to seeing them written, but if it happens somebody else will have to do it, because they're big and complicated and I wouldn't use them enough myself to justify spending all that effort.

• X11 forwarding currently doesn't even attempt to authenticate with the local X server. In order for it to do so, PuTTY would have to know where to look for authentication data. It would be nice if this were to happen.
• SRP support, as an alternative to pure password authentication. Possibly also in Telnet.
• Zmodem file transfers.
• An option in Plink to handle terminal escape codes, so that you get "PuTTY in a console window", and so you can run it full-screen.
• Somebody requested "Kerberos 5 credential forwarding". I don't know anything about Kerberos, so if this gets done it will have to be done by somebody who does.
• Support for various international input methods. There's been a report from the Netherlands of an "international keyboard driver" which allows you to enter, for example, an "Ë" just by typing a double quote and then an E. I believe there are also Eastern input mechanisms we don't handle sensibly. Somebody who knows about this stuff will have to do it for me and probably explain it to me as well, because I just don't know enough about internationalisation.
• There's been one request for SSL. (SSL/Telnet in particular; possibly also raw-SSL in order to talk directly to HTTPS?) Most of the SSL protocol looks reasonably sane, except for the certificates (ASN.1 and X509 and other buzzwords). If the certificate processing turns out to take too much code, SSL might not make it into the PuTTY core for size reasons - it would have to be compiled in specially, or perhaps shipped as a separate DLL.

Non-wish list

These are features I am actively opposed to seeing in PuTTY. Don't bother writing them and sending them to me! If you think you have a good argument why they would be good, feel free to plead for them, but generally I'll already have a good reason not to do them.

• DSA (also known as DSS) public keys for SSH 2 authentication. DSA has a particularly nasty weakness that potentially affects every signature generated using a DSA key:
  • Creating a DSA signature requires a 160-bit random number k. This is used in computing the signature itself, and then discarded.
  • However, if k were to be accidentally made known to the recipient along with the public key, the signature, and the hash of the message, then they would have enough information to deduce the private key - completely compromising the key and allowing the attacker to forge any number of signatures with it.
  • Furthermore, if k is not actually known to the attacker but the random number generation is weak enough to make it guessable in feasibly many attempts, then the signature also contains enough information to let the attacker know when he has guessed the correct k - and then the key is compromised as before.
  • Therefore, a DSA signature should never be created on a platform with less than perfect random number generation. PuTTY's random numbers are as good as I know how to make them, and I welcome improvements, but I don't think they're good enough to trust the security of an authentication key to.
  Note that this problem affects the use of a key, not the generation. Importing a DSA key generated by another program would not help, because PuTTY would still have to generate signatures with that key, and it is the generation of signatures that suffers the weakness.
• Use of the System tray. So many people have requested this that I think it's a genuine desirable feature, but I don't want it to bloat the core of PuTTY. Therefore, it should be implemented using a separate program. There are a variety of programs out there already that do this. Here are some links to them.
  • ToggleMINIMIZE.
  • The Wonderful Icon.
  • TraySaver.
• The ability to specify the precise position on the screen you want your PuTTY window to open at. This is clearly a very useful thing to have, but it would be just as useful for all the other Windows apps anyone uses. It shouldn't be the responsibility of every single program to include a configuration option to specify window position. Instead, it should be the responsibility of the Windows system itself, or a third-party program, to remember where you like individual programs to go.
  One such program is ZMover (shareware); another is HandyThing (free as in beer). If anyone knows of a free (as in speech) one, I'd like to hear about it.