>Here is a pastebin of the strace -f invocation:
>https://pastebin.com/qbJRWBrf
>Please note that I just compiled all skaware
>myself with s6-networking using BearSSL
>and this installation does NOT have that problem.
Found it, thanks to the strace.
It is indeed a bug... in smtpd-starttls-proxy.
The root of the problem is that the UCSPI-TLS protocol, used between
s6-ucspitlsd and smtpd-starttls-proxy-io to implement opportunistic TLS,
goes against the conventional wisdom that fds should not be shared
between programs. (Unfortunately, it has to; there is no other way to
proceed that allow a STARTTLS implementation to be as simple.)
s6-ucspitlsd and smtpd-starttls-proxy-io run in parallel. The former
waits for an instruction from the latter. (On STARTTLS, smtpd-starttls-
proxy instructs s6-ucspitlsd to turn into s6-tlsd-io and start
deciphering from the network; on a command that proves the client will
not attempt STARTTLS, smtpd-starttls-proxy instructs s6-ucspitlsd to
forget it and exit.) Crucially, both of these programs have fds to the
network socket: smtpd-starttls-proxy uses the socket now, in plaintext,
and s6-ucspitlsd may use it later, in ciphertext.
smtpd-starttls-proxy-io runs as an asynchronous IO event loop on 4 fds,
which it sets non-blocking at start. The socket is among them. And
unfortunately, the nonblock flag is not a property of the fd, but of
the underlying file, so it applies to s6-ucspitlsd's fds to the network
socket as well. And until now, smtpd-starttls-proxy-io failed to clear
the nonblock flag before passing the bucket to s6-ucspitlsd. And that
is how s6-tlsd-io found itself with a nonblocking stdin+stdout.
The bug is unnoticeable when s6-networking is linked against BearSSL,
because the BearSSL implementation of s6-tlsd-io does not need the
socket to be blocking (it is an asynchronous IO event loop as well,
even during the handshake). The libtls implementation, however, expects
the socket to be blocking.
The latest git of smtpd-starttls-proxy should fix the bug. If you
cannot use git, a release of all the skaware packages should happen
before next year. Thanks for the report and sorry for the
inconvenience.
--
Laurent
Received on Thu Dec 04 2025 - 16:20:01 CET