Fixpoint

This is a reprint for the blog of a brief but revealing conversation wherein I invited the developers of Dovecot, a prominent Internet Mail Access Protocol (IMAP) server, to maybe do something useful⁽ⁱ⁾ by fixing the brokenness of their code-spew, as revealed by its almost comical failures to work properly on an intellectually approachable, security oriented operating system. Apparently I'm the first to have ever attempted such an outlandish thing and they're confident I'll be the last, too.

Subject: Static build problems
From: Jacob Welsh
Date: Fri Oct 7 22:51:08 UTC 2022

I'm attempting to build the latest Dovecot, version 2.3.19.1, on Gales Linux, a distribution based on musl libc with all static linking.

After working around some expected troubles to generate configure, such as the libtool and iconv.m4 dependencies, the build appeared to complete successfully. But on closer inspection, the plugins were installed as a bunch of .a and .la files rather than getting linked into any of the binaries, as would be necessary to actually use them.

I determined that the probe for dynamic module support (DOVECOT_MODULES defined in 'm4/modules.m4') had returned a false positive: in the static configuration musl includes a stub dlopen() that always returns failure at runtime, so a compile-and-link-only test is not predictive. Libtool itself is affected in the same way, but it comes with the --disable-shared option which usually makes things works fine.

Short of a proper solution (perhaps removing modules.m4 and going instead by what libtool already determined, since you've decided to depend on it anyway), I stubbed out modules.m4 to simply return the correct result for this platform, thus:

AC_DEFUN([DOVECOT_MODULES], [
   have_modules=no
   AC_SUBST(MODULE_LIBS)
   AC_SUBST(DLLIB)
])

Now the build is failing due to the absence of a function that's defined only when HAVE_MODULES is true:

libtool: link: gcc -I../../src/lib -I../../src/lib-test -I../../src/lib-ssl-iostream -DDCRYPT_MODULE_DIR="/gales/pkg/dovecot-0.0-2.3.19.1/lib/dovecot" -DDCRYPT_SRC_DIR="../../src/lib-dcrypt" -std=gnu99 -g -O1 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -fno-builtin-strftime -Wstrict-aliasing=2 -Wl,--whole-archive -Wl,../lib-ssl-iostream/.libs/libssl_iostream.a -Wl,--no-whole-archive -o test-stream test_stream-dcrypt.o test_stream-istream-decrypt.o test_stream-ostream-encrypt.o test_stream-test-stream.o  ../lib-ssl-iostream/.libs/libssl_iostream.a ../lib-test/.libs/libtest.a ../lib/.libs/liblib.a
test_crypto-dcrypt.o: In function `dcrypt_initialize':
/home/user/gales-linux/gports/dovecot/build/dovecot-2.3.19.1/src/lib-dcrypt/dcrypt.c:34: undefined reference to `module_dir_try_load_missing'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:664: test-crypto] Error 1

I noticed commit d21897832a443d139d56b1fb1c86d8f76e5f77f3 from 2009, "Fixed compiling without module support", and clearly it's supposed to work since the #ifdefs are there, but I begin to suspect that nobody's actually tested this branch of the configuration tree recently.

Further, looking through the automakefiles I'm not finding how the plugin libraries are supposed to work at all in this case and I begin to fear that they simply... aren't.

Say it ain't so?

Jacob

From: Aki Tuomi
Date: Sun Oct 9 08:35:40 UTC 2022

We don't test all static builds, since we don't use or ship Dovecot in that manner. So, it is very likely it will not work.

Aki

From: Jacob Welsh
Date: Sun Oct 9 18:35:35 UTC 2022

Alright, then is there any desire to fix it?

Jacob

From: Aki Tuomi
Date: Sun Oct 9 19:31:20 UTC 2022

If you or someone else in community comes up with a fix we can consider merging it at some point.

Aki

1. Should I at least acknowledge all those years of hard work they put in to make something I can even consider using? I'm not sure that can be answered before considering the flip side: what better alternatives never saw the light of day because these guys were occupying the space in the IMAP world with their "highly focused on security" design and implementation, or in the larger picture, because IMAP was occupying the space of how permanent mail collections are to be queried from a server? [^]