Package: putty / 0.67-3
Patch seriesview the series file
|pipe buf.patch | (download)||
3 3 + 0 - 0 !
fix build failure on gnu/hurd putty FTBFS on GNU/Hurd due to a missing definition of PIPE_BUF in <limits.h>. This is solved by using the _POSIX_PIPE_BUF defined value of 512 instead. (In fact the assertion will never happen, SALT_SIZE is defined to 64 and PIPE_BUF is always larger than that, e.g. for Linux 4096, and so is _POSIX_PIPE_BUF.) Bug-Debian: https://bugs.debian.org/805505
|puttygen batch passphrase.patch | (download)||
add command-line passphrase-file options to command-line puttygen. Patch due to Colin Watson. Putting the passphrase in a file avoids exposing it to 'ps' which can print out every process's command line, while at the same time not being as platform-specific as the approach of providing an fd number (since cmdgen.c is in principle a potential cross-platform PuTTYgen, not just a Unix one, which is why it's not in the 'unix' directory). Of course it introduces its own risks if someone can read the file from your disk after you delete it; probably the best approach to avoiding this, if possible, is to point the option at a file on an in-memory tmpfs type file system. Or better still, use bash-style /dev/fd options such as puttygen --new-passphrase <(echo -n "my passphrase") [options] Failing that, try a secure file-wipe utility, as the man page change mentions. (And a use case not to be overlooked, of course, is the one where you actually want to generate an unprotected key - in which case, just pass /dev/null as the filename.)
|vuln agent fwd overflow.patch | (download)||
41 41 + 0 - 0 !
sanity-check message length fields in chan_agent input. Fixes 'vuln-agent-fwd-overflow': a hostile agent-forwarding client sending a length such as 0xFFFFFFFD can cause c->u.a.totallen to end up less than c->u.a.lensofar, leading to an attacker-controlled heap overwrite when those two values are subtracted and used as a bound for the amount of data to memcpy into the buffer. Of course the mitigating factor is that if there is any such thing as a 'hostile agent-forwarding client' in your world then you're likely to _already_ be in fairly serious trouble - they can make free use of all the keys stored in your agent, and would surely prefer to do that than tip their hand by crashing your SSH client. This is just the sort of thing I should have spotted in one of my past general tightening-up passes such as commit 896bb7c74, but apparently didn't :-( Bug-Debian: https://bugs.debian.org/857642