* All the PuTTY tools for Windows and Unix now contain the fingerprints of
the Master Keys. The method for accessing them is crude but universal:
a new "-pgpfp" command-line option. (Except Unix PuTTYgen, which takes
"--pgpfp" just to be awkward.)
* Move the key policy discussion from putty-website/keys.html to
putty/doc/pgpkeys.but, and autogenerate the former from the latter.
Also tweak the text somewhat and include the fingerprints of the
Master Keys themselves.
(I've merged the existing autogeneration scripts into a single new
one; I've left the old scripts and keys.html around until such time
as the webmonster reviews the changes and plumbs in the new script;
he should remove the old files then.)
[originally from svn r5524]
[this svn revision also touched putty-website]
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]
This was harder than verify_ssh_host_key() and askalg() put
together, because:
(a) askappend() can be called at any time, since it's a side effect
of data-logging functions. Therefore there can be an unfinished
askappend() alert at any time, and hence the OS X front end has
to be prepared to _queue_ other alerts which occur during that
time.
(b) logging.c has to do something with data that comes in while
it's waiting for an answer to askappend(). It buffers it until
it knows what the user wants done with it. This involved
something of a reorganisation of logging.c.
[originally from svn r5344]
now returns an integer: 0 means cancel the SSH connection and 1
means continue with it. Additionally, they can return -1, which
means `front end has set an asynchronous alert box in motion, please
wait to be called back with the result', and each one is passed a
callback function pointer and context for this purpose.
I have not yet done the same to askappend() yet, because it will
take a certain amount of reorganisation of logging.c.
Importantly, this checkin means the host key dialog box now works on
OS X.
[originally from svn r5330]
changing its mouse pointer. Currently this is only used in the (slightly-
arbitrarily-defined) "heavy" bits of SSH-2 key exchange. We override pointer
hiding while PuTTY is busy, but preserve pointer-hiding state.
Not yet implemented on the Mac.
Also switch to frobbing window-class cursor in Windows rather than relying on
SetCursor().
[originally from svn r5303]
deal with rekeys at all: they totally ignore mid-session KEXINIT
sent by the client. Hence, a new bug entry so we don't try it.
[originally from svn r5092]
of polishing to bring them to what I think should in principle be
release quality. Unlike the unfix.org patches themselves, this
checkin enables IPv6 by default; if you want to leave it out, you
have to build with COMPAT=-DNO_IPV6.
I have tested that this compiles on Visual C 7 (so the nightlies
_should_ acquire IPv6 support without missing a beat), but since I
don't have IPv6 set up myself I haven't actually tested that it
_works_. It still seems to make correct IPv4 connections, but that's
all I've been able to verify for myself. Further testing is needed.
[originally from svn r5047]
[this svn revision also touched putty-wishlist]
mid-session if we are not using SSHv1. I've done this by introducing
a generic `cfg_info' function which every back end can use to
communicate an int's worth of data to setup_config_box; in SSH
that's the protocol version in use, and in everything else it's
currently zero.
[originally from svn r5040]
[r5031 == d77102a8d5]
(which will gain more content anon).
Retire BUG_SSH2_DH_GEX and add a backwards-compatibility wart, since we never
did find a way of automatically detecting this alleged server bug, and in any
case there was only ever one report (<3D91F3B5.7030309@inwind.it>, FWIW).
Also generalise askcipher() to a new askalg() (thus touching all the
front-ends).
I've made some attempt to document what SSH key exchange is and why you care,
but it could use some review for clarity (and outright lies).
[originally from svn r5022]
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]
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]
timing.c, and hence takes its own responsibility for calling
noise_regular() at regular intervals. Again, this means it will be
called consistently in _all_ the SSH-speaking tools, not just those
in which I remembered to call it!
[originally from svn r4913]
blink when the window doesn't have focus, we don't schedule blink
timers at that point either.
Infrastructure change: term->has_focus should now not be written
directly from outside terminal.c. Instead, use the function
term_set_focus, which will sort out the blink timers as well.
[originally from svn r4911]
which pretty much any module can call to request a call-back in the
future. So terminal.c can do its own handling of blinking, visual
bells and deferred screen updates, without having to rely on
term_update() being called 50 times a second (fixes: pterm-timer);
and ssh.c and telnet.c both invoke a new module pinger.c which takes
care of sending keepalives, so they get sent uniformly in all front
ends (fixes: plink-keepalives, unix-keepalives).
[originally from svn r4906]
[this svn revision also touched putty-wishlist]
of the SSH servers I conveniently have access to (Debian stable OpenSSH --
3.4p1 -- and lshd) seem to take a blind bit of notice, but the channel
requests look fine to me in the packet log.
I've included all the signals explicitly defined by
draft-ietf-secsh-connect-19, but I've put the more obscure ones in a submenu
of the specials menu; there's therefore been some minor upheaval to support
such submenus.
[originally from svn r4652]
the same window (Windows version only).
Policy change: it's now the backend's responsibility to call
update_specials_menu() at the start of a session (or whenever it feels ready),
if it has any special commands. Otherwise the menu won't be displayed.
[originally from svn r4649]
http://www.cl.cam.ac.uk/~mgk25/unicode.html#activate
feels strongly that it should be easy to make _all_ your
applications work in UTF-8 mode, without having to remember a switch
for each one. Every application should simply note a UTF-8 locale
setting and switch into UTF-8 mode automatically.
Therefore, for the Unix port only, there's now a checkbox, enabled
by default, which causes the drop-down Translation box to be
overridden if the locale indicates UTF-8. Anyone who doesn't like
this, or doesn't like MGK, is welcome to turn it straight back off.
I'm not _completely_ convinced by MGK's argument myself; for
xterm/pterm to do _useful_ UTF-8 you also need to specify a decently
Unicode-capable font, and there's no way _that_ can be automagically
done on noticing a locale setting. But it's a de facto standard
(i.e. xterm does it :-) so I might as well at least be _able_ to
support it.
[originally from svn r4648]
array of each `termline' structure now contains optional additional
entries after the normal number of columns, which are used to chain
a linked list of combining characters off any primary termchar that
needs it. This means we support arbitrarily many combining
characters per cell (unlike xterm's hard limit of 2).
Cut and paste works correctly (selecting a character cell containing
multiple code points causes all those code points to be cut and
pasted). Display works by simply overlaying all the relevant
characters on top of one another; this is good enough for Unix
(xterm does the same thing), and mostly seems OK for Windows except
that the Windows Unicode fonts have a nasty habit of not containing
most of the combining characters and thus overlaying an
unknown-code-point box on your perfectly good base glyph.
I had no idea how to add support in the Mac do_text(), so I've
simply stuck in an assertion that will trigger the first time a
combining character is displayed, and hopefully this will bite
someone with the clue to fix it.
[originally from svn r4622]
PuTTY / Plink not to run a remote shell/command at all. Supported in
the GUI configuration and via the (OpenSSH-like) -N command-line
option.
No effort is currently made to arrange `nice' UI properties. If you
do this in GUI PuTTY, a full-size terminal window will still be
created, and will sit there with almost nothing in it throughout
your session. If you do it in Plink, Plink will not accept any kind
of request to terminate gracefully; you'll have to ^C or kill it.
Nonetheless, even this little will be useful to some people...
[originally from svn r4614]
The active terminal screen is no longer an array of `unsigned long'
encoding 16-bit Unicode plus 16 attribute bits. Now it's an array of
`termchar' structures, which currently have 32-bit Unicode and 32
attribute bits but which will probably expand further in future.
To prevent bloat of the memory footprint, I've introduced a mostly
RLE-like compression scheme for storing scrollback: each line is
compressed into a compact (but hard to modify) form when it moves
into the term->scrollback tree, and is temporarily decompressed when
the user wants to scroll back over it. My initial tests suggest that
this compression averages about 1/4 of the previous (32 bits per
character cell) data size in typical output, which means this is an
improvement even without counting the new ability to extend the
information stored in each character cell.
Another beneficial side effect is that the insane format in which
Unicode was passed to front ends through do_text() has now been
rendered sane.
Testing is incomplete; this _may_ still have instabilities. Windows
and Unix front ends both seem to work as far as I've looked, but I
haven't yet looked very hard. The Mac front end I've edited (it
seemed obvious how to change it) but I can't compile or test it.
As an immediate functional effect, the terminal emulator now
supports full 32-bit Unicode to whatever extent the host platform
allows it to. For example, if you output a 4-or-more-byte UTF-8
character in Unix pterm, it will not display it properly, but it
will correctly paste it back out in a UTF8_STRING selection. Windows
is more restricted, sadly.
[originally from svn r4609]
by default (although they can be included). There's also an option to remove
session data, which is good both for privacy and for reducing the size of
logfiles.
[originally from svn r4593]
when talking to SOCKS 5 proxies. Configures itself transparently (if
the proxy offers CHAP it will use it, otherwise it falls back to
ordinary cleartext passwords).
[originally from svn r4517]
`all session data' modes, without completely mauling the performance, by
fflush()ing once per term_out(). If anyone complains I suppose we can
make this optional.
[originally from svn r4445]
before "-load" is processed so that it doesn't clobber it.
I've also changed the semantics of "-load" slightly for PSCP, PSFTP,
and Plink: if it's specified at all, it overrides (disables) the
implicit loading of session details based on a supplied hostname
elsewhere (on the grounds that the user is more likely to want the
"-load" session than the implicit session). (PuTTY itself doesn't do
implicit loading at all, so I haven't changed it.)
This means that all the PuTTY tools' behaviour is now consistent iff
"-load" is specified (otherwise, some tools have implicit-session, and
others don't).
However, I've not documented this behaviour, as there's a good chance
it will be swept away if and when we get round to sorting out how we
deal with settings from multiple sources. It's intended as a "do
something sensible" change.
[originally from svn r4352]
No very good reason, but I've occasionally wanted to frob it to see if it
makes any difference to problems I'm having, and it was easy.
Tested that it does actually cause keepalives on Windows (with tcpdump);
should also work on Unix. Not implemented on Mac (does nothing), but then
neither is TCP_NODELAY.
Quite a big checkin, much of which is adding `keepalive' alongside `nodelay'
in network function calls.
[originally from svn r4309]
on Linux, but the (very few) platform-specific bits are already
abstracted out of the main code, so it should port to other
platforms with a minimum of fuss.
[originally from svn r3762]
platform-independent source file. Haven't yet added the extra
abstraction routines to uxsftp.c to create a Unix PSCP port, but it
shouldn't take long.
Also in this checkin, a change of semantics in platform_default_s():
now strings returned from it are expected to be dynamically allocated.
[originally from svn r3420]
by disabling bold-font-name guessing (if their bold fonts are ugly).
I've turned the UI inside out, but the meat is pretty much the same.
[originally from svn r3410]
discriminating on the Windows version in order to decide whether to
call MessageBeep(-1) or Beep() - I'd prefer to directly test the
specific OS property in any given case - but it looks as if this is
the best available option.
[originally from svn r3208]
box, in that it started to expand under the weight of proxy options.
Now fixed, by folding the SOCKS version selector into the general
proxy type selector so there's one single 5- or 6-way radio button
set split over two lines. settings.c has of course grown a backwards
compatibility wart to deal with legacy config data.
[originally from svn r3168]
ability to do synchronous ones as well, because PSCP and PSFTP don't
really need async ones and it would have been a serious pain to
implement them. Also, Pageant itself when run as a client of its
primary instance doesn't benefit noticeably from async agent
requests.
[originally from svn r3154]
callback function; it may return 0 to indicate that it doesn't have
an answer _yet_, in which case it will call the callback later on
when it does, or it may return 1 to indicate that it's got an answer
right now. The Windows agent_query() implementation is functionally
unchanged and still synchronous, but the Unix one is async (since
that one was really easy to do via uxsel). ssh.c copes cheerfully
with either return value, so other ports are at liberty to be sync
or async as they choose.
[originally from svn r3153]
hazard. I considered removing it completely, but I can't rule out
the possibility of an OS that actually takes security of its
terminal devices seriously, and which might be able to make sensible
and safe use of this feature.
[originally from svn r3103]
of PuTTY (terminal, backend, logctx etc) take a `void *' handle
passed to them from the frontend, and used as a context for all
their callbacks. Most of these point at the frontend structure
itself (on platforms where this is meaningful), except that the
handle passed to the backend has always pointed at the terminal
because from_backend() was implemented in terminal.c. This has
finally bitten Unix PuTTY, because both backend and logctx have
been passing their respective and very different frontend handles to
logevent(), so I've fixed it.
from_backend() is now a function supplied by the _frontend_ itself,
in all cases, and the frontend handle passed to backends must be the
same as that passed to everything else. What was from_backend() in
terminal.c is now called term_data(), and the typical implementation
of from_backend() in a GUI frontend will just extract the terminal
handle from the frontend structure and delegate to that.
This appears to work on Unix and Windows, but has most likely broken
the Mac build.
[originally from svn r3100]
former by simply removing it; the latter by adding an enumeration
function to libcharset.) This has had slight `const' repercussions
on cp_name() and cp_enumerate() which might break the Mac build.
[originally from svn r3064]
This menu is not yet fully populated, but it has an About box (yet
another licence location :-/ ) and supports the new configurable
specials menu (thus making Unix PuTTY do one tiny thing which
OpenSSH-in-a-pterm can't :-).
[originally from svn r3062]
supports SOCKS 4, SOCKS 4A and SOCKS 5 (well, actually IPv6 in SOCKS
5 isn't supported, but it'll be no difficulty once I actually get
round to it). Thanks to Chas Honton for his `stone soup' patch: I
didn't end up actually using any of his code, but it galvanised me
into doing it properly myself :-)
[originally from svn r3055]
`Special Command' menu, in which any backend can place its own list
of magical things the user might want to ask the backend to do. In
particular I've implemented the recently proposed "break" extension
in SSH2 using this mechanism.
NB this checkin slightly breaks the Mac build, since it needs to
provide at least a stub form of update_specials_menu().
[originally from svn r3054]
think it's now actually usable as a day-to-day SSH client, even if
things like the Event Log are still missing. So I call that a decent
lunch hour's work :-)
[originally from svn r3034]
