posttls-finger fails to connect to private/tlsmgr

[Nick Tait]

[SRU]

[Impact]

 If posttls-finger is not used within /var/spool/postfix, the private/tlmsgr socket is not found and TLS is disabled.

[Test Plan]

 This behaviour has been seen in Focal, Hirsute (also in Impish).

 To test the bad response, run posttls-finger mx.dmz.tait.net.nz outside /var/spool/postfix folder:

 root@focal::/home/ubuntu# posttls-finger mx.dmz.tait.net.nz
 posttls-finger: warning: connect to private/tlsmgr: No such file or directory
 posttls-finger: warning: connect to private/tlsmgr: No such file or directory
 posttls-finger: warning: problem talking to server private/tlsmgr: No such file or directory
 posttls-finger: warning: no entropy for TLS key generation: disabling TLS support
 posttls-finger: Connected to mx.dmz.tait.net.nz[114.23.142.178]:25
 posttls-finger: < 220 mx.tait.net.nz ESMTP Postfix (Ubuntu)
 posttls-finger: > EHLO impish-squid-postfix.lxd
 posttls-finger: < 250-mx.tait.net.nz
 posttls-finger: < 250-PIPELINING
 posttls-finger: < 250-SIZE 20480000
 posttls-finger: < 250-STARTTLS
 posttls-finger: < 250-ENHANCEDSTATUSCODES
 posttls-finger: < 250-8BITMIME
 posttls-finger: < 250-SMTPUTF8
 posttls-finger: < 250 CHUNKING
 posttls-finger: > QUIT
 posttls-finger: < 221 2.0.0 Bye

 Good response has STARTTLS section and also the warning messages doesn't appear.

[Where problems could occur]

 It can affect other global variables/functions reallocated in the shared library, so unexpected behaviour can arise for other postfix tools using the shared libraries that the package provides (in the sense of not-discovered-yet bugs).

[Other Info]

 Reported upstream at https://marc.info/?l=postfix-users&m=163094641524790&w=2 . From there, they said:
"Ubuntu should not use -Bsymbolic or -Bsymbolic-functions when building
Postfix shared libraries."

[Original Report]
---

When running posttls-finger on focal, it attempts to connect to private/tlsmgr, and unless the program is being run from /var/spool/postfix as root, this fails and posttls-finger disables TLS in the subsequent connection that it makes to the specified SMTP server.

If the user doesn't notice the "disabling TLS support" message in the output, they might infer that the test has successfully verified their TLS configuration, when in fact all it has verified is that it can connect to the SMTP server without TLS.

The following command shows the problem:

root@maimbo:/# posttls-finger mx.dmz.tait.net.nz
posttls-finger: warning: connect to private/tlsmgr: No such file or directory
posttls-finger: warning: connect to private/tlsmgr: No such file or directory
posttls-finger: warning: problem talking to server private/tlsmgr: No such file or directory
posttls-finger: warning: no entropy for TLS key generation: disabling TLS support
posttls-finger: using DANE RR: _25._tcp.mx.dmz.tait.net.nz -> mx.dane.tait.net.nz IN TLSA 3 1 1 19:D6:84:A7:45:FF:A1:46:0E:09:1B:10:CE:B8:4D:68:BF:EA:A9:C4:EA:51:2D:0F:30:A4:1D:D4:41:DE:0F:AC
posttls-finger: Connected to mx.dmz.tait.net.nz[192.168.20.196]:25
posttls-finger: < 220 mx.tait.net.nz ESMTP Postfix (Ubuntu)
posttls-finger: > EHLO maimbo.tait.net.nz
posttls-finger: < 250-mx.tait.net.nz
posttls-finger: < 250-PIPELINING
posttls-finger: < 250-SIZE 20480000
posttls-finger: < 250-ETRN
posttls-finger: < 250-STARTTLS
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250-8BITMIME
posttls-finger: < 250-DSN
posttls-finger: < 250 SMTPUTF8
posttls-finger: > QUIT
posttls-finger: < 221 2.0.0 Bye

In contrast, if the same command is run from /var/spool/postfix as root, the output is as follows:

root@maimbo:/var/spool/postfix# posttls-finger mx.dmz.tait.net.nz
posttls-finger: using DANE RR: _25._tcp.mx.dmz.tait.net.nz -> mx.dane.tait.net.nz IN TLSA 3 1 1 19:D6:84:A7:45:FF:A1:46:0E:09:1B:10:CE:B8:4D:68:BF:EA:A9:C4:EA:51:2D:0F:30:A4:1D:D4:41:DE:0F:AC
posttls-finger: Connected to mx.dmz.tait.net.nz[192.168.20.196]:25
posttls-finger: < 220 mx.tait.net.nz ESMTP Postfix (Ubuntu)
posttls-finger: > EHLO maimbo.tait.net.nz
posttls-finger: < 250-mx.tait.net.nz
posttls-finger: < 250-PIPELINING
posttls-finger: < 250-SIZE 20480000
posttls-finger: < 250-ETRN
posttls-finger: < 250-STARTTLS
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250-8BITMIME
posttls-finger: < 250-DSN
posttls-finger: < 250 SMTPUTF8
posttls-finger: > STARTTLS
posttls-finger: < 220 2.0.0 Ready to start TLS
posttls-finger: mx.dmz.tait.net.nz[192.168.20.196]:25: depth=0 matched end entity public-key sha256 digest=19:D6:84:A7:45:FF:A1:46:0E:09:1B:10:CE:B8:4D:68:BF:EA:A9:C4:EA:51:2D:0F:30:A4:1D:D4:41:DE:0F:AC
posttls-finger: mx.dmz.tait.net.nz[192.168.20.196]:25: subjectAltName: mx.tait.net.nz
posttls-finger: mx.dmz.tait.net.nz[192.168.20.196]:25 CommonName mx.tait.net.nz
posttls-finger: mx.dmz.tait.net.nz[192.168.20.196]:25: subject_CN=mx.tait.net.nz, issuer_CN=Nick's Domain CA, fingerprint=FD:88:18:3D:9D:33:4C:0B:B8:F9:E8:64:4B:23:D6:05:F1:DB:8D:21, pkey_fingerprint=03:6B:E4:D3:73:82:D5:B4:EB:98:96:BB:56:77:A2:48:C2:73:A0:03
posttls-finger: Verified TLS connection established to mx.dmz.tait.net.nz[192.168.20.196]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
posttls-finger: > EHLO maimbo.tait.net.nz
posttls-finger: < 250-mx.tait.net.nz
posttls-finger: < 250-PIPELINING
posttls-finger: < 250-SIZE 20480000
posttls-finger: < 250-ETRN
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250-8BITMIME
posttls-finger: < 250-DSN
posttls-finger: < 250 SMTPUTF8
posttls-finger: > QUIT
posttls-finger: < 221 2.0.0 Bye

