today reported an SSH2_MSG_UNIMPLEMENTED from a Cisco router which
looks as if it was triggered by SSH2_MSG_IGNORE, so I'm
experimentally putting this flag in. Currently must be manually
enabled, though if it turns out to solve the user's problem then
I'll probably add at least one version string...
[Edited commit message: actually, I also committed in error a piece
of experimental code as part of this checkin. Serve me right for not
running 'svn diff' first.]
[originally from svn r8926]
function in terminal.c, and replace the cloned-and-hacked handling
code in all our front ends with calls to that.
This was intended for code cleanliness, but a side effect is to make
the GTK arrow-key handling support disabling of application cursor
key mode in the Features panel. Previously that checkbox was
accidentally ignored, and nobody seems to have noticed before!
[originally from svn r8896]
UTF-16 when exchanging wchar_t strings with the front end. Enabled
by a #define in the platform's header file (one should not
promiscuously translate UTF-16 surrogate pairs on 32-bit wchar_t
platforms since that could give rise to redundant encoding attacks),
which is present on Windows.
[originally from svn r8495]
as unsigned char. This means that passing in a bare char is incorrect on
systems where char is signed. Sprinkle some appropriate casts to prevent
this.
[originally from svn r8406]
has width and height swapped. Since both a random xterm I have and
<http://invisible-island.net/xterm/ctlseqs/ctlseqs.txt> agree with him, I've
changed ours. (This stuff appears to originate in dtterm, but I can't check the
behaviour of that right now.)
While I'm here, the are-we-iconified report (CSI 11 t) looks to have the
wrong sense compared to the same sources, so swap that too.
(All this has been this way since it was originally implemented in r1414,
which doesn't cite a source. all-escapes is silent too.)
[originally from svn r8376]
[r1414 == bb1f5cec31]
The scenario: I start a small, say 80x24, pterm. I do some work in
it, generating plenty of scrollback, and eventually I `less' a file.
`less' switches to the alt screen. Then I want more vertical space
to look at the file, so I enlarge the window to more like 80x60.
When I quit `less' and switch back to the primary screen, some
scrollback has been pulled down into the screen, as expected - but
the saved _cursor position_ is still at line 24, not at the bottom
of the new terminal where the prompt it goes with has moved to.
Solution: term_size() should adjust the alt-screen saved cursor
positions as well as the normal cursor position.
(Curiously, the problem doesn't happen on my home Debian box, even
without this fix. It happens on my RH9 box at work, though.)
[originally from svn r7911]
term_provide_resize_fn() was not being broken when the back end was
destroyed on session termination, causing resizing an inactive PuTTY
to be a segfault hazard.
[originally from svn r7143]
We now have an option where a remote window title query returns a well-formed
response containing the empty string. This should keep stop any server-side
application that was expecting a response from hanging, while not permitting
the response to be influenced by an attacker.
We also retain the ability to stay schtum. The existing checkbox has thus
grown into a set of radio buttons.
I've changed the default to the "empty string" response, even in the backward-
compatibility mode of loading old settings, which is a change in behaviour;
any users who want the old behaviour back will have to explicitly select it. I
think this is probably the Right Thing. (The only drawback I can think of is
that an attacker could still potentially use the relevant fixed strings for
mischief, but we already have other, similar reports.)
[originally from svn r7043]
I've been having with the cursor sometimes restoring to the wrong
place when screen(1) terminates. The offending sequence of escape
sequences goes ESC 7 (save cursor), ESC [?47h (switch to alternate
screen), ESC 7 (save cursor _again_), do some stuff, ESC 8 (restore
cursor), run screen session for a bit, ESC [?47l (return to main
screen), ESC 8 (restore cursor). The final ESC 8 is expected to
restore the cursor to where it was saved by the initial ESC 7.
Translation: the ESC 7 saved cursor state is part of the state we
must swap out when switching to the alternate screen. In other
words, we need to track _four_ cursor positions: active and saved,
on each of main and alternate screen. Previously we were tracking
only three.
[originally from svn r6788]
we otherwise would (for instance, if Shift is released before the mouse button
being used for selection).
[originally from svn r6727]
[this svn revision also touched putty-wishlist]
accepting 'G' as a hex digit. (The _first_ digit of the sequence
intentionally goes up further than F, but the remaining ones
shouldn't have.)
[originally from svn r6581]
A growable buffer was only being grown for actual text, not for newlines or
trailing NULs. A large run of empty lines could lead to newlines overflowing
the buffer (> 100 should be enough to guarantee this on all platforms, after
the initial 5k size of the buffer).
Also fix some valgrind in the same area (was probably harmless), and a memory
leak introduced by the RTF attribute pasting.
[originally from svn r6570]
[this svn revision also touched putty-wishlist]
basis for other terminal-involving applications: a stub
implementation of the printing interface, an additional function in
notiming.c, and also I've renamed the front-end function beep() to
do_beep() so as not to clash with beep() in lib[n]curses.
[originally from svn r6479]
abstracted out; replace loops structured around a single interaction
per loop with less tortuous code (fixes: `ki-multiprompt-crash',
`ssh1-bad-passphrase-crash'; makes `ssh2-password-expiry' and
`proxy-password-prompt' easier).
The new interaction abstraction has a lot of fields that are unused in
the current code (things like window captions); this is groundwork for
`gui-auth'. However, ssh.c still writes directly to stderr; that may
want to be fixed.
In the GUI apps, user interaction is moved to terminal.c. This should
make it easier to fix things like UTF-8 username entry, although I
haven't attempted to do so. Also, control character filtering can be
tailored to be appropriate for individual front-ends; so far I don't
promise anything other than not having made it any worse.
I've tried to test this fairly exhaustively (although Mac stuff is
untested, as usual). It all seems to basically work, but I bet there
are new bugs. (One I know about is that you can no longer make the
PuTTY window go away with a ^D at the password prompt; this should be
fixed.)
[originally from svn r6437]
[this svn revision also touched putty-wishlist]
Unix Plink sends everything sensible it can find, and it's fully configurable
from the GUI.
I'm not entirely sure about the precise set of modes that Unix Plink should
look at; informed tweaks are welcome.
Also the Mac bits are guesses (but trivial).
[originally from svn r5653]
[this svn revision also touched putty-wishlist]
<http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c>.
This is identified both internally and in HTTP headers as 2003-05-20,
for Unicode 4.0.
Only changes from upstream are to make mk_wcwidth_cjk() non-static and to
#include "putty.h" for prototypes.
The status of some code points has changed; see the wishlist item. We've
had some feedback from the CJK and Arabic communities that upgrading is
probably the right thing to do.
[originally from svn r5547]
[this svn revision also touched putty-wishlist]
discussed. Use Barrett and Silverman's convention of "SSH-1" for SSH protocol
version 1 and "SSH-2" for protocol 2 ("SSH1"/"SSH2" refer to ssh.com
implementations in this scheme). <http://www.snailbook.com/terms.html>
[originally from svn r5480]
its `line != NULL' assertion, so I've replaced the assertion with a
call to fatalbox() giving oodles of information. I may still not be
able to reproduce it, but at least next time it happens we should
see a decent amount of debugging data!
[originally from svn r5447]
to call _either_ do_text() _or_ do_cursor() on a given character
cell. In fact you're supposed to call do_text() no matter what, and
then call do_cursor() as well if it's got the cursor on it, since
do_cursor() _only_ draws the actual cursor, which often doesn't also
cause the text to get drawn.
I'm half tempted to change this in the interface, retire do_cursor()
as an external function and relegate it to an internal function in
each front end, and require that do_text() must fully process all
cursor attributes it is passed. However, I haven't done this yet.
[originally from svn r5017]
the start of every contiguous run passed to do_text() or
do_cursor(), and arranges never to overwrite only part of such a run
on the next update.
I'm a bit worried about this checkin because I've also completely
revamped cursor handling: the cursor was previously being drawn
_outside_ the main loop over the display line, and is now drawn as
part of that loop when it gets to the cursor location. It _seems_ to
still work sensibly, even in complex cases involving LATTR_WIDE and
double-width CJK characters etc, but I won't be entirely happy until
it's had some beta use.
[originally from svn r5003]
[this svn revision also touched putty-wishlist]
going through the line and working out which bits need to be redrawn
is now in a separate loop from the subsequent activity of actually
going through and doing the redraws. This _should_ enable me to
tinker with the which-bits-to-redraw data in between the two, thus
fixing `font-overflow'. However, I thought it would be sensible to
break the work up into two commits so we can track bugs in the
restructuring separately from bugs introduced by the new feature.
Also added a couple more terminal test files.
[originally from svn r5001]
results in unacceptable performance for him on Win2000. Add a checkbox to
revert to the old behaviour.
[originally from svn r4988]
[this svn revision also touched putty-wishlist]
_width_ of a terminal line (number of character cell positions) and
its _size_ (number of termchars), since of course these differ in
the presence of combining characters.
[originally from svn r4938]
