[Fetchmail-devel] ANNOUNCE: fetchmail 6.5.5 release candidate available (more C23/GCC15 fixes, password zeroing)

[Matthias A. <mat...@gm...>]

The 6.5.5.rc1 release candidate
of fetchmail is now available at the usual locations, including
<https://downloads.sourceforge.net/project/fetchmail/branch_6.5/>.

Please test soon in your usual configuration, please compile with
-fsanitize=address,undefined added to CFLAGS if your compiler supports
that, and let me know if it's OK or if new issues show up.

I intend to release 6.5.5 next week if things work out.

The source archive is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.5.rc1.tar.xz/download>

The detached GnuPG signature is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.5.rc1.tar.xz.asc/download>

The SHA256 hashes for the tarballs are:
SHA2-256(fetchmail-6.5.5.rc1.tar.xz)= c35eeece253a1bf4b0aa8f3467f8d0eb111d99c3caddbdf5f8fdbd2413ef9b63


Here are the release notes:
--------------------------------------------------------------------------------
fetchmail-6.5.5 (not yet released):

## LICENSING CHANGE OF WOLFSSL:
* Note that wolfSSL 5.8.2 switched license from GPLv2 to GPLv3, so if
  a distribution links fetchmail against wolfSSL, this implies the use
  of the "or-any-later-version" clause of the GPLv2-or-later licensed material
  in fetchmail, and the combined work can also only ship as GPLv3.
  wolfSSL has therefore lost its licensing advantage and has been marked
  for potential removal in fetchmail 7 above.
  (OpenSSL 3 is under the Apache License 2.0 and a combined work
  of fetchmail with OpenSSL 3 also requires the combined work to ship
  as GPLv3.)

## BUGFIXES:
==-- note that these comprise C23 compatibility fixes (GCC 15) --==
* Support t.operation when the running user is different from the one
  mentioned in the $USER variable.  Fix courtesy of Corey Halpin.
* The kerberos*_auth() functions for v4 and v5 have prototypes now,
  so they can be compiled by the most modern C compilers.
* AC_TYPE_* type-checking macros seem unnecessary, strip them, also from
  config.h.meson which would not fill them from build.meson. We expect
  the operating system to provide us pid_t, size_t, uint32_t.
* Our res_search() autoconf check was broken on compilers adhering to newer
  standards (C23), for instance GCC 15, disabling several DNS-based features
  in autotools-based builds, but not meson-based builds.
  Strip the bogus "extern int res_search();" declaration without prototype,
  we would need to have the prototype from the system either way.

## IMPORTANT CHANGE:
* Fetchmail is now more careful to actually clear password and like buffers
  in memory, so that is less likely that other processes could access them
  should they happen to access similar memory regions after fetchmail's exit.
    Fetchmail now uses memset_explicit(), explicit_bzero(), or its own
  explicit_bzero() implementation to clear memory buffers that contain
  passwords or like secrets, or their base64 equivalents, and also buffers
  that it uses to visualize such strings, instead of just using memset().
    The motivating reason is that a plain memset() that does not have
  /observable/ effects, i. e. when we do not read from the buffer or
  transfer it, can be removed by the compiler's optimizer in the so-called
  dead store elimination, voiding our attempt to clear the buffer contents
  before releasing it to the heap.
    The named alternative functions are not being optimized away.

## WORKAROUND:
* IMAP: Recognize SASL_IR advertisement of Cyrus IMAP 3.10.0...3.12.? as
  synonymous to SASL-IR per RFC4959.  Upstream bug reported at
  https://github.com/cyrusimap/cyrus-imapd/issues/5481 - and it was
  quickly fixed in all their supported branches by patch releases.

## CHANGES:
* Several documentation tweaks.
* As long as SOURCE_DATE_EPOCH is set, the source tarball build may
  be reproducible now.  Tested on Fedora 42.
* The Japanese translation [ja] has been updated by Takeshi Hamasaki.
* The Makefile should be compatible across a wider set of make implementations,
  beyond GNU make.

-------------------------------------------------------------------------------