Use the POSIX PATH_MAX if it exists, and fall back to 1024 otherwise.
We should really allocate filenames dynamically if PATH_MAX isn't defined.
[originally from svn r6307]
hang when reading it because strtok() kept getting the full list passed in.
Fix this, and add an assert() for an assumption documented in a comment while
I'm in the area.
[originally from svn r6294]
patched OpenSSH server. This is controlled by the same user settings
as diffie-hellman-group-exchange-sha1, which may not be optimal, especially
given that they're both referred to as dh-gex-sha1 in saved sessions.
[originally from svn r6272]
diffie-hellman-group-exchange-sha256, which the last DHGEX draft defined.
Code lifted from Simon's "crypto" directory, with changes to make it look
more like sshsh512.c.
[originally from svn r6252]
storing a SHA-1 hash of the client and server version strings, store the
strings themselves so we can feed them through the appropriate hash when
we know what it is.
[originally from svn r6241]
processed and incoming data being processed out of order, which I suspect is
the cause of `ssh1-fwd-trouble' as noted by Gevan Dutton. I'm not able to
test the failure case, but it doesn't seem to have obviously broken anything
in the cases I have tested, anyway.
[originally from svn r6221]
our app-private window messages, which is considerably higher than the
WM_XUSER we arbitrarily chose. (This isn't known to be causing any actual
problems. The fix seems not to have obviously broken anything.)
[originally from svn r6183]
[this svn revision also touched putty-wishlist]
marks a version string. It's a bit vague about the definition of a line,
but I think it's reasonable to assume that they'll end with LF. Change
do_ssh_init() to ignore "SSH-" anywhere else. This makes the existing state
machine overkill, so replace it with something a little more readable.
[originally from svn r6138]
Discourage more strongly mirrors in well-served areas in the Feedback section.
Also, duplicate that text on the Mirrors page, along with a request to tell us
the country (since lots of people still don't).
[originally from svn r6109]
[this svn revision also touched putty-website]
rationale (as mailed to him):
I think you're right. I got the pronunciation there from the second edition
of the OED and my Collins dictionary at home, both of which believe that
"pretty" is pronounced /'prItI/, but, at least to me, those two vowels are
different. Both of them think that /i/ doesn't occur in English words, the
vowel in "beat" being /i:/. The third edition of the OED, though, adds /i/
as an English vowel in its pronunciation guide, with "happy" as an example
of its use. I'll update the FAQ following your suggestion.
[originally from svn r5989]
do_ssh2_transport() was returning the wrong value for rekeys after the first.
This apparent error was introduced in r4901, but we can't see any reason for
the change to have been made. If it turns out to be a mistake to revert it,
I'm sure we'll find out.
Here for posterity is Simon's analysis:
| A lot of the return values from do_ssh2_transport appear to be vestigial: it
| used to be that a zero return from do_ssh2_transport meant it had handled the
| packet internally, and a 1 return meant the packet wasn't a transport-layer
| one and needed to pass on to do_ssh2_authconn. Since r4901, however, the
| layer discrimination is done based on the message type ranges, and the only
| remaining dependency on the return value from do_ssh2_transport is a special
| case in ssh2_protocol which detects the first 1 return and makes the
| initialisation call to do_ssh2_authconn.
|
| Therefore, the gratuitous 1 return on every key exchange as a result of the
| confusing if statement is simply ignored in ssh2_protocol (because
| ssh->protocol_initial_phase_done is already TRUE). So the remaining question
| was, why does the _lack_ of that 1 return not cause a problem, if the if's
| sense is indeed reversed?
|
| The answer is that 1 is still returned, just not by the crReturn inside the
| if statement. It's returned by the next crReturn, just after
| wait_for_rekey(). Which suggests that in fact, the if statement has the
| correct sense, but the crReturn inside it has the wrong value - it should be
| returning _zero_, to indicate that every NEWKEYS after the first one is
| uninteresting to the authconn code, and on the very first run through that
| doesn't happen and the NEWKEYS gets all the way to the crReturn(1) later on.
[originally from svn r5986]
[r4901 == a4ba026838]
enforce the following:
* Packet must have at least one byte of payload and four bytes of padding.
* Total packet length must not exceed 35000 bytes compressed.
* Total packet length including length field must be a multiple of cipher
block size (or eight bytes).
The feebleness of our old checks was noticed by Ben Rudiak-Gould.
[originally from svn r5981]
eaten by the trailing "\f0" on the RTF preamble. The RTF spec (1.0 and 1.6)
suggests that adding a space should defuse this situation and be otherwise
harmless, and it works for me (Win98).
[originally from svn r5931]
and add the ability to treat a local disconnection as "unclean" -- notably, if
we can't agree any authentication methods to even try; someone was complaining
that the PuTTY window by default just disappears for no apparent reason in this
circumstance.
Also, use appropriate disconnect codes for those SSH2_MSG_DISCONNECT messages
that we do send.
I don't think I've seriously broken any user-visible behaviour, but the way
that connection-close distinctions are transmitted to the front-end is shaky
(or so it seems to me), so there may be non-ideal changes on some platforms.
[originally from svn r5824]