Which of course now includes the "Verified TLS connection established..."
line.

[Scott Kitterman (kitterman)]

We (Debian and derivatives such as Ubuntu) have postfix in a chroot by default. This is a side effect of that configuration.

[Nick Tait (nick.t)]

Hi Scott.

I was thinking it was something along those lines, but based on what I've read this issue is specific to focal.

From Jan's original bug report - https://bugs.launchpad.net/ubuntu/focal/+source/postfix/+bug/1868955/comments/2 (which eventually focussed on just the DANE issue):

> ... However the problem is *not* present in Debian sid or Buster, nor I could find a Debian bug referencing to it.

FYI I can also confirm that this issue doesn't occur on bionic.

Did something relating to the chroot thing change in focal?

Nick.

[Scott Kitterman (kitterman)]

No. We've had postfix in a chroot since approximately forever. It might be something in default path resolution has changed? Since I no longer us Ubuntu, I really don't know.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Emmanuel Fusté (emmanuel-fuste-thalesgroup)]

Running not chrooted here since age. But affected.

This is clearly a linking problem. Posttls-finger does not pick the tlsmgr subs of the local tlsmgrmem.o object but the global real one.
Citing the posttls-finger source code : " It does not communicate with the tlsmgr daemon (or any other Postfix daemons); its TLS session cache is held in private memory".

I don't have the competence and time to fix this (I tried). Will try to rebuild the latest Debian package + upstream patchs as I need the latest fixes.

[Emmanuel Fusté (emmanuel-fuste-thalesgroup)]

Ok, you know what ? Latest Debian package rebuild on Ubuntu : same error.
Will try a verbatim Debian package to see if it is a build chain problem.

[Emmanuel Fusté (emmanuel-fuste-thalesgroup)]

Ubuntu build/toolchain problem confirmed.
The verbatim Debian package work perfectly. No more posttls-finger trying to connect to the tlsmgr daemon.

[Emmanuel Fusté (emmanuel-fuste-thalesgroup)]

Debian sid package + latest 3.5 upstream patch rebuild on Debian sid.
Work perfectly on Ubuntu 20.04 (with libicu67 and libnsl2 added).

[Bryce Harrington (bryce)]

Confirmed the test case (although the provided url is 404) on Focal:

root@triage-focal:/home/bryce# cd /
root@triage-focal:/# posttls-finger mx.dmz.tait.net.nz
posttls-finger: warning: connect to private/tlsmgr: No such file or directory
posttls-finger: warning: connect to private/tlsmgr: No such file or directory
posttls-finger: warning: problem talking to server private/tlsmgr: No such file or directory
posttls-finger: warning: no entropy for TLS key generation: disabling TLS support
posttls-finger: Failed to establish session to mx.dmz.tait.net.nz via mx.dmz.tait.net.nz: connect to mx.dmz.tait.net.nz[114.23.142.178]:25: Connection timed out
root@triage-focal:/# cd /var/spool/postfix
root@triage-focal:/var/spool/postfix# posttls-finger mx.dmz.tait.net.nz
posttls-finger: Failed to establish session to mx.dmz.tait.net.nz via mx.dmz.tait.net.nz: connect to mx.dmz.tait.net.nz[114.23.142.178]:25: Connection timed out
root@triage-focal:/var/spool/postfix#

I don't reproduce this behavior on bionic (just gives the connection timeout), but I can reproduce it in groovy and hirsute.

[Bryce Harrington (bryce)]

A portion of the strace running this from /:

futex(0x7f9b450e27e8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
socket(AF_UNIX, SOCK_STREAM, 0) = 3
fcntl(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR) = 0
connect(3, {sa_family=AF_UNIX, sun_path="private/tlsmgr"}, 110) = -1 ENOENT (No such file or directory)
close(3) = 0
write(1, "posttls-finger: warning: connect"..., 78posttls-finger: warning: connect to private/tlsmgr: No such file or directory
) = 78
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=1, tv_nsec=0}, 0x7ffd4d053bc0) = 0
socket(AF_UNIX, SOCK_STREAM, 0) = 3
fcntl(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR) = 0
connect(3, {sa_family=AF_UNIX, sun_path="private/tlsmgr"}, 110) = -1 ENOENT (No such file or directory)
close(3) = 0
write(1, "posttls-finger: warning: connect"..., 78posttls-finger: warning: connect to private/tlsmgr: No such file or directory
) = 78
write(1, "posttls-finger: warning: problem"..., 93posttls-finger: warning: problem talking to server private/tlsmgr: No such file or directory
) = 93

root@triage-focal:/# ls /var/spool/postfix/private/tlsmgr -l
srw-rw-rw- 1 postfix postfix 0 Mar 31 21:09 /var/spool/postfix/private/tlsmgr

