Update Putty files to 0.81 due to security issue (CVE-2024-31497)

src/SharpPlink/PuttySrc/.gitignore

@@ -1,5 +1,18 @@
 *.o
 *.pyc
+*.vcxproj
+*.vcxproj.filters
+.ninja_deps
+.ninja_log
+build.ninja
+/CMakeCache.txt
+CMakeFiles/
+Debug/
+Win32/
+cmake_install.cmake
+/shipped.txt
+*.dir/
+*.lib
 .dirstamp
 .deps
 .DS_Store
@@ -16,12 +29,10 @@
 /*.dsw
 /*.opt
 /*.dsp
+/*.sln
 /*.tds
 /*.td2
 /*.map
-/Makefile.mgw
-/Makefile.vc
-/Makefile.lcc
 /MSVC
 /*.log
 /*.GID
@@ -49,35 +60,20 @@
 /testzlib
 /cgtest
 /scctest
+/test_host_strfoo
+/test_tree234
+/test_wildcard
 /*.DSA
 /*.RSA
 /*.cnt
 /*.hlp
 /.bmake
 /build.log
 /build.out
-/uxconfig.h
 /empty.h
-/config.status
-/Makefile.am
-/Makefile.in
-/Makefile
+Makefile
 /compile
-/config.status
-/configure
-/stamp-h1
-/aclocal.m4
-/ar-lib
-/autom4te.cache
-/depcomp
-/install-sh
-/local
-/missing
-/uxconfig.in
-/uxconfig.in~
-/uxconfig.h
-/licence.h
-/*.a
+*.a
 /charset/sbcsdat.c
 /contrib/cygtermd/cygtermd.exe
 /doc/*.html
@@ -102,9 +98,6 @@
 /icons/*.icns
 /icons/*.xpm
 /icons/*.c
-/unix/Makefile.gtk
-/unix/Makefile.ux
-/unix/Makefile.local
 /unix/empty.h
 /unix/plink
 /unix/pterm
@@ -133,14 +126,6 @@
 /windows/*.td2
 /windows/*.map
 /windows/*.rcpp
-/windows/Makefile.clangcl
-/windows/Makefile.mgw
-/windows/Makefile.vc
-/windows/Makefile.lcc
-/windows/MSVC
-/windows/DEVCPP
-/windows/VS2010
-/windows/VS2012
 /windows/*.log
 /windows/*.GID
 /windows/local

src/SharpPlink/PuttySrc/Buildscr.cv

@@ -6,16 +6,12 @@
 
 module putty
 
-# Preparations.
-in putty do ./mkfiles.pl
-in putty do ./mkauto.sh
-in putty/doc do make
-
 # Scan the Unix build, on a 64-bit system to differentiate as much as
 # possible from the other scan of the cross-platform files.
 delegate covscan64
-  in putty do ./configure
-  in putty do cov-build --dir cov-int make
+  in putty do mkdir linbuild
+  in putty/linbuild do cmake ..
+  in putty/linbuild do cov-build --dir ../cov-int make -j$(nproc) VERBOSE=1
   in putty do tar czvf cov-int.tar.gz cov-int
   return putty/cov-int.tar.gz
 enddelegate
@@ -25,7 +21,9 @@ enddelegate
 # Windows scanner for download).
 delegate covscan32wine
   in putty do tar xzvf cov-int.tar.gz
-  in putty/windows do cov-build --dir ../cov-int make -f Makefile.mgw CC=winegcc RC=wrc
+  in putty do mkdir winbuild
+  in putty/winbuild do cmake .. -DCMAKE_TOOLCHAIN_FILE=../cmake/toolchain-winegcc.cmake
+  in putty/winbuild do cov-build --dir ../cov-int make -j$(nproc) VERBOSE=1
   in putty do tar czvf cov-int.tar.gz cov-int
   return putty/cov-int.tar.gz
 enddelegate

src/SharpPlink/PuttySrc/CHECKLST.txt

@@ -8,7 +8,7 @@ When we begin to work towards a release and want to enable
 pre-releases on the website:
 
  - Make a branch whose tip will be the current state of the
-   pre-release. Regardless of whether the branch is from master or
+   pre-release. Regardless of whether the branch is from main or
    from a prior release branch, the name of the branch must now be in
    the form 'pre-X.YZ', or else the website will fail to link to it
    properly in gitweb and the build script will check out the wrong
@@ -19,23 +19,44 @@ pre-releases on the website:
  - Edit ~/adm/puttysnap.sh on the master machine to enable pre-release
    builds, by changing the 'if false' to 'if true'.
 
+ - Wait for a nightly build to run, so that the first pre-release
+   snapshot actually exists.
+
  - Put the website into pre-release mode, by defining prerel_version()
    in components/Base.mc to return the upcoming version number. Also
    add a news announcement in components/news. (Previous naming
    convention has been to name it in the form 'X.YZ-pre.mi'.)
 
+ - Optionally: write an announcement email for the availability of
+   pre-releases, and send it out to <putty-announce@lists.tartarus.org>.
+
 Things to do during the branch-stabilisation period:
 
  - Go through the source (including the documentation), and the
    website, and review anything tagged with a comment containing the
    word XXX-REVIEW-BEFORE-RELEASE. (Any such comments should state
    clearly what needs to be done.)
 
- - Do some testing of the Windows version with Minefield (you can
-   build a Minefield version using 'bob . XFLAGS=-DMINEFIELD'), and of
-   the Unix version with valgrind and/or Address Sanitiser. In
-   particular, any headline features for the release should get a
-   workout with memory checking enabled!
+ - Test the Unix build with Address Sanitiser. In particular, any
+   headline features for the release should get a workout with memory
+   checking enabled!
+
+ - Test the Windows build with Address Sanitiser too (as of VS 2022).
+    + In the course of that, give a recent Windows pterm a try, to
+      make sure that still works.
+
+ - Test building and running on old platforms:
+    + build on Debian stretch (containing CMake 3.7, the earliest
+      CMake we claim support for)
+    + build with all three major versions of GTK
+    + build the old-Windows binaries and test-run them on Win95 (PuTTY
+      proper even without WinSock2)
+
+ - Check Coverity is happy.
+
+ - Check the side-channel tester is happy.
+
+ - Check all the non-SSH network backends still basically work.
 
 Making a release candidate build
 --------------------------------
@@ -73,9 +94,6 @@ Making a release candidate build
  - Make the release tag, pointing at the version-update commit we just
    generated.
 
- - If the release is on a branch (which I expect it generally will
-   be), merge that branch to master.
-
  - Make a release-candidate build from the release tag, and put the
    build.out and build.log files somewhere safe. Normally I store
    these inside the ~/src/putty/X.YZ directory, alongside the git
@@ -94,7 +112,7 @@ Making a release candidate build
  - Make a preliminary gpg signature, but don't run the full release-
    signing procedure. (We use the presence of a full set of GPG
    signatures to distinguish _abandoned_ release candidates from the
-   one that ended up being the release.) In the 'build.X.YZ-rcN.out'
+   one that ended up being the release.) In the 'build-X.YZ-rcN.out'
    directory, run
      sh sign.sh -r -p putty
    which will generate a clearsigned file called
@@ -108,17 +126,21 @@ Making a release candidate build
     * make sure they basically work
     * check they report the right version number
     * if there's any easily observable behaviour difference between
-      the release branch and master, arrange to observe it
+      the release branch and main, arrange to observe it
     * test that the Windows installer installs successfully
        + on x86 and Arm, and test that putty.exe runs in both cases
     * test that the Unix source tarball unpacks and builds
        + on at least a reasonably current stable Linux distro, and
          also try Debian sid
        + test-build with all of GTK 1, 2 and 3
        + test-build with -DNOT_X_WINDOWS
+    * test that the Windows source builds with Visual Studio (just in
+      case there's an unguarded clangism that would prevent it)
+    * quick check of the outlying network protocols (Telnet, SUPDUP
+      etc)
     * feed the release-candidate source to Coverity and make sure it
       didn't turn up any last-minute problems
-    * make sure we have a clean run of sctest
+    * make sure we have a clean run of testsc
     * do some testing on a system with a completely clean slate (no
       prior saved session data)
 
@@ -140,6 +162,26 @@ Preparing to make the release
       enabled), by editing prerel_version() in components/Base.mc to
       return undef.
 
+ - Prepare some 'what's new in this release' blurb for the Windows
+   Store. This should be very brief - even briefer than the website
+   news item.
+    * Keep it to a couple of sentences in a single paragraph,
+      templated along the lines of
+        X.YZ adds support for this, that and the other, and fixes bugs
+        including this and that.
+      or
+        X.YZ is a bug-fix release, mostly in the area of Foo, with one
+        important fix to Bar.
+    * Might as well check this into putty-aux too.
+
+ - Prepare a toot! I'm on Mastodon, so I should announce the release
+   there. This means writing a cut-down 500-char announcement, maybe
+   more like the website news item than like the email.
+    * Include any relevant hashtags. Refer to the software as #PuTTY;
+      if you mention SSH then write it as #SSH; similarly if we're
+      fixing a #vulnerability. That's how people will find the toot.
+    * Again, commit to putty-aux for team review.
+
  - Update the wishlist, in a local checkout:
     * If there are any last-minute wishlist entries (e.g. security
       vulnerabilities fixed in the new release), write entries for
@@ -165,6 +207,14 @@ Preparing to make the release
      sh sign.sh -r putty     # and enter the release key passphrase
      chmod -R a-w putty
 
+ - If the release is on a branch (which I expect it generally will
+   be), prepare a merge of that branch to main. Even if the branch
+   consists of nothing but cherry-picks _from_ main, this will mean
+   that the 'update version number' change appears on main and the
+   snapshots start announcing themselves as post-X.YZ. But also, if
+   there's anything new on the branch, this is how it gets on to main
+   as well.
+
 The actual release procedure
 ----------------------------
 
@@ -180,12 +230,9 @@ locally, this is the procedure for putting it up on the web.
 
  - Check that downloads via version-numbered URLs all work:
       ../putty/release.pl --version=X.YZ --precheck
-   If this has trouble accessing chiark's ftp server, that is
-   unfortunately normal; add --no-ftp and try again.
 
  - Switch the 'latest' links over to the new release:
     * Update the HTTP redirect at the:www/putty/htaccess .
-    * Update the FTP symlink at chiark:ftp/putty-latest .
 
  - Now verify that downloads via the 'latest' URLs are all redirected
    correctly and work:
@@ -195,10 +242,10 @@ locally, this is the procedure for putting it up on the web.
     * run 'git push' in the website checkout
     * run 'git push' in the wishlist checkout
     * push from the main PuTTY checkout. Typically this one will be
-      pushing both the release tag and an update to the master branch,
+      pushing both the release tag and the merge to the main branch,
       plus removing the pre-release branch, so you'll want some
       commands along these lines:
-        git push origin master        # update the master branch
+        git push origin main          # update the main branch
         git push origin --tags        # should push the new release tag
         git push origin :pre-X.YZ     # delete the pre-release branch
 
@@ -216,6 +263,23 @@ locally, this is the procedure for putting it up on the web.
    subdirectory for the new version and that the links from its
    latest.html point into that subdirectory.
 
+ - Start the process of updating our Windows Store entry:
+    + log into partner.microsoft.com and go to Partner Center
+    + start editing the existing app submission, which should
+      automatically create a new submission
+       * provide a new set of installer URLs, then click "save all"
+         which actually uploads them
+          + be careful to use URLs without "latest" in the pathname!
+            Just copying from the links on the download page is wrong.
+            Change "latest" to the version number, and test-download
+            via those URLs to check you didn't make a typo.
+       * change the "what's new in this release" text in the store
+         listing
+       * upload revised screenshots, if necessary
+       * update the URL in the "Applicable license terms" box
+    + press Publish or Submit (or whatever the button is called this
+      time) to submit that to the actual upload process
+
  - Announce the release!
     + Construct a release announcement email whose message body is the
       announcement written above, and which includes the following
@@ -225,6 +289,7 @@ locally, this is the procedure for putting it up on the web.
     + Mail that release announcement to
       <putty-announce@lists.tartarus.org>.
     + Post it to comp.security.ssh.
+    + Post the prepared toot to Mastodon.
     + Mention it in <TDHTT> on mono.
 
  - Edit the master ~/adm/puttysnap.sh to disable pre-release builds,