Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
37 check-ins using file Recipe version 13afce56bc
|
2006-12-09
| ||
| 09:44 | Set FD_CLOEXEC in a little convenience function that does the right thing with F_GETFD and F_SETFD. check-in: 7af697811b user: ben tags: trunk | |
|
2006-11-28
| ||
| 15:51 | Correct an embarrassingly wrong comment. check-in: 3c8ea162b2 user: simon tags: trunk | |
|
2006-11-23
| ||
| 08:32 | I've just discovered that using the saved sessions menu from Unix PuTTY causes the child process to inherit a lot of socket fds from its parent, which is a pain if one of them then ends up holding open a listening socket which the parent was using for port forwarding after the parent itself is dead. Therefore, this checkin sprinkles FD_CLOEXEC throughout the Unix platform directory wherever there looks like being a long-lived fd. check-in: 1002c29630 user: simon tags: trunk | |
|
2006-11-18
| ||
| 09:10 | Reinstate as much of the Windows font-linking behaviour as I can easily manage, by adopting a hybrid approach to Unicode text display. The old approach of simply calling ExtTextOutW provided font linking without us having to lift a finger, but didn't do the right thing when it came to bidirectional or Arabic-shaped text. Arabeyes' replacement exact_textout() supported the latter, but turned out to break the former (with no warning from the Windows API documentation, so it's not their fault). So now I've got a second wrapper layer called general_textout(), which splits the input string into substrings based on bidi character class. Any character liable to cause bidi or shaping behaviour if fed straight to ExtTextOutW is instead fed through Arabeyes' exact_textout(), but the rest is fed straight to ExtTextOutW as it used to be. The effect appears to be that font linking is restored for all characters _except_ Arabic and other bidi scripts, which means in particular that we are no longer in a state of regression over 0.57. (0.57 would have done font linking on Arabic as well, but would also have misbidied it, so we've merely exchanged one failure mode for another slightly less harmful one in that situation.) check-in: 76941fa153 user: simon tags: trunk | |
|
2006-11-15
| ||
| 17:42 | Chris Boucher spotted that after "-nc" was added (r6823), cfg->ssh_nc_host was not always initialised, which could lead to spurious attempts to open a bogus channel (typically refused: "FATAL ERROR: Server refused to open a direct-tcpip channel"). Fixed. check-in: 8472f487a9 user: jacob tags: trunk | |
| 17:12 | (Config).remote_cmd2[512] was added in r1208, but it wasn't used then and isn't now, so presumably never has been. Remove. check-in: ba05ea5d22 user: jacob tags: trunk | |
| 06:56 | publickeyfile now an RFC check-in: 81eb81326b user: jacob tags: trunk | |
| 05:48 | Link to faq-cleanup from faq-settings. check-in: 5174b633ca user: jacob tags: trunk | |
|
2006-11-08
| ||
| 15:15 | There's been an increase in people posting non-SSH PuTTY-related questions to comp.security.ssh, posting queries that are clearly about PuTTY to newsgroups without actually mentioning PuTTY, and so on. They may have been directed there by this document :( Add a futile attempt to instil a sense of etiquette. check-in: eac1e0cf0e user: jacob tags: trunk | |
|
2006-11-07
| ||
| 18:55 | Administrivia: most SSH-2 specs are no longer drafts. check-in: a5a1de44c9 user: jacob tags: trunk | |
|
2006-10-31
| ||
| 10:59 | Tiny comment fix. check-in: 2a8b9e487d user: jacob tags: trunk | |
|
2006-10-22
| ||
| 15:19 | Spotted by Tim Kosse: we were returning an incorrect path in canonify() when we couldn't get any sense out of the server. check-in: a809c336dd user: jacob tags: trunk | |
| 14:51 | Minor semantic tweak to bug-compatibility modes: make BUG_NEEDS_SSH1_PLAIN_PASSWORD do exactly what it says on the tin, independent of whether BUG_CHOKES_ON_SSH1_IGNORE is set. This is invisible in the default configuration, as all servers marked as having the second bug have the first one too, but it would allow one to manually configure PuTTY to cope with a SSH-1 server that got upset by ignore messages during authentication, but was fine with their use as keepalives. check-in: d0102515d4 user: jacob tags: trunk | |
|
2006-10-03
| ||
| 12:16 | Disable a bunch of undesirable termios flags. ICRNL, in particular, is liable to have been set on serial ports previously used as terminal devices, and definitely wants not to be set on serial ports being used for callout. check-in: b632e7b72f user: simon tags: trunk | |
|
2006-10-02
| ||
| 15:52 | IXON and IXOFF belong in _iflag_, not cflag! While I'm here, be more reliable in clearing of RTS/CTS flags. check-in: 4a236e9e9f user: simon tags: trunk | |
|
2006-09-21
| ||
| 06:48 | Fix breakage of `Restart Session' in r6802. When restarting the session, we were clearing the new session_closed flag, but failing to clear must_close_session; with that set, the session was being opened but immediately re-closed. check-in: 856b30b874 user: simon tags: trunk | |
|
2006-09-15
| ||
| 09:44 | Note that the dynamic-tunnel proxy does not support UDP, since we get asked about this quite often. check-in: 83c7b4cc04 user: jacob tags: trunk | |
|
2006-09-05
| ||
| 17:08 | CSI 3 J now clears the scrollback, as in xterm. check-in: de3c767e85 user: jacob tags: trunk | |
| 16:41 | I seem to have slightly funted Plink's display of banners etc in r6437, oops. Fixed. check-in: 93bc517218 user: jacob tags: trunk | |
| 16:39 | Slight change to password expiry UI for the benefit of Cisco servers, which are as usual slightly odd. check-in: 2887f76e0f user: jacob tags: trunk | |
|
2006-09-03
| ||
| 09:31 | Support for an alternative mechanism for displaying wide characters under X: instead of having two separate fixed-width fonts one of which is twice the width of the other, you can instead have a single font in which some characters are twice as wide as others. This is implemented very simply: if you specify a wide font, it will be used for wide characters, and if you don't then the normal font will be used for wide characters (so they'd better _be_ wide in that font, or there'll be trouble). I got this idea from Jed, whose latest version supports UTF-8 and requires a font of this type. If there are going to be X fonts like that kicking around, there will doubtless be people who want to use them. check-in: 8007266fdc user: simon tags: trunk | |
| 07:55 | Add a mini-rant to the top comment explaining why threads are required. (I just tried getting rid of them; it worked fine for serial ports, but not for anything else. The Windows I/O API sucks.) check-in: b2cd494085 user: simon tags: trunk | |
|
2006-08-29
| ||
| 16:46 | Updates for today's changes: - changes to Logging panel - breaks in serial backend (Plus, completely unrelated, an index term entry related to port forwarding which seems to have been sitting around for ages, possibly waiting for me to think about `see also' index terms in Halibut.) check-in: 8f65282e5c user: jacob tags: trunk | |
| 14:07 | New logging mode, which records the exact bytes sent over the wire in an SSH connection _in addition_ to the decrypted packets. This will hopefully come in useful for debugging wire data corruption issues: you can strace the server, enable this mode in the client, and compare the sent and received data. I'd _like_ to have this mode also log Diffie-Hellman private exponents, session IDs, encryption and MAC keys, so that the resulting log file could be used to independently verify the correctness of all cryptographic operations performed by PuTTY. However, I haven't been able to convince myself that the security implications are acceptable. (It doesn't matter that this information would permit an attacker to decrypt the session, because the _already_ decrypted session is stored alongside it in the log file. And I'm not planning, under any circumstances, to log users' private keys. But gaining access to the log file while the session was still running would permit an attacker to _hijack_ the session, and that's the iffy bit.) check-in: 5b5937160f user: simon tags: trunk | |
| 13:50 | Explicitly closing logctx on various kinds of error exit means that the log file gets fclosed properly and the critical last few messages might be recoverable from the log file more often... check-in: b802bd4ac5 user: simon tags: trunk | |
| 13:32 | The Windows HANDLE type, despite being a `void *', does not actually behave like a pointer. In particular, the right thing to set a HANDLE to to indicate that it's invalid is INVALID_HANDLE_VALUE, not NULL. Crack down on sloppy use of NULL HANDLEs across all Windows code. (There is one oddity, which is that {Create,Open}FileMapping are documented to return a NULL HANDLE instead of INVALID_HANDLE_VALUE on failure. Shrug. If MS want to be inconsistent, I suppose I have to live with it.) check-in: 8c6438590b user: simon tags: trunk | |
| 13:20 | Support for sending serial breaks, in both the Windows and Unix serial backends. check-in: 92fba70907 user: simon tags: trunk | |
| 04:18 | Inhibit the Serial configuration panel in mid-session if the session isn't a serial one. In particular, this causes pterm not to fail an assertion if you select `Change Settings'. Ahem. check-in: 0f9a8f4bb2 user: simon tags: trunk | |
|
2006-08-28
| ||
| 14:09 | Apparently MsgWaitForMultipleObjects doesn't always return the values one might expect, which means that GetMessage() was occasionally blocking the process. That appears to be the last of the annoying data loss issues, so I think the Windows serial back end actually looks vaguely reliable now. Phew. check-in: b83e5fdf72 user: simon tags: trunk | |
| 13:36 | That OVERLAPPED fix seems to have made flow control useful as well (presumably Windows's serial buffer is actually _filling up_, causing an XOFF to be sent, now that my dodgy I/O code isn't causing it to leak). So I think I'll switch the default flow control to XON/XOFF, since it actually seems to do something now. check-in: eca76f8423 user: simon tags: trunk | |
| 13:27 | Eep! Next bit flag after 1 and 2 is _4_, not 3. Perhaps it's time I stopped coding and went and sat down quietly and tried not to touch anything for a while. check-in: 8e09b64fa5 user: simon tags: trunk | |
| 13:26 | Reading 4K at a time from a serial port turns out to be a bit unfriendly in an interactive session, because at 19200 baud it takes nearly two seconds to receive that much data, and as long as the data is flowing continuously Windows waits until it has a full buffer. So here's another annoying flag in the winhandl API, which restricts reads to length 1 so that serial output shows up as it appears. (I tried this yesterday, but without the OVERLAPPED fix in r6826 it behaved very erratically. It now seems solid.) check-in: da46d6cd48 user: simon tags: trunk | |
| 13:16 | Apparently it helps for an OVERLAPPED structure to contain a valid event handle. This seems to have fixed _some_, but not all, of the curious data loss issues in the Windows serial backend. check-in: 51fdd5e6b1 user: simon tags: trunk | |
| 12:47 | Minor tweaks to -nc: - log host:port in event log - add -nc to Plink usage message check-in: 6310d3d2a4 user: jacob tags: trunk | |
| 12:41 | Missed a couple of instances of cfg_launchable(). check-in: 451f6c4481 user: simon tags: trunk | |
| 10:12 | New command-line option in Plink (and PuTTY, though it's less useful there): `plink host -nc host2:port' causes the SSH connection's main channel to be replaced with a direct-tcpip connection to the specified destination. This feature is mainly designed for use as a local proxy: setting your local proxy command to `plink %proxyhost -nc %host:%port' lets you tunnel SSH over SSH with a minimum of fuss. Works on all platforms. check-in: 3171b7e2b9 user: simon tags: trunk | |
| 09:29 | Serial back end for Unix. Due to hardware limitations (no Linux box I own has both an X display and a working serial port) I have been unable to give this the full testing it deserves; I've managed to demonstrate the basic functionality of Unix Plink talking to a serial port, but I haven't been able to test the GTK front end. I have no reason to think it will fail, but I'll be more comfortable once somebody has actually tested it. check-in: d6cb32325e user: simon tags: trunk | |