SSH_AUTH_SOCK is defined to the empty string. (Because a common way to
'unset' it is to run commands like 'SSH_AUTH_SOCK= putty -load thing'.)
[originally from svn r9225]
(o,p,r,s). They are displayed in Windows by actually writing the
centred one (q) with a vertical offset, in case fonts don't have the
offset versions; this requires terminal.c to separate those characters
into distinct calls to do_text(). Unfortunately, it was only breaking
up a text-drawing call _before_ one of those characters, not after
one. Spotted by Robert de Bath.
[originally from svn r9221]
loop that fetches the next item using conf_get_str_strs and passing
the previous key as a parameter, because the previous key will have
been freed by the intervening conf_del_str_str. Instead, use the
technique of repeatedly using conf_get_str_nthstrkey with index 0 and
deleting what comes back, as PSCP and PSFTP do.
Spotted by Minefield with the aid of Jacob, or possibly vice versa.
[originally from svn r9220]
with the entries from the source one, otherwise add234 will keep
failing ("this key already exists"). Completely broke Plink, ahem.
[originally from svn r9218]
'Config' in putty.h, which stores all PuTTY's settings and includes an
arbitrary length limit on every single one of those settings which is
stored in string form. In place of it is 'Conf', an opaque data type
everywhere outside the new file conf.c, which stores a list of (key,
value) pairs in which every key contains an integer identifying a
configuration setting, and for some of those integers the key also
contains extra parts (so that, for instance, CONF_environmt is a
string-to-string mapping). Everywhere that a Config was previously
used, a Conf is now; everywhere there was a Config structure copy,
conf_copy() is called; every lookup, adjustment, load and save
operation on a Config has been rewritten; and there's a mechanism for
serialising a Conf into a binary blob and back for use with Duplicate
Session.
User-visible effects of this change _should_ be minimal, though I
don't doubt I've introduced one or two bugs here and there which will
eventually be found. The _intended_ visible effects of this change are
that all arbitrary limits on configuration strings and lists (e.g.
limit on number of port forwardings) should now disappear; that list
boxes in the configuration will now be displayed in a sorted order
rather than the arbitrary order in which they were added to the list
(since the underlying data structure is now a sorted tree234 rather
than an ad-hoc comma-separated string); and one more specific change,
which is that local and dynamic port forwardings on the same port
number are now mutually exclusive in the configuration (putting 'D' in
the key rather than the value was a mistake in the first place).
One other reorganisation as a result of this is that I've moved all
the dialog.c standard handlers (dlg_stdeditbox_handler and friends)
out into config.c, because I can't really justify calling them generic
any more. When they took a pointer to an arbitrary structure type and
the offset of a field within that structure, they were independent of
whether that structure was a Config or something completely different,
but now they really do expect to talk to a Conf, which can _only_ be
used for PuTTY configuration, so I've renamed them all things like
conf_editbox_handler and moved them out of the nominally independent
dialog-box management module into the PuTTY-specific config.c.
[originally from svn r9214]
website _wasn't_ missing - I just looked straight past it somehow.
Fold the two versions together into one more complete than either.
[originally from svn r9206]
- for 'ixion' read 'atreus' throughout
- the signature-checking commands needed minor modifications to cope
with more *sums files
- stated a few things explicitly which were previously implied, in
case the next inter-release gap is also long enough for me to
forget them.
[originally from svn r9205]
to "winadj@putty.projects.tartarus.org" with SSH_MSG_CHANNEL_SUCCESS despite
probably having no idea what it means, treat this just the same as
SSH_MSG_CHANNEL_FAILURE instead of killing the connection.
Tested only as far as making sure that winadj/FAILURE with a normal server
isn't _completely_ broken.
[originally from svn r9185]
[this svn revision also touched putty-wishlist]
information about where to put items that aren't mentioned in the
saved configuration. So far the only nontrivial use I've made of this
facility is to default to placing KEX_RSA just above KEX_WARN in the
absence of any other information, which should fix
'ssh2-rsa-kex-pref'.
While I'm here I've rewritten wprefs() on general principles to remove
the needless length limit, since I was touching it anyway. The length
limit is still in gprefs (but I've lengthened it just in case).
[originally from svn r9181]
code (as introduced in r9043), so that it uses the user SID rather
than the default SID.
This does change the access-control model, in that a Pageant running
with administrator privilege will now serve keys to an unprivileged
PuTTY running as the same user who started Pageant. Owen and I think
this isn't a problem (in particular, it will still not serve keys to a
_different_ user).
More importantly, making the Pageant client and server code work the
same way means that PuTTY and Pageant can still talk to each other
when UAC is turned off, which we've had several reports of r9043
having broken.
[originally from svn r9178]
[r9043 == 05f22632eb]
Currently, if the IPC exchange goes wrong, the Event Log just prints
"Pageant is running. Requesting keys." and then goes on to the next
step without ever saying what happened.
[originally from svn r9177]
SIGPIPE ignored in its child processes, leading to unexpected
behaviour inside pterms. (The gnome-session I'm sitting in front of
doesn't seem to do this as far as I can tell, but I don't doubt there
are some that do.) Add SIGPIPE to the list of signals we reset to
default behaviour before launching pterm's child process.
[originally from svn r9117]
that we won't keep calling close_session() again the next time we go
round the message loop. Should fix unclean-close-hang. Thanks to Simon
Coleman for debugging.
[originally from svn r9115]
of array indices. You'd hope that compilers could automatically turn
the one representation into the other if it was faster to do so, but
apparently not: even on gcc -O3, this source transformation gains over
15% performance.
[originally from svn r9105]
routines into their callers, where they'll be done once for a whole
modpow rather than many times within each multiply. Doesn't save much
time as far as I can see - perhaps a couple of percent, one second in
the minute it takes to run the new bignum test suite - but seems like
a sensible idea anyway on general principles.
[originally from svn r9103]
mostly so I can valgrind both and make sure they free all their
workspace - a memory leak in this code would be not merely an
inconvenience but a security hazard.
[originally from svn r9101]
fallback for when Montgomery is inapplicable.
(I may also at some point switch to using it for small exponents, if
speed testing should reveal that there's a noticeable threshold beyond
which preparing the Montgomery setup is uneconomical.)
[originally from svn r9099]
testdata/bignum.py is twice the size of the rest of the PuTTY source
put together, so I'm not checking it in.
This reveals bugs in the new multiplication code, which I have yet to
fix.
[originally from svn r9097]
specified in the configuration. Jacob's userpass abstraction proves
its worth in making this a trivial job.
(Actually reported by a user - somebody's still using rlogin!)
[originally from svn r9096]
exponentiation by replacing the modulo operation by a cleverly chosen
multiplication. This was not worth doing in the previous state of the
code (because my multiply was about as slow as my modulo), but now
that multiplication has been sped up by the Karatsuba optimisation,
Montgomery becomes worthwhile.
[originally from svn r9094]
setting BignumInt to 32 bits. gcc defines _LP64 on x86-64 and
presumably on other 64-bit architectures, so I've conditioned my
defines on that in the hope that they won't need redoing for the next
few such architectures.
I've also added a set for _LLP64, but it's untested as yet.
[originally from svn r9092]
in saved sessions, so that a programmable window manager can
distinguish different PuTTYs/pterms on startup and assign them
different window management properties.
[originally from svn r9078]
and avoiding trashing a non-default port, don't treat a port of 0 as special;
this was causing defaults to "freeze in" for sequences of clicks like SSH,
Raw, Telnet.
Arrange that a port of 0 (which in a backend indicates no default) is displayed
as a blank in the port box, to make this less jarring.
[originally from svn r9077]
[r7635 == db7cc1cba6]
those in the CHAN_SOCKDATA_DORMANT state (i.e., local-to-remote forwardings
which the SSH server had not yet acknowledged).
Marcel Kilgus has been running with the ssh_do_close() patch for nearly two
years (*cough*) and reports that it has eliminated frequent
'unclean-close-crash' symptoms for him (due to the unclosed socket generating
a pfd_closing() which accessed freed memory), although I've not reproduced
that. The patch to ssh_free() is mine and not known to fix any symptoms.
[originally from svn r9069]
[this svn revision also touched putty-wishlist]
rectangle into smaller ones: it doesn't work any more, since the new
variable-pitch code can now call general_textout() with a larger
clipping rectangle than the text it's meant to be displaying. Instead,
general_textout() now uses the same semantics as the next loop up in
do_text_internal(): the first piece of text it displays uses the
opacity setting passed in, which blanks the entire clipping rectangle
if necessary, and then subsequent overlays are non-opaque. And the
same clipping rectangle is used throughout.
[originally from svn r9067]
array to ExtTextOut:
- move it inside the new big loop (this should fix a potential bug
whereby the DBCS handling altered some elements of it but the loop
did not actually step along it)
- initialise it more sensibly
- rename it to lpDx rather than IpDx, since as far as I can tell the
latter name was derived from a misreading of the former in the
Windows API docs.
[originally from svn r9066]