Guessing that the reason it works in /var/spool/postfix but not / is probably due to some call using a relative path to private/tlsmgr rather than an abspath.

[Bryce Harrington (bryce)]

Aha, bunch more analysis was done on this issue as part of this:

    https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1868955

Comment #17 in particular suggests "private/tlsmgr" is probably a red herring, and comment #21 and #23 have some good debugging analysis. Comments #26 and subsequent focus on fixing dane support due to breakage by glibc, released as 3.4.13-0ubuntu1. Comments #43 and #44 are splitting the remaining issue with posttls-finger out as this bug report.

[Christian Ehrhardt  (paelzer)]

In terms of version comparison (call the example not in /var/spool/postfix to have tls support) is:

Ubuntu:
 bionic 3.3.0-1ubuntu0.4 working
 focal 3.4.13-0ubuntu1.1 failing
 hirsute 3.5.6-1 failing
 impish 3.5.6-1ubuntu1 failing

Fedora:
 32 2:3.5.10-2.fc34 working
 34 2:3.5.10-2.fc34 working

So there is also a chance to do good/bad comparison with different code levels running outside of /var/spool/postfix and see where their behavior starts to differ.

Since https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1868955/comments/21 was around tlsmgr being a red herring and later about some flags one might want to rebuild these other postfix versions into e.g. Focal. There the qeustion is "if bionic is rebuilt for focal does it work still" or vice versa "if focals postfix is rebuilt for bionic does it then work". If it does it might indicate that here again some other part of the configuration might be responsible and that the herring that is "private/tlsmgr" has again got us.

P.S. even if it is a red herring it annoys me

TL;DR there are many things to prove before we can even be sure which direction this should be approached.

In that mindset I was forcing the postfix of bionic into focal the most ugly (not recommended) way to see how it would behave.

$ wget https://launchpad.net/ubuntu/+source/postfix/3.3.0-1ubuntu0.4/+build/21989327/+files/postfix_3.3.0-1ubuntu0.4_amd64.deb
$ dpkg -x postfix_3.3.0-1ubuntu0.4_amd64.deb postfix_3.3.0-1ubuntu0.4_amd64
$ wget https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+build/18845669/+files/libicu60_60.2-3ubuntu3.1_amd64.deb
$ dpkg -x libicu60_60.2-3ubuntu3.1_amd64.deb libicu60_60.2-3ubuntu3.1_amd64
$ cd postfix_3.3.0-1ubuntu0.4_amd64/
$ export LD_LIBRARY_PATH="/root/postfix_3.3.0-1ubuntu0.4_amd64/usr/lib/postfix/:/root/libicu60_60.2-3ubuntu3.1_amd64/usr/lib/x86_64-linux-gnu/:$LD_LIBRARY_PATH"
$ usr/sbin/posttls-finger mx.dmz.tait.net.nz

And I can confirm the bionic code executed as-is in the otherwise failing focal environment does work. Thereby this case might not (again) be some missing flag in the other bits of the setup.
But we might have something better to compare here.

root@f:~/postfix_3.3.0-1ubuntu0.4_amd64# usr/sbin/posttls-finger mx.dmz.tait.net.nz
posttls-finger: Connected to mx.dmz.tait.net.nz[114.23.142.178]:25
posttls-finger: < 220 mx.tait.net.nz ESMTP Postfix (Ubuntu)
posttls-finger: > EHLO f.lxd
posttls-finger: < 250-mx.tait.net.nz
posttls-finger: < 250-PIPELINING
posttls-finger: < 250-SIZE 20480000
posttls-finger: < 250-STARTTLS
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250-8BITMIME
posttls-finger: < 250 SMTPUTF8
posttls-finger: > STARTTLS
posttls-finger: < 220 2.0.0 Ready to start TLS
posttls-finger: mx.dmz.tait.net.nz[114.23.142.178]:25: subjectAltName: mx.tait.net.nz
posttls-finger: mx.dmz.tait.net.nz[114.23.142.178]:25 CommonName mx.tait.net.nz
posttls-finger: certificate verification failed for mx.dmz.tait.net.nz[114.23.142.178]:25: untrusted issuer /CN=Nick's Domain CA
posttls-finger: mx.dmz.tait.net.nz[114.23.142.178]:25: subject_CN=mx.tait.net.nz, issuer_CN=Nick's Domain CA, fingerprint=FD:88:18:3D:9D:...

[Christian Ehrhardt  (paelzer)]

And to confirm on "it seems to be opening things relative to the CWD" here a small test:

mkdir -p /tmp/test/private
ln -s /var/spool/postfix/private/tlsmgr /tmp/test/private/tlsmgr
cd /tmp/test/
posttls-finger mx.dmz.tait.net.nz

Miriam will post a few more detailed updates what we have seen in GDB, but the TL;DR is that the calls to socket/happen in a way that makes socket open it relative the the current working directory.

[Christian Ehrhardt  (paelzer)]

Since I have seen 3.5.10 to work in fedora @mirespace and myself have built 3.5.12, but in Ubuntu that fails the very same way as our normal version in impish.
That might be due to differences in the configuration, but I could not easily spot it from here.

Possible steps from here:
a) GDB debug it on Ubuntu AND in Fedore and compare vs each other where the Fedora build manages to connect while we do not (maybe the change the CWD or it is related to all the chrooting of postfix). It certainly is different as there /var/spool/postfix/private/tlsmgr doe not exist at all - and due to that the code might go completely different paths.

b) patch postfix in Ubuntu to prepend a path /var/spool/postfix when opening sockets. Eventually that might be a try-and-fallback, but for now all we need is posttls-finger to see if it "would work" if connections would be made. If it does we can discuss upstream how it would need to work to cover all edge cases.

