Merge the 0.68 release branchlet to master.

Conflicts in the FAQ are fixed by incorporating Jacob's rewritten post-0.68 version. (But owing to considerable git confusion I haven't managed to get his name on to this commit anywhere.)
2017-02-20 20:52:41 +00:00 · 2017-02-20 20:52:41 +00:00 · 359b5c8eb4
--- a/2
+++ b/2
@ -35,7 +35,7 @@ module putty
 ifeq "$(RELEASE)" "" set Ndate $(!builddate)
 ifneq "$(Ndate)" "" in . do echo $(Ndate) | perl -pe 's/(....)(..)(..)/$$1-$$2-$$3/' > date
 ifneq "$(Ndate)" "" read Date date
-set Epoch 15860 # update this at every release
+set Epoch 16214 # update this at every release
 ifneq "$(Ndate)" "" in . do echo $(Ndate) | perl -ne 'use Time::Local; /(....)(..)(..)/ and print timegm(0,0,0,$$3,$$2-1,$$1) / 86400 - $(Epoch)' > days
 ifneq "$(Ndate)" "" read Days days

--- a/CHECKLST.txt
+++ b/CHECKLST.txt
@ -79,8 +79,11 @@ for it:

 - Update the website, in a local checkout:
    * Write a release file in components/releases which identifies the
-      new version, its release date, a section for the Changes page,
-      and a news announcement for the front page.
+      new version, a section for the Changes page, and a news
+      announcement for the front page.
+       + The one thing this can't yet contain is the release date;
+         that has to be put in at the last minute, when the release
+         goes live. Fill in 'FIXME', for the moment.
    * Disable the pre-release sections of the website (if previously
      enabled), by editing prerel_version() in components/Base.mc to
      return undef.
@ -95,15 +98,16 @@ for it:
      headers for those.
    * Add an entry to the @releases array in control/bugs2html.

- - Build the release, by checking out the release tag:
-     git checkout 0.XX
-     bob . RELEASE=0.XX
+ - Make a release-candidate build from the release tag, and put the
+   build.out and build.log dfiles somewhere safe. Normally I store
+   these in an adjacent directory, so I'll run a command like
+     bob -o ../X.YZ/build-X.YZ-rcN.out -l ../X.YZ/build-X.YZ-rcN.log -c X.YZ . RELEASE=X.YZ
   This should generate a basically valid release directory as
-   `build.out/putty', and provide link maps and sign.sh alongside that
-   in build.out.
+   `build-X.YZ-rcN.out/putty', and provide link maps and sign.sh
+   alongside that.

- - Double-check in build.log that the release was built from the right
-   git commit.
+ - Double-check in build-X.YZ-rcN.log that the release was built from
+   the right git commit.

 - Do a bit of checking of the release binaries:
    * make sure they basically work
@ -113,16 +117,22 @@ for it:
    * test the Windows installer
    * test the Unix source tarball.

- - Sign the release: in the `build.out' directory, type
+ - Sign the release: in the `build-X.YZ-rcN.out' directory, type
     sh sign.sh -r putty
   and enter the passphrases a lot of times.

+ - For my own safety, make the release candidate build read-only.
+     chmod -R a-w build-X.YZ-rcN.out build-X.YZ-rcN.log
+
 The actual release procedure
 ----------------------------

 Once all the above preparation is done and the release has been built
 locally, this is the procedure for putting it up on the web.

+ - Make a final adjustment to your local website changes, filling in
+   the release date in components/releases/X.YZ.mi.
+
 - Upload the release itself and its link maps to everywhere it needs
   to be, by running this in the build.out directory:
      ../release.pl --version=X.YZ --upload
@ -147,7 +157,7 @@ locally, this is the procedure for putting it up on the web.
      commands along these lines:
        git push origin master        # update the master branch
        git push origin --tags        # should push the new release tag
-        git push origin :pre-0.XX     # delete the pre-release branch
+        git push origin :pre-X.YZ     # delete the pre-release branch

 - Run ~/adm/puttyweb.sh on atreus to update the website after all
   those git pushes.
--- a/LATEST.VER
+++ b/LATEST.VER
@ -1 +1 @@
-0.67
+0.68
--- a/doc/errors.but
+++ b/doc/errors.but
@ -69,11 +69,11 @@ change the \q{SSH protocol version} setting (see \k{config-ssh-prot}),
 or use the \c{-1} command-line option; in any case, you should not
 treat the resulting connection as secure.

