Have mksrcarc.sh log its activity to standard output.

Its previous policy of silence made sense before we did builds using
bob (gratuitous output on success caused cronmail) but now it just
makes it hard to spot problems.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10153 cda61777-01e9-0310-a592-d414129be87e
Add 'set -e' to mksrcarc.sh, so it spots zip returning error.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10154 cda61777-01e9-0310-a592-d414129be87e
Stop using 'zip -k' to construct the Windows source archive.

It was intended to ensure that people still working with DOS filename
restrictions (or things approximating that, e.g. VFAT) wouldn't have
trouble. Those days are surely long gone, and now zip -k is causing
its own trouble with the new VS2010/VS2012 project files, which
include pairs of filenames that become the same under the zip -k
transformation and hence break the source archive build.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10155 cda61777-01e9-0310-a592-d414129be87e
New FAQ, aimed at the people who periodically send us large
questionnaires in unfriendly formats like Excel, apparently in the
mistaken belief that we have some kind of incentive to answer them. I
hope I've managed to identify the key reason why they make this
mistake.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10156 cda61777-01e9-0310-a592-d414129be87e
Add auto-recognition of BUG_SSH2_RSA_PADDING for ProFTPD.

Martin Prikryl reports that it had the exact same bug as old OpenSSH
(insisting that RSA signature integers be padded with leading zero
bytes to the same length as the RSA modulus, where in fact RFC 4253
section 6.6 says it ought to have _no_ padding), but is recently
fixed. The first version string to not have the bug is reported to be
"mod_sftp/0.9.9", so here we recognise everything less than that as
requiring our existing workaround.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10161 cda61777-01e9-0310-a592-d414129be87e