sync with PuTTY-0.62

Buildscr

@@ -7,6 +7,7 @@ module putty
 set Makever -DSVN_REV=$(revision)
 ifneq "$(!numeric $(revision))" "yes" set Makever $(Makever) -DMODIFIED
 ifneq "$(RELEASE)" "" set Makever $(Makever) -DRELEASE=$(RELEASE)
+ifneq "$(PRERELEASE)" "" set Makever $(Makever) -DPRERELEASE=$(PRERELEASE)
 ifneq "$(date)" "" set Makever $(Makever) -DSNAPSHOT=$(date)
 set Makeargs VER="$(Makever)"
 ifneq "$(XFLAGS)" "" set Makeargs $(Makeargs) XFLAGS="$(XFLAGS)"
@@ -15,11 +16,13 @@ ifneq "$(MAKEARGS)" "" set Makeargs $(Makeargs) $(MAKEARGS)
 # Set up the version string for the docs build.
 set Docmakeargs VERSION="PuTTY revision $(revision)"
 ifneq "$(RELEASE)" "" set Docmakeargs VERSION="PuTTY release $(RELEASE)"
+ifneq "$(PRERELEASE)" "" set Docmakeargs VERSION="PuTTY pre-release $(PRERELEASE):r$(revision)"
 ifneq "$(date)" "" set Docmakeargs VERSION="PuTTY development snapshot $(date)"
 
 # Set up the version string for the Unix source archive.
 set Unxver r$(revision)
 ifneq "$(RELEASE)" "" set Unxver $(RELEASE)
+ifneq "$(PRERELEASE)" "" set Unxver $(PRERELEASE)pre $(revision)
 ifneq "$(date)" "" set Unxver $(date)
 
 # Set up the various version strings for the installer.
@@ -33,16 +36,15 @@ ifneq "$(RELEASE)" "" set Iname PuTTY version $(RELEASE)
 ifneq "$(RELEASE)" "" set Ivertext Release $(RELEASE)
 ifneq "$(RELEASE)" "" set Irev 0
 ifneq "$(RELEASE)" "" set Ifilename putty-$(RELEASE)-installer.exe
+ifneq "$(PRERELEASE)" "" set Iversion $(PRERELEASE):r$(revision)
+ifneq "$(PRERELEASE)" "" set Iname PuTTY pre-release $(PRERELEASE):r$(revision)
+ifneq "$(PRERELEASE)" "" set Ivertext Pre-release $(PRERELEASE):r$(revision)
+ifneq "$(PRERELEASE)" "" set Ifilename putty-$(PRERELEASE)-pre$(revision)-installer.exe
 ifneq "$(date)" "" set Iversion $(date):r$(revision)
 ifneq "$(date)" "" set Iname PuTTY development snapshot $(date):r$(revision)
 ifneq "$(date)" "" set Ivertext Development snapshot $(date):r$(revision)
 ifneq "$(date)" "" set Ifilename putty-$(date)-installer.exe
 
-# Set up the version string for the installer.
-set Iversion r$(revision)
-ifneq "$(RELEASE)" "" set Iversion $(RELEASE)
-ifneq "$(date)" "" set Iversion $(date):r$(revision)
-
 in putty do ./mksrcarc.sh
 in putty do ./mkunxarc.sh $(Unxver)
 in putty do perl mkfiles.pl
