The 6.6.7.rc3 release candidate is available (fix Cygwin make check; update translations)

--===============4079643284372446732==
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="UlZ3usecp00BjpIP"
Content-Disposition: inline


--UlZ3usecp00BjpIP
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

The 6.6.7.rc3 release of fetchmail is now available at the usual locations,
including <https://downloads.sourceforge.net/project/fetchmail/branch_6.6/>.

This updates more translations and should fix a Cygwin build issue=20
affecting the test suite's rfc822 test program that can't find getopt.

The source archive is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.6/fetchmail-6=
=2E6.7.rc3.tar.xz/download>

The detached GnuPG signature is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.6/fetchmail-6=
=2E6.7.rc3.tar.xz.asc/download>

The SHA256 hashes for the tarballs are:
SHA2-256(fetchmail-6.6.7.rc3.tar.xz)=3D 6ce692664c32b5a3dd196a4a54a480c2b48=
7412411babe696bc6db4a8edf20ae


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

## BUGFIXES:
* Safeguard internal NTLM buffer handling to avoid overrun if server
  sends extremely long fields in the challenge, to avoid stack corruption.
  Reported by "Tristan".

  The code will report the buffer sizing issue and abort the NTLM authentic=
ation
  flow properly so that it's clear that message sizes are the issue.
  Fetchmail 6.6.7 currently supports 1 kByte of NTLM payload for each of the
  three messages, plus header.

  Earlier reports of this bug overestimated the impact.  While the bug
  indeed can write beyond the end of a stack-based buffer, it is reaching
  into another stack-based buffer that is at least 2048 bytes large, whereas
  the overflow is a few dozen bytes at most.  The worst impact is that the
  NegotiateFlags value in the final Authenticate Message step of the NTLM
  authentication protocol gets messed up and the authentication fails.

  It COULD previously happen, depending on hardening, stack protection and=
=20
  other compiler flags that these protections terminate fetchmail because=
=20
  one write to a data structure crosses into an other variable that is=20
  adjacent, on normal stack layouts that "victim" would be the challenge=20
  message, which was already read except for its "flags" value.  The=20
  termination can happen, for instance, with the Address Sanitizer feature.

  NOTE: NTLM is based on obsolete cryptographic mechanisms
  and should not be used without TLS or SSL security for the transport.

  NOTE: fetchmail 7 will remove support for NTLM and MSN authentication.
  Microsoft (who own the specification) generally advises that applications
  should not use NTLM, and is replacing with with Kerberos, see
  [MS-NLMP]: NT LAN Manager (NTLM) Authentication Protocol,
  https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/
  See Introduction and Security Considerations for Implements
  (In Version 37.0 of the spec, sections 1 and 5.1 on page 84)

  Since this WAS initially reported as a stack smashing vulnerability,
  a security announcement fetchmail-SA-2026-01 will be issued to reduce
  the severity of the impact in public reporting.

* The IMAP protocol exchange was made stricter,
  (1) it will validate tagged responses that we received the right
  response to make sure fetchmail and the IMAP server are still in synch,
  (2) it will no longer accept the response words OK, NO, BAD, BYE if
  there is trailing garbage, and will now reject "OKAY" or "NONE", which
  would previously be accepted as aliases for OK or NO.

* For NTLM: Made protocol exchange more robust and make it track errors
  and SASL cancellation better to avoid hangs if NTLM does not work but oth=
er
  authentication schemes do or NTLM gets rejected by the server.

* Handling of escape sequences in the rcfile has been bugfixed to handle
  all ISO C escape sequences and handle octal escapes more strictly.

* The AC_LIBOBJ extensions have been moved to a lib/ subdirectory
  in an attempt to fix #96 reported by Achim (ASSI).

## TRANSLATION UPDATES were contributed by these fine people - thank you!

* eo:    Keith Bowes [Esperanto]
* ja:    Takeshi Hamasaki [Japanese]
* ro:    Remus-Gabriel Chelu [Romanian]
* cs:    Petr Pisar [Czech]
* es:    Cristian Oth=F3n Mart=EDnez Vera [Spanish]
* sv:    G=F6ran Uddeborg [Swedish]
* fr:    Fr=E9d=E9ric Marchal [French]
* pl:    Jakub Bogusz [Polish]
* it:    Luca Vercelli [Italian]

(listed in random order)

---------------------------------------------------------------------------=
----

--UlZ3usecp00BjpIP
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3EplW9mTzUhx+oIQ5BKxVu/zhVoFAmptPCQACgkQ5BKxVu/z
hVppURAAgGzuCkYm0Bo2m1k9/TNH/icUw8Fe7mnO3fp2649Duo3FHfql5Nfd1jLV
pDqssFWvJWsECvFlrYSrb1WcsE9r+RVsGj+be6gDmTGdkwhN0t2Nqn5HqDJMUGUC
kENnUS17Xr0qW+HPfsJsfLK/avJWkmvCOo+HAhaIaJnqPPN9lWg1c5cfviF2ulZi
/Jw9XwSZb5suH0GxHVJFLavZ9jz4/cxeSXnaV7/hBcVpODGgo/NhqoAj0CvHN2Lm
BkXweL7HRd9c4w+NaK5mqc7UT4f1EarvnSCYOBUkhTvVEGcqga1gbB1hQ3ljtiuM
7SxuAHAftFElxDXyQ982l0JiOXlm7Lzbj/U4TkV0JB5SegHEncQm1z78bAoFx91A
wRjFh3sy3pfmQwcf+51JqDFAtSKeaUbCMGHeMB9IKzdMNtw5tOYDu7Xnxf4Q91IS
Vr1JeenLBmvDdUu49fCy/9mfw3k4IVjrEAJZX2uwd0gWfs93VodrUyM+4FUoo+yn
vBUNXLawpLlDQ0f/rbqnlCbm/rvIJPWPrqS23+LacBTzDVSH+x88wf1FQyylBfmr
sF2XYX+njHAAFvUTc/mpoUjs2Uvi5bDlqFnlONiPJ8+IgZnVIGUxS3wwRco+YqZt
Dr2/dx04iA0aZ3UWp493CTydavM1NukVSyMkmHsq1zU6rJ0DqUw=
=fpOK
-----END PGP SIGNATURE-----

--UlZ3usecp00BjpIP--


--===============4079643284372446732==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============4079643284372446732==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Fetchmail-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fetchmail-users

--===============4079643284372446732==--