under SSH-2, don't risk looking at the length field of an incoming packet
until we've successfully MAC'ed the packet.
This requires a change to the MAC mechanics so that we can calculate MACs
incrementally, and output a MAC for the packet so far while still being
able to add more data to the packet later.
[originally from svn r8334]
directly. Fixes a build failure involving name clashes between
winsock2.h and winsock.h, which had somehow managed to get included
in succession.
[originally from svn r8332]
While I'm here, a cosmetic PuTTYtel change: remove a reference to SSH from the
"logical host name" label in PuTTYtel only.
[originally from svn r8331]
[r8305 == ca6fc3a4da]
ourselves, but on Unix then assumed it was compatible with the system's
gss_buffer_desc, which wasn't the case on LP64 systems. Now, on Unix
we make Ssh_gss_buf into an alias for gss_buffer_desc, though we keep
something similar to the existing behaviour on Windows. This requires
renaming a couple of the fields in Ssh_gss_buf, and hence fixing all
the references.
Tested on Linux (MIT Kerberos) and Solaris. Compiled on NetBSD (Heimdal).
Not tested on Windows because neither mingw32 nor winegcc worked out of the
box for me. I think the Windows changes are all syntactic, though, so
if this compiles it should work no worse than before.
[originally from svn r8326]
if we have no better ideas, with UI shamelessly stolen from Quest PuTTY.
Off by default, which effectively reverts the change to using the local
username by default that came in with GSSAPI support in r8138. Anyone wanting
seamless single sign-on will need to set the new option. (The previous
default behaviour was getting in the way in ad-hoc scenarios.)
Note that the PSCP and Unix-Plink behaviour of using the local username by
default have remained unchanged throughout; they are not affected by the new
option. Not sure if that's the Right Thing.
[originally from svn r8324]
[r8138 == de5dd9d65c]
than <gssapi/gssapi_krb5.h> and provide the OID for Kerberos 5 ourselves
(since it's a known constant). I'm not sure this actually works on Solaris
yet, mind.
[originally from svn r8317]
strings more rigorously, and then we look up the local X authority
data in .Xauthority _ourself_ rather than delegating to an external
xauth program. This is (negligibly) more efficient on Unix, assuming
I haven't got it wrong in some subtle way, but its major benefit is
that we can now support X authority lookups on Windows as well
provided the user points us at an appropriate X authority file in
the standard format. A new Windows-specific config option has been
added for this purpose.
[originally from svn r8305]
called from within a backend function which will expect its own
backend pointer to still be valid on return. Instead, move all the
real functionality of notify_remote_exit() out into a GTK idle
function.
[originally from svn r8304]
both directions. We had a bug report yesterday about a Cisco router
sending SSH2_MSG_UNIMPLEMENTED and it wasn't clear for which packet;
logging the sequence numbers should make such problems much easier
to diagnose.
(In fact this logging fix wouldn't have helped in yesterday's case,
because the router also didn't bother to fill in the sequence number
field in the SSH2_MSG_UNIMPLEMENTED packet! This is a precautionary
measure against the next one of these problems.)
[originally from svn r8295]
"curraddr", and turn "family" into a macro-derived property of the
other fields. The idea is that this renders SockAddrs immutable once
created, which should open up the possibility of duplicating and
reusing one without having to redo the actual DNS lookup.
I _hope_ I haven't broken anything. The new code architecture
contains several rather dubious-looking operations (namely the
arbitrary choice of the first returned address in functions like
sk_getaddr and sk_address_is_local - what if, for instance, a DNS
lookup returned a local and a non-local address?), but I think they
were functionally just as dubious beforehand and all this change has
done is to make them more obviously so to a reader.
[originally from svn r8293]
on received data. Experiment and suggestion suggest that the character set
configuration applies equally to keystrokes sent to the server, or at least
that that's close enough to being true that we should document it as a first
approximation.
[originally from svn r8209]
the ordering of the primes in a fully specified RSA private key:
when the key format typically has p > q, it will always output p > q
but be willing to tolerate p < q on input. (Inspired by seeing an
OpenSSH-format key file in the wild which had p < q, which I've
never seen before; I suspect a third-party application incautiously
generating the format.)
[originally from svn r8201]
sites for uint64_make(), we _shouldn't_ attempt to preserve high
bits in the low-order argument; it turns out not to be what the call
sites want.
[originally from svn r8185]
to be trying harder to find a 32-bit type rather than making a
uint64 structure out of two potentially 64-bit unsigned longs. And
really I ought to be using the C99 64-bit integers anyway if they're
available. But this should do for the moment.
[originally from svn r8184]
combination Ctrl + \ as the Ctrl-\ character. All of mine have, but
at least one laptop turns out not to. Do so explicitly.
[originally from svn r8182]
no actual prompts, we weren't displaying the former, which was wrong. We
should now (although I haven't found a server to test it against).
[originally from svn r8172]
semicolon which crept in in r8138 was causing a lot of the "make
install" implementation to be missing from Makefile.gtk.
[originally from svn r8159]
[r8138 == de5dd9d65c]
ago, I apparently caused all data received from local proxies to be
unconditionally tagged as TCP Urgent. Most network backends ignore
this, but it's critical to the Telnet backend, which will ignore all
Urgent-marked data in the assumption that there's a SYNCH on its way
that it should wait for. Nobody has noticed in two years, presumably
meaning that nobody has ever tried to do Telnet over a local proxy
in that time.
[originally from svn r8158]
and gss_name_t are supposed to be congruent types, so a pointer to
one should never be cast to a non-indirect instance of the other.
[originally from svn r8157]
other reasons and I noticed that the list of TELOPTs is given twice
and hence needs to be kept in sync. Replace with my now-standard
second-order-macro approach which allows the list to be maintained
in only one place.
[originally from svn r8156]
(rather than IPv4 or IPv6-only; this is the default), try to open up listening
sockets on both address families, rather than (unhelpfully) just IPv6. (And
don't open one if the other can't be bound, in a nod to CVE-2008-1483.)
Based on a patch from Ben A L Jemmett.
[originally from svn r8150]
[this svn revision also touched putty-wishlist]
Attempts at damage limitation from the name similarity with pterm.
Also try to refresh the ports section of the FAQ a bit.
[originally from svn r8139]
[this svn revision also touched putty-website]
read uninitialised (because the only circumstance under which it
isn't initialised is when "update" is FALSE, in which case it isn't
read either). Placate it.
[originally from svn r8119]
ssh_sftp_loop_iteration(), not just one. Fixes exiting on a negative
response to the host key confirmation prompt on Windows (because
winsftp.c doesn't have the equivalent of uxsftp.c's no_fds_ok); on
Unix it worked already but gave a suboptimal error message, which is
fixed too by this patch.
[originally from svn r8110]
The colour list box beeped at the user whenever it found that
something other than exactly one colour was selected. This seems to
happen implicitly in Gtk when the pane is changed. In Gtk1, this gave
you a beep whenever you left the Colours dialog after having selected
a colour from the list; in Gtk2, you additionally got a beep _every_
time you subsequently re-entered the Colours dialog (for reasons I
haven't investigated). Windows was unaffected.
Also, in Gtk (unlike Windows), it's possible for the user to go back
to the state where no items in the list box are selected at all.
For these reasons, stop beeping at the user, and instead blank the RGB
edit boxes as a hint that edits to them would be futile. (Really we
should be disabling them entirely, but the cross-platform edit
controls aren't up to that yet.)
[originally from svn r8074]
with the switch to GTK2. This turns out to be because, where GTK1
represented the scroll wheel as mouse buttons 4 and 5 and generated
GdkEventButton when it was moved, GTK2 has moved wheel actions out
into a new event type GdkEventScroll which we were not handling. Now
we do, so scroll wheel support should be back in place.
[originally from svn r8063]