c) the chrooting makes me wonder, I don't know enough about how it is used in postfix. Chances are that everything but posttls-finger chroots to the same dir and from there these sockets are reachable. If that would be true, the question is if finger should do so as well.

[Christian Ehrhardt  (paelzer)]

More interestingly even the very similar version from Debian works just fine (just as mentioned even back in comment #2).
3.5.6-1+b1 in sid worked fine in my test.
That is closer code and config-wise than Fedora.

That would be a better partner for the comparison in (a).

[Christian Ehrhardt  (paelzer)]

I was exchanging the builds of Debian-sid and Ubuntu in an Impish system.
That means dpkg -i for postfix_3.5.6-1+b1_amd64.deb / postfix_3.5.6-1ubuntu1_amd64.deb

Of these the Ubuntu build fails and the Debian build works.

Due to exchanging it in-place - Everything else like libc and so on are unchanged.

[Christian Ehrhardt  (paelzer)]

Of the config files only /etc/postfix/makedefs.out changes as part of this exchange.
That contains the build-settings and in there one only thing was suspicious to me.
The detection as SYSTYPE = LINUX4 vs the 5 that Ubuntu has.
In the long past these detections could change a lot in the handling inside of postfix.
But nowadays all there is seems to be:
src/util/sys_defs.h:752:#if defined(LINUX2) || defined(LINUX3) || defined(LINUX4) || defined(LINUX5)

So that would not make a difference?
What else could it be - libs/compilers/... at build time?
But if it is broken since Focal then it might more be "default settings" than the versions of these build-time components.

[Christian Ehrhardt  (paelzer)]

To make the exchange have even less side effects I was extracting the .deb files and only called the different finger programs.
I started on a Ubuntu system that is broken, and by the former experiment we know that installing the Debian .deb of postfix would fix it.

1. Only calling the debian built pf-deb/usr/sbin/posttls-finger did not make it work
   The assumption based on that would be that the different behavior happens on the server?

2. The default service starts
   /usr/lib/postfix/sbin/master
   /usr/lib/postfix/sbin/pickup
   /usr/lib/postfix/sbin/qmgr
   Exchanging these three on disk and restarting the service postfix@- did not make
   it work either.

3. All of usr
   $ systemctl stop postfix@-
   $ cp -a pf-deb/usr/* /usr/
   $ systemctl start postfix@-
   *That worked*

=> Ok, it is something in /usr package in the postfix deb but not the three binaries in #2
   Note: the pattern repeats, always stop service / copy / start service / test

4. well maybe it is /usr/lib/postfix/sbin/tlsmgr as that is what we connect to?
   I re-set to the content of postfix_3.5.6-1ubuntu1_amd64.deb
   Then I replaced just tlsmgr
   $ cp pf-deb/usr/lib/postfix/sbin/tlsmgr /usr/lib/postfix/sbin/
   => That was not enough

5. All of /usr/lib/postfix/sbin/*
   cp pf-deb//usr/lib/postfix/sbin/* /usr/lib/postfix/sbin/
   => Still not working

6. Also internal libs:
   cp pf-deb/usr/lib/postfix/* /usr/lib/postfix/
   * working again *

=> Ok, that is better than all of /usr
I have again re-set to postfix_3.5.6-1ubuntu1_amd64.deb

7. cp -v pf-deb/usr/lib/postfix/* /usr/lib/postfix/
   * worked again *

I have again re-set to postfix_3.5.6-1ubuntu1_amd64.deb

8. cp -v pf-deb/usr/lib/postfix/libpostfix-tls.so /usr/lib/postfix/
  * works *

[Christian Ehrhardt  (paelzer)]

That is it - so /usr/lib/postfix/libpostfix-tls.so is the single file we need to exchange on an Ubuntu Impish system taking the libpostfix-tls.so from postfix_3.5.6-1+b1_amd64.deb that makes it work.

It then is also non-important if I run the posttls-finger from the Ubuntu or the Debian build.

Both are built from the very same source, but the one in Ubuntu fails since ~Focal.
Again - since it is not just in impish but happening for a while - it is more likely a build config thing instead of a particular new version.

Next steps:
- identify if libpostfix-tls.so is loaded by posttls-finger or the server (or both)
- then debug how the content and behavior of the functions in there differ when using one or the other build.

[Miriam España Acebal (mirespace)]

libpostfix-tls.so is loaded by posttls-finger as we can see in the debugging session, while trying to figure out how the path to the socket is created:

Breakpoint 1, tls_mgr_open () at tls_mgr.c:163
163 tls_mgr.c: No such file or directory.
(gdb) bt
#0 tls_mgr_open () at tls_mgr.c:163
#1 0x00007ffff7fb0de5 in tls_mgr_seed (buf=0x555555572920, len=32) at tls_mgr.c:184
#2 0x00007ffff7fb1394 in tls_ext_seed (nbytes=32) at tls_seed.c:82
#3 0x00007ffff7fae1e1 in tls_client_init (props=props@entry=0x7fffffffe490) at tls_client.c:374
#4 0x0000555555558871 in tls_init (state=0x55555555f060 <state>) at posttls-finger.c:1781
#5 parse_options (state=0x55555555f060 <state>, argv=0x7fffffffe6e8, argc=2) at posttls-finger.c:2033
#6 main (argc=2, argv=0x7fffffffe6e8) at posttls-finger.c:2129
(gdb) info locals
service = <optimized out>
(gdb) n
165 in tls_mgr.c
(gdb) info locals
service = 0x555555575220 "local:private/tlsmgr"
(gdb) n
167 in tls_mgr.c
(gdb) n
169 in tls_mgr.c
(gdb) n
0x00007ffff7fa55b0 in attr_clnt_control@plt () from /usr/lib/postfix/libpostfix-tls.so

and, then, here is the client structure with path and unix socket connection:
(gdb) print *client->auto_clnt
$4 = {vstream = 0x0, endpoint = 0x555555575300 "private/tlsmgr", timeout = 0, max_idle = 0, max_ttl = 0,
  connect = 0x7ffff7f24b40 <unix_connect>}
(gdb) bt
#0 attr_clnt_request (client=0x555555575250, send_flags=send_flags@entry=0) at attr_clnt.c:177
#1 0x00007ffff7fb0db5 in tls_mgr_seed (buf=0x555555572920, len=32) at ../../include/attr.h:89
#2 0x00007ffff7fb1394 in tls_ext_seed (nbytes=32) at tls_seed.c:82
#3 0x00007ffff7fae1e1 in tls_client_init (props=props@entry=0x7fffffffe490) at tls_client.c:374
#4 0x0000555555558871 in tls_init (state=0x55555555f060 <state>) at posttls-finger.c:1781
#5 parse_options (state=0x55555555f060 <state>, argv=0x7fffffffe6e8, argc=2) at posttls-finger.c:2033
#6 main (argc=2, argv=0x7fffffffe6e8) at posttls-finger.c:2129

All before warning messages starts to appear.

[Christian Ehrhardt  (paelzer)]

BTW since it was trivial to try, forcing the conifig to LINUX4 did not change anything (as expected).

The library that makes the difference consists of all the usual suspects that we've already seen/heard - it is linked from:

tls_prng_dev.o tls_prng_egd.o tls_prng_file.o tls_fprint.o tls_prng_exch.o tls_stream.o tls_bio_ops.o tls_misc.o tls_dh.o tls_rsa.o tls_verify.o tls_dane.o tls_certkey.o tls_session.o tls_client.o tls_server.o tls_scache.o tls_mgr.o tls_seed.o tls_level.o tls_proxy_clnt.o tls_proxy_context_print.o tls_proxy_context_scan.o tls_proxy_client_print.o tls_proxy_client_scan.o tls_proxy_server_print.o tls_proxy_server_scan.o tls_proxy_client_misc.o

The linking parameter difference is in the default toolchain options like
  -Wl,-Bsymbolic-functions -flto=auto
but also any other that are not in the cmdline but still different defaults.

Suggestions:
a)
 - gdb debug the different behavior (debug symbols could be hard)
b)
 to easen (a) consider
 - build a non debug split libpostfix-tls.so in debian and ubuntu
 - verify that using those two libs still makes it work/fail
 - now gdb debug it
c)
 - identify all the differences in our build toolchain
 - Build it in Ubuntu but overriding it to how Debian would work
   If that resulting lib makes it work, then reduce the overrides one by one
   until we found what makes it work/fail
d)
 - I'm open for other ideas :-)

[Christian Ehrhardt  (paelzer)]

Here two non-stripped -O0 builds from the very same 3.6.5-1 (plus the glibc 234 fix):

https://people.canonical.com/~paelzer/libpostfix-tls.so.debugdebian
https://people.canonical.com/~paelzer/libpostfix-tls.so.debugubuntu

The are making the case work/fail when placed at /usr/lib/postfix/libpostfix-tls.so in otherwise normal impish system

[Christian Ehrhardt  (paelzer)]

Before the really interesting bit first some data that is equal.

Frame/Backtrace wise in gdb they do not look too different:

Debian:
Breakpoint 1, tls_log_mask (log_param=0x55555555c6f8 "-L option", log_level=0x5555555728c0 "routine,certmatch") at tls_misc.c:545
545 tls_misc.c: No such file or directory.
(gdb) bt
#0 tls_log_mask (log_param=0x55555555c6f8 "-L option", log_level=0x5555555728c0 "routine,certmatch") at tls_misc.c:545
#1 0x00005555555587d2 in ?? ()
#2 0x00007ffff79c3565 in __libc_start_main (main=0x5555555580f0, argc=2, argv=0x7fffffffe6b8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
    stack_end=0x7fffffffe6a8) at ../csu/libc-start.c:332
#3 0x0000555555559bae in ?? ()

Ubuntu:
Breakpoint 1, tls_log_mask (log_param=0x55555555c6f8 "-L option", log_level=0x5555555728c0 "routine,certmatch") at /build/postfix-9Thbkc/postfix-3.5.6/src/tls/tls_misc.c:545
545 /build/postfix-9Thbkc/postfix-3.5.6/src/tls/tls_misc.c: No such file or directory.
(gdb) bt
#0 tls_log_mask (log_param=0x55555555c6f8 "-L option", log_level=0x5555555728c0 "routine,certmatch") at /build/postfix-9Thbkc/postfix-3.5.6/src/tls/tls_misc.c:545
#1 0x00005555555587d2 in ?? ()
#2 0x00007ffff79c2565 in __libc_start_main (main=0x5555555580f0, argc=2, argv=0x7fffffffe6b8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
    stack_end=0x7fffffffe6a8) at ../csu/libc-start.c:332
#3 0x0000555555559bae in ?? ()

And ldd for both is the same:
$ ldd /usr/sbin/posttls-finger | grep tls
    libpostfix-tls.so => /usr/lib/postfix/libpostfix-tls.so (0x00007f78aeba1000)

The file is loaded and mapped in both cases - both look like:
$ cat /proc/$(pidof posttls-finger)/maps | grep tls.so
7ffff7f97000-7ffff7fa0000 r--p 00000000 00:ba 86770 /usr/lib/postfix/libpostfix-tls.so
7ffff7fa0000-7ffff7fb8000 r-xp 00009000 00:ba 86770 /usr/lib/postfix/libpostfix-tls.so
7ffff7fb8000-7ffff7fbf000 r--p 00021000 00:ba 86770 /usr/lib/postfix/libpostfix-tls.so
7ffff7fbf000-7ffff7fc1000 r--p 00027000 00:ba 86770 /usr/lib/postfix/libpostfix-tls.so
7ffff7fc1000-7ffff7fc2000 rw-p 00029000 00:ba 86770 /usr/lib/postfix/libpostfix-tls.so

Both have the same symbols (slight differences due to LTO, but not everywhere)
root@i-postfix:~# nm libpostfix-tls.so.debugubuntu | grep ' [tT].*tls_log_mask'
000000000000d3e4 T tls_log_mask
root@i-postfix:~# nm libpostfix-tls.so.debugdebian | grep ' [tT].*tls_log_mask'
000000000000c470 T tls_log_mask

[Christian Ehrhardt  (paelzer)]

I had a look at the library interaction like:

$ dist=ubuntu; rm libpostfix-tls.so.${dist}.ltrace; cp -v libpostfix-tls.so.debug${dist} /usr/lib/postfix/libpostfix-tls.so; ltrace -f -s 128 --no-signals --library=libpostfix-tls.so posttls-finger mx.dmz.tait.net.nz >libpostfix-tls.so.${dist}.ltrace 2>&1

$ rm libpostfix-tls.so.${dist}.ltrace; cp -v libpostfix-tls.so.debug${dist} /usr/lib/postfix/libpostfix-tls.so; ltrace -f -s 128 --no-signals --library=libpostfix-tls.so posttls-finger mx.dmz.tait.net.nz >libpostfix-tls.so.${dist}.ltrace 2>&1

I thought I could go in depth onto the function results, but TBH.
In the Ubuntu case it didn't call into the library at all ?!

But only one of them had hits in ltrace at all?!?

I realized that ltrace tried to fool me here.
With --library=libpostfix-tls.so it identifies the symbols in there, and logs calls to those names.
But it is not guaranteed that they will be redirected elsewhere (man ltrace).

A ltrace call without --library=libpostfix-tls.so does NOT list any library calls in both cases.
So something is odd here in regard to where this code really comes from.

With -x @libpostfix-tls.so just as without any -l/-e/-x there was no report at all.
This is interesting as we clearly see the exchange of the library having an effect.
How would it do so it really would not be called.

Could it be that it only uses the data segment of the library and that might differ - sounds like a too crazy theory to me ...

Maybe we can squeeze out of GDB where the text segment of e.g. tls_log_mask really is from while executing?

[Miriam España Acebal (mirespace)]

I built ubuntu package on sid, and this package ubuntu-sourced but debian-built works ok on impish, so ... What is the difference between the two compilations mode? or, does it link something different?

Doing a ldd -v on libpostfix-tls.so* from @paelzer in comment [#22]( https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1885403/comments/22), we see that in debian-built version appears libpthread.so and it doesn't appear in ubuntu-built version:

---- Debian

Version information:
 ./libpostfix-tls.so.debugdebian:
  libpthread.so.0 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libpthread.so.0
  libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
  libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
  libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6
  libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
  libcrypto.so.1.1 (OPENSSL_1_1_0) => /lib/x86_64-linux-gnu/libcrypto.so.1.1
  libssl.so.1.1 (OPENSSL_1_1_1) => /lib/x86_64-linux-gnu/libssl.so.1.1
  libssl.so.1.1 (OPENSSL_1_1_0) => /lib/x86_64-linux-gnu/libssl.so.1.1

---- Ubuntu

 Version information:
 ./libpostfix-tls.so.debugubuntu:
  libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
  libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
  libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6
  libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
  libcrypto.so.1.1 (OPENSSL_1_1_0) => /lib/x86_64-linux-gnu/libcrypto.so.1.1
  libssl.so.1.1 (OPENSSL_1_1_1) => /lib/x86_64-linux-gnu/libssl.so.1.1
  libssl.so.1.1 (OPENSSL_1_1_0) => /lib/x86_64-linux-gnu/libssl.so.1.1

Also, doing a readelf -a , we see libpthread.so also as NEEDED for debian, but not for ubuntu:

---- Debian

Dynamic section at offset 0x27120 contains 34 entries:
  Tag Type Name/Value
 0x0000000000000001 (NEEDED) Shared library: [libssl.so.1.1]
 0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.1.1]
 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED) Shared library: [libpostfix-dns.so]
 0x0000000000000001 (NEEDED) Shared library: [libpostfix-global.so]
 0x0000000000000001 (NEEDED) Shared library: [libpostfix-util.so]
 0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
 0x000000000000000e (SONAME) Library soname: [libpostfix-tls.so]
 0x000000000000001d (RUNPATH) Library runpath: [/usr/lib/postfix]

Version needs section '.gnu.version_r' contains 4 entries:
 Addr: 0x00000000000053e0 Offset: 0x0053e0 Link: 4 (.dynstr)
  000000: Version: 1 File: libpthread.so.0 Cnt: 1
  0x0010: Name: GLIBC_2.2.5 Flags: none Version: 6
  0x0020: Version: 1 File: libc.so.6 Cnt: 4

---- Ubuntu

Dynamic section at offset 0x28340 contains 33 entries:
  Tag Type Name/Value
 0x0000000000000001 (NEEDED) Shared library: [libssl.so.1.1]
 0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.1.1]
 0x0000000000000001 (NEEDED) Shared library: [libpostfix-dns.so]
 0x0000000000000001 (NEEDED) Shared library: [libpostfix-global.so]
 0x0000000000...

[Christian Ehrhardt  (paelzer)]

I realized that gdb and maps (that I both had already) give me all that I need.
When stopping at a function from libpostfix-tls.so I can print where I am and check which file is mapped there:

Breakpoint 1, tls_log_mask (log_param=0x55555555c6f8 "-L option", log_level=0x5555555728c0 "routine,certmatch") at /build/postfix-9Thbkc/postfix-3.5.6/src/tls/tls_misc.c:545
(gdb) info regs
...
rip 0x7ffff7fa43f8 0x7ffff7fa43f8 <tls_log_mask+20>
$ cat /proc/$(pidof posttls-finger)/maps | grep -e 'xp.*tls.so' -e 'xp.*posttls-finger'
555555557000-55555555c000 r-xp 00003000 00:ba 87205 /usr/sbin/posttls-finger
7ffff7fa0000-7ffff7fb8000 r-xp 00009000 00:ba 86770 /usr/lib/postfix/libpostfix-tls.so

So whatever detail I miss from my ltrace incantaton, the code of tls_log_mask really is from the shared library. And while that makes tracing the calls slightly harder it is relieving as it eliminates at least one kind of craziness :-)

[Christian Ehrhardt  (paelzer)]

As I have mentioned before I assume as-needed [1] could play a role, at least for pthread that you wondered about it most likely does.
-lpthread might be listed somewhere, but if not needed it will not effectvely be linked in Ubuntu but t will in Debian.

No guarantees, but I'd not expect pthread to play a big role here - at least to my gut feeling - that non usage of /usr/lib/postfix/libpostfix-tls.so. That might also be a red herring, but it is mine :-)

@miriam - default used compiler/linker flags used effectively in a setup you can mostly get via:
  $ apt install dpkg-dev
  # get built in -m options
  $ gcc -Q --help=target
  # Get any -f and similar options built in or derived from default distro buildflags
  $ echo "int main(void) {}" | gcc $(dpkg-buildflags --get LDFLAGS) -o /dev/null -v -x c - &> /dev/stdout| grep collect
  # Get linker options built in or derived from default distro buildflags
  $ echo "int main(void) {}" | gcc $(dpkg-buildflags --get CFLAGS) -o /dev/null -v -x c - 2>&1 | grep 'cc1'
  # get Defines
  $ gcc -dM -E - < /dev/null
  # If a package build inserts some further flags you can add them as well in this call

@miriam - how about you looking for a comparison of these flags and then approximating them until they match - that could identify one option that causes the effect which will help our theory-crafting.

I can have look at ltrace/function probing in the same time, just to understand what is going on there.

[1]: https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-Wl.2C--as-needed

[Miriam España Acebal (mirespace)]

Comparing sbuild logs and running that commands in the correspondent chroots, we found flags and defines present in impish but not on sid:

* LDFLAGS
    -z now -z relro (but in the build logs is present in both)
    -flto=auto
    -Bsymbolic-functions

*CFLAGS
    -flto=auto -ffat-lto-objects
    -fstack-clash-protection -fcf-protection

* DEFINES
    #define __SSP_STRONG__ 3
    #define __CET__ 3

Also in impish (not present in sid):

Enviroment:
DEB_BUILD_PROFILES="noudeb"

Build-Tainted-By:
 merged-usr-via-aliased-dirs
 usr-local-has-programs

Architecture:amd64_translations

And in the toolchain we can see the present of gcc11/g++11
and different version of linux-libc-dev (among others).

[Miriam España Acebal (mirespace)]

We discover that if we remove the -BSymbolic-functions from LDFLAGS when building, the problem goes away. After this, we think that  something with the exposure/rellocation of the folder for the servicename on the shared library can be the origin of this behaviour. We reported this to upstream (postfix) with the log attached to this comment.

[Christian Ehrhardt  (paelzer)]

That upstream report and answer is great and a clear indication of disabling symblic-functions for this build. Thanks for driving that @mirespace!

[Christian Ehrhardt  (paelzer)]

FYI: Uploaded to impish

[Launchpad Janitor (janitor)]

This bug was fixed in the package postfix - 3.5.6-1ubuntu2

---------------
postfix (3.5.6-1ubuntu2) impish; urgency=medium

  * d/rules: Removed LDFLAG -Bsymbolic-functions (LP: #1885403).
  * d/p/postfix-3.6.2-glibc-234-build-fix.patch: Fix for building
    against glibc-2.34 (LP: #1939353).

 -- Miriam España Acebal <email address hidden> Thu, 02 Sep 2021 13:04:29 +0200

[Miriam España Acebal (mirespace)]

Thanks to you for all your help in this Christian :).

[Steve Langasek (vorlon)]

For future reference, it would be helpful if the upstream rationale for why we should drop this build flag would be included in the SRU bug description. It's quite unusual to have a legitimate case where we should not build with -Bsymbolic-functions; this one does fit the bill but it took some digging to confirm that.

[Steve Langasek (vorlon)]

Hello Nick, or anyone else affected,

Accepted postfix into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/postfix/3.4.13-0ubuntu1.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Steve Langasek (vorlon)]

Hello Nick, or anyone else affected,

Accepted postfix into hirsute-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/postfix/3.5.6-1ubuntu0.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-hirsute to verification-done-hirsute. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-hirsute. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Miriam España Acebal (mirespace)]

Doing verification for Focal:

root@focal:~# apt upgrade postfix/focal-proposed
Reading package lists... Done
Building dependency tree
Reading state information... Done
Selected version '3.4.13-0ubuntu1.2' (Ubuntu:20.04/focal-proposed [amd64]) for 'postfix'
[...]
Unpacking postfix (3.4.13-0ubuntu1.2) over (3.4.13-0ubuntu1.1) ...
Setting up postfix (3.4.13-0ubuntu1.2) ...
[...]

root@focal:~# posttls-finger mx.dmz.tait.net.nz
posttls-finger: Connected to mx.dmz.tait.net.nz[114.23.142.178]:25
posttls-finger: < 220-mx.tait.net.nz ESMTP Postfix (Ubuntu)
posttls-finger: < 220 mx.tait.net.nz ESMTP Postfix (Ubuntu)
posttls-finger: > EHLO focal.lxd
posttls-finger: < 250-mx.tait.net.nz
posttls-finger: < 250-PIPELINING
posttls-finger: < 250-SIZE 20480000
posttls-finger: < 250-STARTTLS
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250-8BITMIME
posttls-finger: < 250-SMTPUTF8
posttls-finger: < 250 CHUNKING
posttls-finger: > STARTTLS
posttls-finger: < 220 2.0.0 Ready to start TLS
posttls-finger: mx.dmz.tait.net.nz[114.23.142.178]:25: subjectAltName: mx.tait.net.nz
posttls-finger: mx.dmz.tait.net.nz[114.23.142.178]:25 CommonName mx.tait.net.nz
posttls-finger: certificate verification failed for mx.dmz.tait.net.nz[114.23.142.178]:25: untrusted issuer /CN=Nick's Domain CA
posttls-finger: mx.dmz.tait.net.nz[114.23.142.178]:25: subject_CN=mx.tait.net.nz, issuer_CN=Nick's Domain CA, fingerprint=FD:88:18:3D:9D:33:4C:0B:B8:F9:E8:64:4B:23:D6:05:F1:DB:8D:21, pkey_fingerprint=03:6B:E4:D3:73:82:D5:B4:EB:98:96:BB:56:77:A2:48:C2:73:A0:03
posttls-finger: Untrusted TLS connection established to mx.dmz.tait.net.nz[114.23.142.178]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
posttls-finger: > EHLO focal.lxd
posttls-finger: < 250-mx.tait.net.nz
posttls-finger: < 250-PIPELINING
posttls-finger: < 250-SIZE 20480000
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250-8BITMIME
posttls-finger: < 250-SMTPUTF8
posttls-finger: < 250 CHUNKING
posttls-finger: > QUIT
posttls-finger: < 221 2.0.0 Bye
root@focal:~#

It's ok.

[Miriam España Acebal (mirespace)]

Doing verification for Hirsute:

root@hirsute:/home/ubuntu# apt install postfix/hirsute-proposed
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Selected version '3.5.6-1ubuntu0.2' (Ubuntu:21.04/hirsute-proposed [amd64]) for 'postfix'
[...]
Creating /etc/postfix/dynamicmaps.cf
changing /etc/mailname to hirsute.lxd
[...]
Created symlink /etc/systemd/system/multi-user.target.wants/postfix.service → /lib/systemd/system/postfix.service.
[...]

root@hirsute:/home/ubuntu#
root@hirsute:/home/ubuntu# posttls-finger mx.dmz.tait.net.nz
posttls-finger: Connected to mx.dmz.tait.net.nz[114.23.142.178]:25
posttls-finger: < 220 mx.tait.net.nz ESMTP Postfix (Ubuntu)
posttls-finger: > EHLO hirsute.lxd
posttls-finger: < 250-mx.tait.net.nz
posttls-finger: < 250-PIPELINING
posttls-finger: < 250-SIZE 20480000
posttls-finger: < 250-STARTTLS
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250-8BITMIME
posttls-finger: < 250-SMTPUTF8
posttls-finger: < 250 CHUNKING
posttls-finger: > STARTTLS
posttls-finger: < 220 2.0.0 Ready to start TLS
posttls-finger: mx.dmz.tait.net.nz[114.23.142.178]:25: subjectAltName: mx.tait.net.nz
posttls-finger: mx.dmz.tait.net.nz[114.23.142.178]:25 CommonName mx.tait.net.nz
posttls-finger: certificate verification failed for mx.dmz.tait.net.nz[114.23.142.178]:25: untrusted issuer /CN=Nick's Domain CA
posttls-finger: mx.dmz.tait.net.nz[114.23.142.178]:25: subject_CN=mx.tait.net.nz, issuer_CN=Nick's Domain CA, fingerprint=FD:88:18:3D:9D:33:4C:0B:B8:F9:E8:64:4B:23:D6:05:F1:DB:8D:21, pkey_fingerprint=03:6B:E4:D3:73:82:D5:B4:EB:98:96:BB:56:77:A2:48:C2:73:A0:03
posttls-finger: Untrusted TLS connection established to mx.dmz.tait.net.nz[114.23.142.178]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
posttls-finger: > EHLO hirsute.lxd
posttls-finger: < 250-mx.tait.net.nz
posttls-finger: < 250-PIPELINING
posttls-finger: < 250-SIZE 20480000
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250-8BITMIME
posttls-finger: < 250-SMTPUTF8
posttls-finger: < 250 CHUNKING
posttls-finger: > QUIT
posttls-finger: < 221 2.0.0 Bye
root@hirsute:/home/ubuntu#

It's OK.

[Nick Tait (nick.t)]

Thanks everyone for fixing this issue.
Nick.

[Launchpad Janitor (janitor)]

This bug was fixed in the package postfix - 3.5.6-1ubuntu0.2

---------------
postfix (3.5.6-1ubuntu0.2) hirsute; urgency=medium

  * d/rules: Removed LDFLAG -Bsymbolic-functions (LP: #1885403).

 -- Miriam España Acebal <email address hidden> Tue, 07 Sep 2021 11:36:44 +0200

[Brian Murray (brian-murray)]

The verification of the Stable Release Update for postfix has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package postfix - 3.4.13-0ubuntu1.2

---------------
postfix (3.4.13-0ubuntu1.2) focal; urgency=medium

  * d/rules: Removed LDFLAG -Bsymbolic-functions (LP: #1885403).

 -- Miriam España Acebal <email address hidden> Tue, 07 Sep 2021 08:58:01 +0200