includes: Fix two bugs in the JCLDebug address to source lookup
(though it does not seem to have any positive impact on exception stack trace collection)
Source commit: e49c36ce4a97a6eeb4a1f43743893fdab854ba50
This prevents a couple of different possible crashes if a PPK file
constructed by something other than PuTTYgen contains invalid
parameters. If parallelism is 0 then the Argon2 code can divide by
zero; if the memory requirement is too small for the parallelism then
it can overrun a buffer.
Signed-off-by: Martin Prikryl <martin@winscp.net>
Source commit: e66db8e4bd600fd9d92467fb8b6cc31cd86fc0ad
This case led to a tight loop in ssh2_try_send, which would calculate
the largest size of data packet it could send on a channel as the min
of various things including the max packet size; find, of course, that
the largest size was therefore 0; send no data; and loop round again
to keep trying.
There's nothing you can sensibly do about that by the time you get to
ssh2_try_send, so a better response is to reject the connection at
open time.
When the connection is initiated from the far end (i.e. we receive
CHANNEL_OPEN) we can do this relatively nondestructively, by rejecting
just that one channel-open request. When it's initiated from our end,
and the CHANNEL_OPEN_CONFIRMATION we got back contained the zero
maxpkt, there's no similar protocol method for rejecting the
confirmation, so instead we disconnect the whole SSH session.
(That seems harsh, but I think it's reasonable, because one reason for
aborting an SSH connection is that you genuinely don't _know_ what
your client can legally do next – and this is exactly that situation.)
Signed-off-by: Martin Prikryl <martin@winscp.net>
Source commit: 5b7de97f5fcb3f4b957e9585ea15018831c8b547
The space allocated for the decrypted packet was 4 bytes too small,
because we end up reading (s->packetlen + s->maclen) bytes into it,
but we allocated the buffer based on the largest possible size of
(s->len + s->maclen). The two differ by 4. So if a packet is within 4
bytes of the largest size accepted by the check of s->len against
OUR_V2_PACKETLIMIT, then it overruns the buffer allocated for the
following BPP_READ.
Thanks to Yukihiro Nakamura for spotting this.
Signed-off-by: Martin Prikryl <martin@winscp.net>
Source commit: dc1ea030899bc7ec7ed4388cfc01757c41816f0c
jcld28win32.inc:
Install.bat
Selected RAD Studio 11 32 bit
Kept all defaults
Checked Install selected only
Clicked Install
Copied all files that we use to thirdparty branch
Uninstall
Source commit: a4029c76ca6ba3df0c08a4a35cc5707660ccf5a8
(JclAnsiStrings was needed already before, but until now the few needed function were manually duplicated into the target files)
Source commit: 90fe814e9098ad9611addb3fb404dd45147ed9e6
(cherry picked from commit 5d189553be)
This was by mistake previously added directly to the main code branch, but not to the thirdparty. Consequently we did not update the code with later PuTTY releases.
(cherry picked from commit 85c8d207bd)
Source commit: 530faffb051e61a40eb42bf7d2539d09dabf6c00
