Re: [Fetchmail-users] The 6.6.7.rc1 release candidate is available (security fix for NTLM protocol, possible RCE)

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

Am 13.07.26 um 21:49 schrieb Andrew C Aitchison:
> On Mon, 13 Jul 2026, Norman Ramsey wrote:
>
>> > The 6.6.7.rc1 release candidate of fetchmail tightens code
>> > around a security vulnerability in the NTLM code.
>> > It is now available at the usual locations, including
>> > <https://downloads.sourceforge.net/project/fetchmail/branch_6.6/>.
>>
>> Building on Debian stable, I'm running into this build issue, which is
>> not addressed in the FAQ:
>>
>>    nr@homedog ~/n/fetchmail> make check
>>    CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh 
>> /home/nr/net/fetchmail/missing aclocal-1.14 -I m4 -I m4-local
>>    /home/nr/net/fetchmail/missing: 81: aclocal-1.14: not found
>>    WARNING: 'aclocal-1.14' is missing on your system.
>>             You should only need it if you modified 'acinclude.m4' or
>>             'configure.ac' or m4 files included by 'configure.ac'.
>>             The 'aclocal' program is part of the GNU Automake package:
>>             <http://www.gnu.org/software/automake>
>>             It also requires GNU Autoconf, GNU m4 and Perl in order 
>> to run:
>>             <http://www.gnu.org/software/autoconf>
>>             <http://www.gnu.org/software/m4/>
>>             <http://www.perl.org/>
>>    make: *** [Makefile:893: aclocal.m4] Error 127
>>    nr@homedog ~/n/fetchmail [2]> l /usr/bin/aclocal*
>>    /usr/bin/aclocal@  /usr/bin/aclocal-1.15* /usr/bin/aclocal-1.17*
>>
>> I did not modify the files that are mentioned.
>>
>> Running `make install` is also blocked by this error.
>>
>> I can globally replace aclocal-1.14 with aclocal 1.15, but if the
>> Makefile is looking for such a specific version, perhaps I should not
>> tinker with things I don't understand.
>>
>> Please advise me how to proceed.
>
> I think
>         rm Makefile ; configure
> should be sufficient. Add whatever configure options you usually use.
>
> If not, you may need to run
>         rm Makefile.in ; automake
> and then then above
>         rm Makefile ; configure
> again.
>
> It looks like your automake has been updated since you last built 
> fetchmail,
> so removing config.status and/or or autom4te.cache/
> *might* be appropriate too.

Norman reported NOT having done so.  I have test built the freshly 
downloaded and unpackged tarball in a freshly pulled debian:stable 
container where I installed build-essential make libssl-dev, no such 
observation.

The usual cause that the autoconf/automake/gettext stuff wants to update 
its files is that timestamps got messed up, or that the computer time is 
way behind.
This might happen on tiny computers without real-time clock if they fail 
to synchronize upon boot.

If the computer slept for long enough in suspend mode so the clock is 
behind, or a computer without or with broken/unset/wrongly set RTC boots 
up and can't get the time from the network during boot, it can happen 
that the tarball is "in the future" from the perspective of the computer 
that built the tarball (mine), confusion ensues.

Now, as a result of an oversight in the build scripts, I export 
TAR_OPTIONS with an empty --mtime= argument which means all files get 
"start of today" date (midnight in the local timezone). This does work 
in my testing on Debian stable without forcing rebuilds of automake etc.

HTH