trying to _follow_ it for the first time :-) And also due to the
fact that it now needs to mention the Unix source tarball as well.
[originally from svn r3853]
It appears that this is because Visual C's sscanf works by first
calling strlen to get the length of the string, so that its internal
read-character routine can be sure of never overrunning the buffer.
Quite why the internal read-char routine can't detect \0 _itself_
rather than having to have it found for it in advance I have no
idea. Sigh.
[originally from svn r3844]
will validate an md5sums manifest and if all md5sums match will use
a version number provided in a file. This should allow me to produce
a Unix release source archive with the property that when unpacked
and built it will produce binaries advertising themselves as
`Release X.YZ', but as soon as the user starts fiddling with the
sources it will revert to `Unidentified build' (though of course the
user can still _explicitly_ ask for a release tag, and in fact this
will override the default if any default is specified).
[originally from svn r3818]
keys. This _appears_ to be due to me computing the byte count of the
key by dividing the bit count by 8 and rounding _down_ rather than
up. Therefore, I can't see how this code could ever have worked on
any SSH2 RSA key whose length was not a multiple of 8 bits; and
therefore I'm staggered that we haven't noticed it before! OpenSSH's
keygen appears to be scrupulous about ensuring the returned key
length is exactly what you asked for rather than one bit less, but
even so I'm astonished that _all_ keygen implementations for servers
we've ever interoperated with have avoided tripping this bug...
[originally from svn r3815]
trying to bind to the localhost interface with a sockaddr_in which has non-zero
sin_zero fields." Zero sockaddr_in (and sockaddr_in6) before any use.
[originally from svn r3793]
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]
simply doesn't work - if multiple concurrent agent requests are
attempted, some of them will fail for no apparent reason. I assume
concurrent SendMessage() calls don't work in the Windows API, or
some such. So I'm commenting out the async code for the moment
(there wasn't a Windows Pageant that made helpful use of it anyway
yet) and returning to the drawing board.
[originally from svn r3756]
negative font sizes (meaning pixels) into positive ones (points) in
winstore.c, since it gets done anyway at the point of font creation;
and removing the code in winstore.c means that the precise font
entered by the user is saved in the config, rather than being
rounded.
[originally from svn r3755]
on the PSFTP `open' command; it was arguably a bug that this command
couldn't do such an obvious thing that could be done from the main
command line. Also had to fix a NULL-dereference in do_sftp_cleanup
in the process.
[originally from svn r3754]
caused a small amount of extra inconvenience at the tops of .rc
files, but it's been positive overall since lcc has managed to point
out some pedantic errors (typically static/extern mismatches between
function prototypes and definitions) which everything else missed.
[originally from svn r3744]
clicks in the top left of the window should not be detected by
comparing the coordinates with (0,0) since this won't work on
secondary monitors.
[originally from svn r3742]
states that plug_receive() may recurse back into
sk_proxy_set_frozen() again. Therefore, bufchain_consume() should
have been called _before_ calling plug_receive(), to prevent an
infinite loop overflowing the stack. I can't immediately figure out
under what circumstances this might happen, but it seems an
obviously sensible precaution.
[originally from svn r3741]
- update usage info in tools
- ack, plink is over 24 lines now
- update man pages for Unix version
- Doc changes:
- move long description from (GUI) "config" to "using"
- sorry if complete specification isn't what this section is meant for,
but if you only read "using" it was hard to find.
- ensure enough references to this made in other sections (GUI,
command-line)
- update instance of plink usage info
[originally from svn r3740]