compute (100*a)/b. Instead compute 100*(a/b), because that way
there's no chance that 100*a will become inexact enough to fail to
yield 100 when a==b.)
[originally from svn r1254]
range of Unicode characters. Not entirely sure I understand this one
but I trust that RDB knows what he's talking about with Unicode.
[originally from svn r1246]
characters that failed the UTF-8 canonicality rules were being sent
to the session log twice. Sounds trivial, but I bet it'd have
confused anyone who turned on session logging precisely to track
down a canonicality bug :-)
[originally from svn r1244]
settings file is unrecognised (i.e. PuTTYtel reading PuTTY's
registry), fall back to the default _port_ as well as the default
protocol.
[originally from svn r1242]
Alt-Space, Alt-only and the System menu. It lets Windows do more of
the work, and also saves a static variable, so it must be good :-)
[originally from svn r1237]
mouse tracking is enabled. (This can be turned off if your app
really wants Shift+mouse, but it defaults to on for general
usefulness.)
[originally from svn r1235]
numeric code page, and also reinstate the direct-to-font zero
translation mode (but now under an actual _name_ rather than blank).
Also add CP437 to the list since at least one expatriate DOS user
wanted it; also select a sensible ISO or KOI codepage based on the
system locale.
[originally from svn r1230]
can't start the sftp subsystem. This should enable convenient sftp
access to SSH1-only systems: all the admin needs is to install
sftp-server in the right place.
[originally from svn r1228]
_think_ there was an exploit (even if the server sends "c:foobar",
the client will not attempt to create "c:foobar"; instead it will
try to create ".\c:foobar" which will fail), but it's as well to be
sure.
[originally from svn r1223]
construction. Doesn't actually affect anything right now, since the
bug was a failure to round a length up to the next multiple of 4 and
it so happens that our current message was exactly 40 bytes anyway
:-) But if we start giving a wider variety of messages one day then
it might be handy to be able to do them without gratuitous crashes.
[originally from svn r1222]
causes password login to occur on a server that supports password-
through-k-i. Of course when we use the new preference list mechanism
for selecting the order of authentications this will all become much
more sane, but for the moment I've put publickey back up to the top
and things seem to be happier.
[originally from svn r1220]
code _ever_ worked before! But it's been like this for four months
and nobody has noticed, including me. That's quite spooky.
[originally from svn r1219]
(as well as showing it for cut and paste). For SSH1, this feature is
largely cosmetic and added for orthogonality; it comes into its own
in SSH2, where it saves the Official One True Public Key Format as
specified in the draft spec, and more particularly as used by
ssh.com's product for authentication. Now that ssh-3.0.1 supports
RSA user keys, this is suddenly actually useful.
[originally from svn r1217]
done properly (by binding to INADDR_LOOPBACK) instead of hackishly
(by binding to INADDR_ANY, looking at the peer address when a
connection is accepted, and slamming the connection shut at that
point).
[originally from svn r1215]
CHANNEL_OPEN_FAILURE messages, which occur when the remote side is
unable to open a forwarded network connection we have requested. (It
seems they _don't_ show up if you get something mundane like
Connection Refused - the channel is cheerfully opened and
immediately slammed shut - but they do if you try to connect to a
host that doesn't even exist. Try forwarding a port to
frogwibbler:4800 and see what you get.)
[originally from svn r1213]
_right_ way. (SSWs are disabled by default and can be re-enabled
using `-unsafe', meaning that pscp will _never_ do anything
unexpected to your local file system unless you explicitly give
consent. The sftp-based variant will work fine because the
corresponding mechanism is _not_ unsafe.)
[originally from svn r1212]
scp1 if it can't. Currently not very tested - I checked it in as
soon as it completed a successful recursive copy in both directions.
Also, one known bug: you can't specify a remote wildcard, because by
the nature of SFTP we'll need to implement the wildcard engine on
the client side. I do intend to do this (and use the same wildcard
engine in PSFTP as well) but I haven't got round to it yet.
[originally from svn r1208]
actually get things done. I'm sure this is the second time I've
checked in this mistake :-/ Still, this time I've got right to the
bottom of the cause, and commented it clearly. Phew.
[originally from svn r1207]
malicious SCP server could have written to areas other than the ones
the user requested; cleared up buffer overruns everywhere. Hopefully
we now do not use arbitrary buffer limits _anywhere_.
[originally from svn r1205]
