larryli · larryli · Dec 19, 2024 · Sep 16, 2022 · Sep 18, 2022 · Sep 19, 2022
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
@@ -18,7 +18,6 @@ jobs:
         - { platform: "x64", archive: "-x64" }
         - { platform: "Win32", archive: "" }
         - { platform: "ARM64", archive: "-arm64" }
-        - { platform: "ARM", archive: "-arm" }
 
     steps:
     - name: Checkout

diff --git a/Buildscr b/Buildscr
@@ -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 18819 # update this at every release
+set Epoch 19052 # 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
 
@@ -140,6 +140,9 @@ delegate -
 in putty do cmake . -DCMAKE_C_COMPILER=clang -DCMAKE_C_FLAGS="-fsanitize=address -fsanitize=leak" -DSTRICT=ON
 in putty do make -j$(nproc) VERBOSE=1
 in putty do python3 test/cryptsuite.py
+in putty do ./test_lineedit
+in putty do ./test_terminal
+in putty do ./test_conf
 enddelegate
 
 delegate -

diff --git a/CHECKLST.txt b/CHECKLST.txt
@@ -112,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
@@ -164,13 +164,24 @@ Preparing to make the release
 
  - 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'.
+   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
@@ -196,6 +207,21 @@ 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.
+
+ - Log in to the MS Partner Center and make sure everything is in
+   order. If the UI has completely changed, make sure you can find
+   your way around the new one; if it wants you to read an enormous
+   document of revised T&Cs, get that out of the way in advance, so it
+   doesn't suddenly become a delay in the middle of the actual
+   release.
+
 The actual release procedure
 ----------------------------
 
@@ -219,18 +245,12 @@ locally, this is the procedure for putting it up on the web.
    correctly and work:
       ../putty/release.pl --version=X.YZ --postcheck
 
- - If the release is on a branch (which I expect it generally will
-   be), merge that branch to main, so that the 'update version number'
-   change appears on main and the snapshots start announcing
-   themselves as post-X.YZ.
-
  - Push all the git repositories:
     * 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 the merge we just made to the
-      main branch, plus removing the pre-release branch, so you'll
-      want some
+      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 main          # update the main branch
         git push origin --tags        # should push the new release tag
@@ -276,6 +296,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,

diff --git a/CMakeLists.txt b/CMakeLists.txt
@@ -20,7 +20,7 @@ add_subdirectory(utils)
 add_subdirectory(stubs)
 
 add_library(logging OBJECT
-  logging.c)
+  logging.c utils/logeventf.c)
 
 add_library(eventloop STATIC
   callback.c timing.c)
