https://winscp.net/tracker/2455
Some related refactoring:
Refactoring php release script includes
Reusing complete_translations in copy_complete_translations.php
Removing obsolete maketran.bat hack
Source commit: 07476ec822e4bd7b8b1c65ceb9783b6d92f20489
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
No negative impact is know - the calls are not incremental. But it might have caused some flicker.
Source commit: 4833f200de05da107b3486f5b43dd9475a75dc4f
Check the generated fake directory name before comparing canonical paths in the clipboard fake-directory monitor callback. This keeps broad directory monitor notifications from touching unrelated paths.
Co-authored-by: jeremydixon22 <jeremydixon22@users.noreply.github.com>
https://winscp.net/tracker/2445