-You might start seeing this message with new versions of PuTTY
-\#{XXX-REVIEW-BEFORE-RELEASE: (from 0.XX onwards)}
-where you didn't before, because it used to be possible to configure
-PuTTY to automatically fall back from SSH-2 to SSH-1. This is no
-longer supported, to prevent the possibility of a downgrade attack.
+You might start seeing this message with new versions of PuTTY (from
+0.68 onwards) where you didn't before, because it used to be possible
+to configure PuTTY to automatically fall back from SSH-2 to SSH-1.
+This is no longer supported, to prevent the possibility of a downgrade
+attack.

 \H{errors-cipher-warning} \q{The first cipher supported by the server is
 ... below the configured warning threshold}
--- a/doc/faq.but
+++ b/doc/faq.but
@ -66,9 +66,8 @@ Yes. SSH-1 support has always been available in PuTTY.
 However, the SSH-1 protocol has many weaknesses and is no longer
 considered secure; you should use SSH-2 instead if at all possible.

-\#{XXX-REVIEW-BEFORE-RELEASE:
 As of 0.68, PuTTY will no longer fall back to SSH-1 if the server
-doesn't appear to support SSH-2; you must explicitly ask for SSH-1. }
+doesn't appear to support SSH-2; you must explicitly ask for SSH-1.

 \S{faq-localecho}{Question} Does PuTTY support \i{local echo}?

@ -216,16 +215,12 @@ seems to be working so far.
 Currently, release versions of PuTTY tools only run on Windows
 systems and Unix.

-\#{XXX-REVIEW-BEFORE-RELEASE: replace following two lines with:
-As of 0.68, the supplied PuTTY executables run on versions of
-Windows from XP onwards,}
-PuTTY runs on versions of Windows from Windows 95 onwards (but not
-the 16-bit Windows 3.1; see \k{faq-win31}),
-up to and including Windows 10; and we know of no reason why PuTTY
-should not continue to work on future versions of Windows.
-\#{XXX-REVIEW-BEFORE-RELEASE: We provide 32-bit and 64-bit Windows
-executables; see \k{faq-32bit-64bit} for discussion of the
-compatibility issues around that.}
+As of 0.68, the supplied PuTTY executables run on versions of Windows
+from XP onwards, up to and including Windows 10; and we know of no
+reason why PuTTY should not continue to work on future versions of
+Windows. We provide 32-bit and 64-bit Windows executables; see
+\k{faq-32bit-64bit} for discussion of the compatibility issues around
+that.

 (We used to also provide executables for Windows for the Alpha
 processor, but stopped after 0.58 due to lack of interest.)
@ -252,10 +247,9 @@ If you look at the source release, you should find a \c{unix}
 subdirectory. There are a couple of ways of building it,
 including the usual \c{configure}/\c{make}; see the file \c{README}
 in the source distribution. This should build you Unix
-ports of Plink, PuTTY itself, PuTTYgen, PSCP, PSFTP, and also
+ports of Plink, PuTTY itself, PuTTYgen, PSCP, PSFTP, Pageant, and also
 \i\c{pterm} - an \cw{xterm}-type program which supports the same
-terminal emulation as PuTTY. \#{XXX-REVIEW-BEFORE-RELEASE:}
-We do not yet have a Unix port of Pageant.
+terminal emulation as PuTTY.

 If you don't have \i{Gtk}, you should still be able to build the
 command-line tools.
@ -592,13 +586,12 @@ all versions of Windows that PuTTY supports. PuTTY doesn't require to
 run as a 64-bit application to work well, and having a 32-bit PuTTY on
 a 64-bit system isn't likely to cause you any trouble.

-The 64-bit version
-\#{XXX-REVIEW-BEFORE-RELEASE (first released in 0.XX)}
-will only run if you have a 64-bit processor \e{and} a \I{64-bit
-Windows}64-bit edition of Windows (both of these things are likely to
-be true of any recent Windows PC). It will run somewhat faster (in
-particular, the cryptography will be faster, especially during link
-setup), but it will consume slightly more memory.
+The 64-bit version (first released in 0.68) will only run if you have
+a 64-bit processor \e{and} a \I{64-bit Windows}64-bit edition of
+Windows (both of these things are likely to be true of any recent
+Windows PC). It will run somewhat faster (in particular, the
+cryptography will be faster, especially during link setup), but it
+will consume slightly more memory.

 If you need to use an external \i{DLL} for GSSAPI authentication, that
 DLL may only be available in a 32-bit or 64-bit form, and that will
