Package: putty / 0.63-10


Package Version Patches format
putty 0.63-10 3.0 (quilt)

Patch series

view the series file
Patch File delta Description
am prog ar.patch | (download)

unix/ | 2 2 + 0 - 0 !
1 file changed, 2 insertions(+)

 fix build failures on ubuntu 13.10.

Automake now insists that we run AM_PROG_AR if we're going to build a
library, and AM_PROG_CC_C_O if we're going to build anything with
extra compile options. Those extra macros seem harmless in previous
versions of automake.

restore autoconf compatibility.patch | (download)

unix/ | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 restore compatibility with older autoconfs.

The one in Ubuntu 10.04 doesn't know what AM_PROG_AR means, so was broken in r10053 when fixing compatibility with later
versions; you can't win...

move unix configure script.patch | (download)

Recipe | 6 3 + 3 - 0 !
configure | 3 0 + 3 - 0 ! | 198 198 + 0 - 0 ! | 2 1 + 1 - 0 ! | 12 6 + 6 - 0 ! | 2 1 + 1 - 0 !
unix/configure | 6426 2 + 6424 - 0 !
unix/ | 198 0 + 198 - 0 !
8 files changed, 211 insertions(+), 6636 deletions(-)

 move the unix configure script up to the top level.

Previously, 'configure' and its assorted machinery lived in the 'unix'
subdir, because that seemed like a clean place to keep it given that
all the other per-platform Makefiles live in their platform
directories. However, this never sat all that happily with autotools,
and even less so now that it likes to have object file pathnames
parallel source file pathnames: if you have refer to
source files outside its subdir as "../terminal.c" and enable
subdir-objects then any out-of-tree build calls the corresponding
object file "../terminal.o" and so your build products mostly end up
at the directory above your build dir! And as of autotools 1.14 my
previous compensatory bodge of prefixing every source file path in with "$(srcdir)" has stopped working too.

So I'm giving in to necessity, and changing policy by moving the
configure machinery up to the top level of the source tree where
autotools will be less confused by it. This should not be taken as any
indication of the primacy of the Unix port, only of the recalcitrance
of autotools.

Whereas before we had a trivial script called 'configure' at the top
level that invoked unix/configure to effectively do an 'out-of-tree
build' (for make purposes) at the top level of the source tree, we now
have a similar script in unix/configure. So this _should_ make very
add subdir objects option.patch | (download) | 4 4 + 0 - 0 !
1 file changed, 4 insertions(+)

 add the 'subdir-objects' option in the automake makefile.

This rearranges the object files so that they each live alongside
their original source file, instead of all being in the same
directory. To my way of thinking this is a more or less neutral change
(perhaps marginally less tidy), but autotools is apparently beginning
to think it's the One True Way and 1.14 will give a warning if you
don't have it enabled.

sshzlib assertions.patch | (download)

sshzlib.c | 8 8 + 0 - 0 !
1 file changed, 8 insertions(+)

 add some assertions in sshzlib.c.

