Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
4 check-ins using file ssh.c version 29b7b2563a
|
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 | |