The number of people has been steadily increasing who read our source
code with an editor that thinks tab stops are 4 spaces apart, as
opposed to the traditional tty-derived 8 that the PuTTY code expects.
So I've been wondering for ages about just fixing it, and switching to
a spaces-only policy throughout the code. And I recently found out
about 'git blame -w', which should make this change not too disruptive
for the purposes of source-control archaeology; so perhaps now is the
time.
While I'm at it, I've also taken the opportunity to remove all the
trailing spaces from source lines (on the basis that git dislikes
them, and is the only thing that seems to have a strong opinion one
way or the other).
Apologies to anyone downstream of this code who has complicated patch
sets to rebase past this change. I don't intend it to be needed again.
I've only just found out that it has the effect of treating the argv
words not as plain filenames, but as arguments to Perl default 'open',
i.e. if they end in | then the text before that is treated as a
command. That's not what was intended in any of these contexts!
Fortunately, in this project it only comes up in non-critical
'contrib' scripts.
Used the wrong kind of brackets when initialising the actual hash (as
opposed to hash ref) %disc_reasons. Not sure how I didn't notice the
warning in yesterday's testing!
I'm increasingly wishing I'd written this parsing program in Python,
and yet another reason why is that using argparse for the command-line
handling makes it a lot harder to forget to write the --help text when
you add an extra option.
This makes it more feasible to use logparse.pl as an output filter on
a PuTTY SSH log file and discard the original file.
In particular, ever since commit b4fde270c, I've been finding it
useful when testing new code to direct my SSH logs to a named pipe and
have another terminal window give a real-time dump of them by running
'while cat $named_pipe; do :; done'. Now I can replace the 'cat' in
that shell command with 'logparse.pl -ve' and still get the Event Log
messages as well as the unpacked contents of all the packets.
This includes picking apart the various asymmetric crypto formats
(public keys, signatures, elliptic-curve point encodings) as far as
possible, but since the verbose decoder system in logparse.pl
currently has to work without benefit of statefulness, it's not always
possible - some of the ECC formats depend for their decoding on
everyone remembering _which_ ECC protocol was negotiated by the
KEXINITs.
The type code for an mpint in the input format string is "m", not
"mpint". This hasn't come up yet as far as I can see, but as and when
I add verbose dump routines for packet types that involve asymmetric
crypto, it will.
This allows me to request a verbose dump of the contents of some
particular packet type, or for all packet types.
Currently, the only packet type for which I've written a verbose dump
function is KEXINIT, but the framework is there to add further verbose
dumpers as and when they're needed.
This provides support for ECDSA public keys, for both hosts and users,
and also ECDH key exchange. Supported curves are currently just the
three NIST curves required by RFC 5656.
It looks as if it's never worked at all: it had a spurious second
printf, it completely forgot to allow for the uint32 type code that
SSH2_MSG_CHANNEL_DATA doesn't have, it accessed the channel state's
sequence number fields in a way that made no sense and didn't match
the rest of the program, *and* it misinvoked the file opening API. I
must have never had an occasion to test it.
[originally from svn r10037]
Previously it would throw a bunch of Perl undefined-variable-usage
warnings; now it cleanly detects the problem, dumps as much of the
message as it still reasonably can, and doesn't update any channel
states.
[originally from svn r10036]
In each case, want_reply was being treated as true even when it wasn't,
because it got decoded into "yes"/"no", both of which are true in
Perl.
[originally from svn r9617]
interpretation with some analysis done on it. The script will do its
own tracking of the set of open channels and their states, and its
output is in a one-line-per-packet format such that every distinct
channel has a unique identifier in it which should make it easy to
grep out all lines relating to that channel. The script also matches
up {CHANNEL,REQUEST}_{SUCCESS,FAILURE} to the requests that caused
them, by tracking a queue of requests in each direction per channel
and for global requests. Command-line options permit generating a
final dump of all channels ever known to the script and their various
ids and final state, and also dumping out the data transferred over
each channel in each direction.
Output is not complete, in the sense that some parameters in some
messages (e.g. pixel sizes in window-size specifications) are
deliberately omitted due to being boring, and the entire contents of
some messages (e.g. KEXINIT) are omitted because I haven't yet seen
any purpose in decoding them. Filling them in might be a useful thing,
although I'm inclined to think that the default should still be to
show only the potentially interesting stuff (e.g. still not pixel
sizes!) and enable the rest using a -v option.
Hopefully this should do a lot of the legwork in debugging issues in
which a channel mysteriously remains partially open and prevents PuTTY
closing.
[originally from svn r9457]