gcc 4.8 compiling with -O3 gives a new warning about the access to
st->pending at the top of lz77_compress, because for some reason it
thinks there's an out-of-bounds array access there (or perhaps just a
potential one, I'm not really sure which side -Warray-bounds is erring
on). Add an assertion reassuring it that st->npending can't get bigger
than the size of st->pending at the site it's complaining about, and a
second one at the site where st->npending is increased (just in case
my analysis of why it can't happen was wrong!). Also add a comment
explaining the assertions.

puttygen assertion failure.patch | (download)

cmdgen.c | 2 2 + 0 - 0 !
1 file changed, 2 insertions(+)

 fix assertion failure in unix puttygen exports.

The assertions I added to sshrand.c in r9930 are now justified,
because they were failing when cmdgen was used to convert a key into
either foreign private key file format - both the export functions
require random_byte() for one reason or another, and random_ref()
hadn't been called first.

gtk timer warning.patch | (download)

unix/gtkwin.c | 8 8 + 0 - 0 !
1 file changed, 8 insertions(+)

 fix an annoying warning from gtk on ubuntu 14.04.

Timer objects evaporate when our timer_trigger callback is called, and
therefore we should not remember their ids beyond that time and
attempt to cancel them later. Previous versions of GTK silently
ignored us doing that, but upgrading to Ubuntu Trusty has given me a
version of GTK that complains about it, so let's stop doing it.

gtk timer leak 1.patch | (download)

unix/gtkwin.c | 16 9 + 7 - 0 !
1 file changed, 9 insertions(+), 7 deletions(-)

 work around a timer leak with gtk 2.4.22 on opensuse 13.1.

Mihkel Ader reports that on that system, timers apparently aren't
getting auto-destroyed when timer_trigger returns FALSE, so the change
in r10181 has caused GTK PuTTY to gradually allocate more and more
timers and consume more and more CPU as they all keep firing.

As far as I can see, this must surely be a bug in GTK 2 (the docs say
that timers _are_ auto-destroyed when their callback returns false),
and it doesn't seem to happen for me with GTK 2.4.23 on Ubuntu 14.04.
However, I'll try to work around it by _explicitly_ destroying each
old timer before we zero out the variable containing its id.

gtk timer leak 2.patch | (download)

unix/gtkwin.c | 11 8 + 3 - 0 !
1 file changed, 8 insertions(+), 3 deletions(-)

 another fix to timer handling.

Robert de Bath points out that failure to remove the timer whose
callback returned FALSE may not have been the cause of runaway timer
explosion; another possibility is that a function called from
timer_trigger()'s call to run_timers() has already set a timer up by
the time run_timers() returns, and then we set another one up on top
of it. Fix that too.

dynamic tunnel session.patch | (download)

config.c | 20 17 + 3 - 0 !
settings.c | 13 9 + 4 - 0 !
2 files changed, 26 insertions(+), 7 deletions(-)

 fix handling of ipv6 dynamic forwardings.

During the Conf revamp, I changed the internal representation of
dynamic forwardings so that they were stored as the conceptually
sensible L12345=D rather than the old D12345, and added compensation
code to translate to the latter form for backwards-compatible data
storage and for OpenSSH-harmonised GUI display. Unfortunately I forgot
that keys in the forwarding data can also prefix the L/R with a
character indicating IPv4/IPv6, and my translations didn't take
account of that possibility. Fix them.

font bolding style default.patch | (download)

settings.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 revert default for font bolding style

Revert the default for font bolding style back to using colours rather
than fonts. I broke this in r9559 when I added the option for 'both',
because the internal representation got offset by one so as to change
from a boolean to two bitfields and I must have confused myself about
what the default should be.

[originally from svn r10008]
[r9559 == bc6e0952ef1c27c577318ee3c0883c7823c7005b]

kh2reg modern python.patch | (download)

contrib/ | 20 14 + 6 - 0 !
1 file changed, 14 insertions(+), 6 deletions(-)

 make compatible with modern python.

Bare string exceptions aren't supported any more.
Patch by Will Aoki, plus a backward compatibility tweak from Colin Watson.
Seen working with Python 2.4.3 and 2.7.6.

enforce dh range.patch | (download)

ssh.c | 7 7 + 0 - 0 !
ssh.h | 1 1 + 0 - 0 !
sshdh.c | 23 23 + 0 - 0 !
3 files changed, 31 insertions(+)

 enforce acceptable range for diffie-hellman server value.

Florent Daigniere of Matta points out that RFC 4253 actually
_requires_ us to refuse to accept out-of-range values, though it isn't
completely clear to me why this should be a MUST on the receiving end.

Matta considers this to be a security vulnerability, on the grounds
that if a server should accidentally send an obviously useless value
such as 1 then we will fail to reject it and agree a key that an
eavesdropper could also figure out. Their id for this vulnerability is

ssh 1 key load length.patch | (download)

sshpubk.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 fix an erroneous length field in ssh-1 key load.

We incremented buf by a few bytes, so we must decrement the
corresponding length by the same amount, or else makekey() could

Thanks to Patrick Coleman for the patch.

private key not wiped 2.patch | (download)

sshpubk.c | 18 14 + 4 - 0 !
1 file changed, 14 insertions(+), 4 deletions(-)

 add some missing smemclrs and sfrees.

The absence of these could have prevented sensitive private key
information from being properly cleared out of memory that PuTTY tools
had finished with.

Thanks to Patrick Coleman for spotting this and sending a patch.