@ -1070,8 +1063,7 @@ is triggered by PuTTY 0.58. This was fixed in 0.59. The
 \W{http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/xp-wont-run}{\q{xp-wont-run}}
 entry in PuTTY's wishlist has more details.

-\S{faq-system32}{Question} When I put
-\#{XXX-REVIEW-BEFORE-RELEASE 32-bit} PuTTY in
+\S{faq-system32}{Question} When I put 32-bit PuTTY in
 \cw{C:\\WINDOWS\\\i{SYSTEM32}} on my \i{64-bit Windows} system,
 \i{\q{Duplicate Session}} doesn't work.

--- a/doc/plink.but
+++ b/doc/plink.but
@ -41,7 +41,7 @@ use Plink:

 \c Z:\sysosd>plink
 \c Plink: command-line connection utility
-\c Release 0.67
+\c Release 0.68
 \c Usage: plink [options] [user@]host [command]
 \c        ("host" can also be a PuTTY saved session name)
 \c Options:
@ -54,6 +54,8 @@ use Plink:
 \c   -P port   connect to specified port
 \c   -l user   connect with specified username
 \c   -batch    disable all interactive prompts
+\c   -proxycmd command
+\c             use 'command' as local proxy
 \c   -sercfg configuration-string (e.g. 19200,8,n,1,X)
 \c             Specify the serial configuration (serial only)
 \c The following options only apply to SSH connections:
@ -83,6 +85,8 @@ use Plink:
 \c   -sshlog file
 \c   -sshrawlog file
 \c             log protocol details to a file
+\c   -shareexists
+\c             test whether a connection-sharing upstream exists

 Once this works, you are ready to use Plink.

--- a/doc/pscp.but
+++ b/doc/pscp.but
@ -39,7 +39,7 @@ use PSCP:

 \c Z:\owendadmin>pscp
 \c PuTTY Secure Copy client
-\c Release 0.67
+\c Release 0.68
 \c Usage: pscp [options] [user@]host:source target
 \c        pscp [options] source [source...] [user@]host:target
 \c        pscp [options] -ls [user@]host:filespec
@ -63,6 +63,8 @@ use PSCP:
 \c   -hostkey aa:bb:cc:...
 \c             manually specify a host key (may be repeated)
 \c   -batch    disable all interactive prompts
+\c   -proxycmd command
+\c             use 'command' as local proxy
 \c   -unsafe   allow server-side wildcards (DANGEROUS)
 \c   -sftp     force use of SFTP protocol
 \c   -scp      force use of SCP protocol
--- a/mkfiles.pl
+++ b/mkfiles.pl
@ -1660,11 +1660,20 @@ if (defined $makefiles{'am'}) {
    print "endif\n\n";

    @noinstcliprogs = ("noinst_PROGRAMS", "=");
-    foreach $p (&prognames("XT:UT")) {
+    foreach $p (&prognames("UT")) {
      ($prog, $type) = split ",", $p;
      push @noinstcliprogs, $prog;
    }
+    @noinstallprogs = @noinstcliprogs;
+    foreach $p (&prognames("XT")) {
+      ($prog, $type) = split ",", $p;
+      push @noinstallprogs, $prog;
+    }
+    print "if HAVE_GTK\n";
+    print &splitline(join " ", @noinstallprogs), "\n";
+    print "else\n";
    print &splitline(join " ", @noinstcliprogs), "\n";
+    print "endif\n\n";

    %objtosrc = ();
    foreach $d (&deps("X", undef, "", "/", "am")) {
--- a/windows/putty.iss
+++ b/windows/putty.iss
@ -14,10 +14,10 @@

 [Setup]
 AppName=PuTTY
-AppVerName=PuTTY version 0.67
-VersionInfoTextVersion=Release 0.67
-AppVersion=0.67
-VersionInfoVersion=0.67.0.0
+AppVerName=PuTTY version 0.68
+VersionInfoTextVersion=Release 0.68
+AppVersion=0.68
+VersionInfoVersion=0.68.0.0
 AppPublisher=Simon Tatham
 AppPublisherURL=http://www.chiark.greenend.org.uk/~sgtatham/putty/
 AppReadmeFile={app}\README.txt
 @ -1 +1 @@
 .67
 .68