@@ -98,9 +100,14 @@ deliver putty/windows/*.map maps-x86/$@
 # whatever key they want.
 deliver putty/sign.sh $@
 
-# Building the md5sums file is most easily done in the destination
-# directory.
-in-dest putty do md5sum `\find * -type f -print` > md5sums
+# Create files of cryptographic checksums, which will be signed along
+# with the files they verify. We've provided MD5 checksums for a
+# while, but now MD5 is looking iffy, we're expanding our selection.
+#
+# Creating these files is most easily done in the destination
+# directory, where all the files we're delivering are already in their
+# final relative layout.
+in-dest putty do a=`\find * -type f -print`; md5sum $$a > md5sums && sha1sum $$a > sha1sums && sha256sum $$a > sha256sums && sha512sum $$a > sha512sums
 
 # And construct .htaccess files. One in the top-level directory,
 # setting the MIME types for Windows help files and providing an

CHECKLST.txt

@@ -26,12 +26,6 @@ The resource files:
       once in the Licence box. Don't forget to change both!
  - putty/windows/version.rc2
     + the copyright date appears once only.
- - putty/mac/mac_res.r
-    + the copyright date appears twice, once in the About box and
-      once in the Licence box. Don't forget to change both!
- - putty/mac/macpgen.r
-    + the copyright date appears twice, once in the About box and
-      once in the Licence box. Don't forget to change both!
  - putty/unix/gtkdlg.c
     + the copyright date appears twice, once in the About box and
       once in the Licence box. Don't forget to change both!
@@ -82,11 +76,6 @@ VERSIONINFO resources -- the strings are supplied by the usual means):
 
  - putty/windows/version.rc2 (BASE_VERSION; NB, _comma_-separated)
 
-The Mac resource file (used to generate the binary bit of the 'vers'
-resources):
-
- - putty/mac/version.r
-
 It might also be worth going through the documentation looking for
 version numbers - we have a couple of transcripts showing the help
 text from the command-line tools, and it would be nice to ensure the
@@ -111,7 +100,7 @@ of the tag.
 
  - Write a release announcement (basically a summary of the changes
    since the last release). Squirrel it away in
-   ixion:src/putty/local/announce-<ver> in case it's needed again
+   atreus:src/putty/local/announce-<ver> in case it's needed again
    within days of the release going out.
 
  - Build the release: `bob putty-0.XX RELEASE=0.XX'. This should
@@ -123,22 +112,25 @@ of the tag.
    report their version numbers accurately, and so on. Test the
    installer and the Unix source tarball.
 
- - Save the link maps. Currently I keep these on ixion, in
+ - Save the link maps. Currently I keep these on atreus, in
    src/putty/local/maps-<version>.
 
  - Sign the release: in the `build.out' directory, type `./sign.sh
    putty Releases', and enter the passphrases a lot of times.
 
  - Now the whole release directory should be present and correct.
-   Upload it to ixion:www/putty/<ver>.
+   Upload it to atreus:www/putty/<ver>.
 
  - Do final checks on the release directory:
     + verify all the signatures:
-      for i in `find . -name '*.*SA'`; do case $i in *md5sums*) gpg --verify $i;; *) gpg --verify $i ${i%%.?SA};; esac; done
-    + check the md5sums:
+      for i in `find . -name '*.*SA'`; do case $i in *sums*) gpg --verify $i;; *) gpg --verify $i ${i%%.?SA};; esac; done
+    + check the checksum files:
       md5sum -c md5sums
+      sha1sum -c sha1sums
+      sha256sum -c sha256sums
+      sha512sum -c sha512sums
 
- - Having double-checked the release, copy it from ixion to
+ - Having double-checked the release, copy it from atreus to
    chiark:ftp/putty-<ver> and to the:www/putty/<ver>.
 
  - Check the permissions! Actually try downloading from the, to make
@@ -148,16 +140,21 @@ of the tag.
     + Update the one at the:www/putty/htaccess which points the
       virtual subdir `latest' at the actual latest release dir. TEST
       THIS ONE - it's quite important.
-    + ixion:www/putty/.htaccess has an individual redirect for each
+    + atreus:www/putty/.htaccess has an individual redirect for each
       version number. Add a new one.
 
  - Update the FTP symlink (chiark:ftp/putty-latest -> putty-<ver>).
 
  - Update web site.
-   + Adjust front page (`the latest version is <ver>').
-   + Adjust Download page similarly.
-   + Adjust filenames of installer and Unix tarball on links in
-     Download page.
+   + Adjust front page to say 'The latest version is <ver>'.
+   + Adjust front page to add a news item.
+   + Adjust Download page to say 'The latest release version (<ver>)'.
+   + Adjust Download page to update filenames of installer and Unix
+     tarball (both in the hrefs themselves and the link text).
+   + Check over the Download page and remove any mention of
+     pre-releases, if there were any before this release. Comment out
+     the big pre-release section at the top, and also adjust the
+     sections about source archives at the bottom.
    + Adjust header text on Changelog page. (That includes changing
      `are new' in previous version to `were new'!)
 
@@ -171,18 +168,19 @@ of the tag.
  - Check that the web server attaches the right content type to .HLP
    and .CNT files.
 
- - Run webupdate, so that all the changes on ixion propagate to
+ - Run webupdate, so that all the changes on atreus propagate to
    chiark. Important to do this _before_ announcing that the release
    is available.
 
- - After running webupdate, run update-rsync on chiark and verify
-   that the rsync mirror package correctly identifies the new
-   version.
+ - After running webupdate, run update-rsync on chiark and verify that
+   the rsync mirror package (~/ftp/putty-website-mirror) contains a
+   subdirectory for the new version and mentions it in its .htaccess.
 
  - Announce the release!
-    + Mail the announcement to putty-announce.
-       * Set a Reply-To on the mail so that people don't keep
-	 replying to my personal address.
+    + Mail the announcement to <putty-announce@lists.tartarus.org>.
+       * Put a 'Reply-To: putty@projects.tartarus.org' header on the
+	 mail so that people don't keep replying to my personal
+	 address.
     + Post it to comp.security.ssh.
     + Mention it in <TDHTT> on mono.
 

LATEST.VER

@@ -1 +1 @@
-0.60
+0.62

LICENCE

@@ -6,13 +6,15 @@ PuTTY-SC is Copyright 2005-2008 Pascal Buchbinder.
 PuTTY-SC is available under the GPLv2 license.
 PuTTY-SC is a derivative work of PuTTY.
 
-PuTTY is copyright 1997-2009 Simon Tatham.
+PuTTY is copyright 1997-2011 Simon Tatham.
 
 Portions copyright Robert de Bath, Joris van Rantwijk, Delian
 Delchev, Andreas Schultz, Jeroen Massar, Wez Furlong, Nicolas Barry,
 Justin Bradford, Ben Harris, Malcolm Smith, Ahmad Khalifa, Markus
 Kuhn, Colin Watson, and CORE SDI S.A.
 
+CAPI support donated by Andrew Prout.
+
 Permission is hereby granted, free of charge, to any person
 obtaining a copy of this software and associated documentation files
 (the "Software"), to deal in the Software without restriction,

README

@@ -18,9 +18,9 @@ For building on Windows:
    -f Makefile.vc' to build all the PuTTY binaries.
 
    Last time we checked, PuTTY built with vanilla VC7, or VC6 with
-   an up-to-date Platform SDK. (It is possible to build with
-   vanilla VC6, but you'll have to remove some functionality with
-   directives such as NO_IPV6.)
+   an up-to-date Platform SDK. (It might still be possible to build
+   with vanilla VC6, but you'll certainly have to remove some
+   functionality with directives such as NO_IPV6.)
 
    (We've also had reports of success building with the
    OpenWatcom compiler -- www.openwatcom.org -- using Makefile.vc
@@ -56,9 +56,10 @@ For building on Windows:
  - Inside the windows/DEVCPP subdirectory are Dev-C++ project
    files for doing GUI-based builds of the various PuTTY utilities.
 
-The PuTTY team actively use Makefile.vc and Makefile.cyg, so we'll
-probably notice problems with those toolchains fairly quickly. Please
-report any problems with the other toolchains mentioned above.
+The PuTTY team actively use Makefile.vc (with VC7) and Makefile.cyg
+(with mingw32), so we'll probably notice problems with those
+toolchains fairly quickly. Please report any problems with the other
+toolchains mentioned above.
 
 For building on Unix:
 
@@ -71,9 +72,12 @@ For building on Unix:
    portability problems such as BSD-style ptys or different header file
    requirements are expected.
 
- - unix/Makefile.gtk is for non-autoconfigured builds. This makefile
-   expects you to change into the `unix' subdirectory, then run `make
-   -f Makefile.gtk'.
+ - unix/Makefile.gtk and unix/Makefile.ux are for non-autoconfigured
+   builds. These makefiles expect you to change into the `unix'
+   subdirectory, then run `make -f Makefile.gtk' or `make -f
+   Makefile.ux' respectively. Makefile.gtk builds all the programs but
+   relies on Gtk, whereas Makefile.ux builds only the command-line
+   utilities and has no Gtk dependence.
 
  - For the graphical utilities, Gtk+-1.2 and Gtk+-2.0 should both be
    supported.

README.md

@@ -3,8 +3,14 @@ putty-cac
 
 secure shell client with support for US Gov't Smartcards and other X.509 certificates.
 
-This is a fork of PuTTY.  It breaks much of the delictious goodness of the original PuTTY, in that it only builds for Windows, and is only known to build correctly with Microsoft Visual C, at this time.  
+This is a fork of PuTTY.  It breaks much of the delictious goodness of
+the original PuTTY, in that it only builds for Windows, and is only
+known to build correctly with Microsoft Visual C, at this time.
 
 But it supports the DoD Common Access Card (CAC) and a number of other smartcards.  
 
-This version (as of 2012-08-29) has support for Microsoft's Cryptographic API (CAPI) in addition to the PKCS#11 API, thanks to a patch contributed by Andrew PRout of the MIT Lincoln Laboratory.  What this means is that it is likely to support a broader range of middleware and certificates, including soft-certs.
+This version (as of 2012-08-29) has support for Microsoft's
+Cryptographic API (CAPI) in addition to the PKCS#11 API, thanks to a
+patch contributed by Andrew Prout of the MIT Lincoln Laboratory.  What
+this means is that it is likely to support a broader range of
+middleware and certificates, including soft-certs.