@@ -36,7 +36,8 @@ add_library(crypto STATIC
 add_subdirectory(crypto)
 
 add_library(network STATIC
-  errsock.c logging.c x11disp.c
+  errsock.c x11disp.c
+  $<TARGET_OBJECTS:logging>
   proxy/proxy.c
   proxy/http.c
   proxy/socks4.c
@@ -54,7 +55,7 @@ add_library(agent STATIC
 
 add_library(guiterminal STATIC
   terminal/terminal.c terminal/bidi.c
-  ldisc.c config.c dialog.c
+  ldisc.c terminal/lineedit.c config.c dialog.c
   $<TARGET_OBJECTS:logging>)
 
 add_library(noterminal STATIC
@@ -87,6 +88,11 @@ add_executable(test_decode_utf8
 target_compile_definitions(test_decode_utf8 PRIVATE TEST)
 target_link_libraries(test_decode_utf8 utils ${platform_libraries})
 
+add_executable(test_unicode_norm
+  utils/unicode-norm.c)
+target_compile_definitions(test_unicode_norm PRIVATE TEST)
+target_link_libraries(test_unicode_norm utils ${platform_libraries})
+
 add_executable(test_tree234
   utils/tree234.c)
 target_compile_definitions(test_tree234 PRIVATE TEST)
@@ -111,7 +117,8 @@ add_executable(bidi_test
 target_link_libraries(bidi_test guiterminal utils ${platform_libraries})
 
 add_executable(plink
-  ${platform}/plink.c)
+  ${platform}/plink.c
+  stubs/no-lineedit.c)
 # Note: if we ever port Plink to a platform where we can't implement a
 # serial backend, this be_list command will need to become platform-
 # dependent, so that it only sets the SERIAL option on platforms where
@@ -151,8 +158,30 @@ target_link_libraries(psocks
   eventloop console network utils
   ${platform_libraries})
 
+add_executable(test_conf
+  test/test_conf.c
+  stubs/no-agent.c
+  stubs/no-callback.c
+  stubs/no-gss.c
+  stubs/no-ldisc.c
+  stubs/no-network.c
+  stubs/no-timing.c
+  proxy/noproxy.c # FIXME: move this to stubs
+)
+be_list(test_conf TestConf SSH SERIAL OTHERBACKENDS)
+target_link_libraries(test_conf sshclient otherbackends settings network crypto utils ${platform_libraries})
+
 foreach(subdir ${platform} ${extra_dirs})
   add_subdirectory(${subdir})
 endforeach()
 
+# Nasty bodge: we'd like to run this command inside unix/CMakeLists,
+# adding the 'charset' library to everything that links with utils.
+# But that wasn't allowed until cmake 3.13 (see cmake policy CMP0073),
+# and we still have a min cmake version less than that. So we do it
+# here instead.
+if(platform STREQUAL unix)
+  target_link_libraries(utils charset)
+endif()
+
 configure_file(cmake/cmake.h.in ${GENERATED_SOURCES_DIR}/cmake.h)
diff --git a/LATEST.VER b/LATEST.VER
@@ -1 +1 @@
-0.81
+0.82
diff --git a/README b/README
@@ -1,14 +1,23 @@
-This is the README for PuTTY, a free Windows and Unix Telnet and SSH
-client.
+PuTTY source code README
+========================
+
+This is the README for the source code of PuTTY, a free Windows and
+Unix Telnet and SSH client.
 
 PuTTY is built using CMake <https://cmake.org/>. To compile in the
-simplest way (on any of Linux, Windows or Mac), run these commands in
-the source directory:
+simplest way (on any of Linux, Windows or Mac), the general method is
+to run these commands in the source directory:
 
   cmake .
   cmake --build .
 
-Then, to install in the simplest way on Linux or Mac:
+These commands will expect to find a usable compile toolchain on your
+path. So if you're building on Windows with MSVC, you'll need to make
+sure that the MSVC compiler (cl.exe) is on your path, by running one
+of the 'vcvars32.bat' setup scripts provided with the tools. Then the
+cmake commands above should work.
+
+To install in the simplest way on Linux or Mac:
 
   cmake --build . --target install
 

diff --git a/cmake/cmake.h.in b/cmake/cmake.h.in
@@ -48,6 +48,7 @@
 #cmakedefine01 HAVE_BINARY_SETPGRP
 #cmakedefine01 HAVE_PANGO_FONT_FAMILY_IS_MONOSPACE
 #cmakedefine01 HAVE_PANGO_FONT_MAP_LIST_FAMILIES
+#cmakedefine01 HAVE_G_APPLICATION_DEFAULT_FLAGS
 
 #cmakedefine01 HAVE_AES_NI
 #cmakedefine01 HAVE_SHA_NI

diff --git a/cmake/gtk.cmake b/cmake/gtk.cmake
@@ -84,6 +84,10 @@ if(GTK_FOUND)
       ${HAVE_PANGO_FONT_FAMILY_IS_MONOSPACE} PARENT_SCOPE)
     set(HAVE_PANGO_FONT_MAP_LIST_FAMILIES
       ${HAVE_PANGO_FONT_MAP_LIST_FAMILIES} PARENT_SCOPE)
+    check_c_source_compiles("
+      #include <gtk/gtk.h>
+      int f = G_APPLICATION_DEFAULT_FLAGS;
+      int main(void) {}" HAVE_G_APPLICATION_DEFAULT_FLAGS)
   endfunction()
   pango_check_subscope()
 endif()
diff --git a/cmake/winegcc b/cmake/winegcc
@@ -5,6 +5,7 @@
 # options that CMake gets wrong.
 
 init=true
+link=true
 for arg in init "$@"; do
     if $init; then
         set --
@@ -21,9 +22,18 @@ for arg in init "$@"; do
         # suffix.
         -l*.lib) set -- "$@" "${arg%.lib}";;
 
+        # Options that mean we're not linking.
+        -E | -S | -c) link=false  set -- "$@" "$arg";;
+
         # Anything else, we leave unchanged.
         *) set -- "$@" "$arg";;
     esac
 done
 
+if $link; then
+    # winegcc requires this library for _wfopen
+    set -- "$@" -lucrtbase
+fi
+
+echo "$@" >&2
 exec winegcc "$@"
diff --git a/cmdgen.c b/cmdgen.c
@@ -717,10 +717,11 @@ int main(int argc, char **argv)
 
     /*
      * If run with at least one argument _but_ not the required
-     * ones, print the usage message and return failure.
+     * ones, fail with an error.
      */
     if (!infile && keytype == NOKEYGEN) {
-        usage(true);
+        fprintf(stderr, "puttygen: expected an input key file name, "
+                "or -t for a type of key to generate\n");
         RETURN(1);
     }