Bug#1003982: postfix: /etc/ssl/certs/ca-certificates.crt not copied to chroot

[Thomas Fargeix]

Package: postfix
Version: 3.5.6-1+b1
Severity: normal

Dear Maintainer,

After a dist-upgrade from Buster to Bullseye, the configure-instance.sh
of Postfix
3.5 no longer copy /etc/ssl/certs/ca-certificates.crt to the chroot. The
previous
script from 3.4 used to copy it.

In the script, the files to copy are selected based on their .pem
extension:
find . -name '*.pem' -not -xtype l -print0
which is why this file is excluded.

I understand that several workarounds exist (such as using CApath
instead of CAfile)
and that Bookworm now has a way to copy extra files into the chroot
(#948321),
however it is a change that I did not see in the CHANGELOG from Buster
and may be
of interest for other, especially because ca-certificates.crt is a
standard source
of trust on Debian and not a custom file created by the system admin.

Would it be possible to copy the ca-certificates.crt file in addition to
the *.pem?

(In my specific case, ca-certificates.crt was used by tls_ca_cert_file
in a
ldap-based virtual map similar to #948321, I changed the value to a
specific .pem).

Thanks,
Thomas

-- System Information:
Debian Release: 11.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-10-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages postfix depends on:
ii adduser 3.118
ii cpio 2.13+dfsg-4
ii debconf [debconf-2.0] 1.5.77
ii dpkg 1.20.9
ii e2fsprogs 1.46.2-2
ii libc6 2.31-13+deb11u2
ii libdb5.3 5.3.28+dfsg1-0.8
ii libicu67 67.1-7
ii libnsl2 1.3.0-2
ii libsasl2-2 2.1.27+dfsg-2.1
ii libssl1.1 1.1.1k-1+deb11u1
ii lsb-base 11.1.0
ii netbase 6.3
ii ssl-cert 1.1.0+nmu1

Versions of packages postfix recommends:
ii ca-certificates 20210119
ii python3 3.9.2-3

Versions of packages postfix suggests:
ii bsd-mailx [mail-reader] 8.1.2-0.20180807cvs-2
ii libsasl2-modules 2.1.27+dfsg-2.1
pn postfix-cdb <none>
pn postfix-doc <none>
ii postfix-ldap 3.5.6-1+b1
pn postfix-lmdb <none>
pn postfix-mysql <none>
ii postfix-pcre 3.5.6-1+b1
pn postfix-pgsql <none>
pn postfix-sqlite <none>
pn procmail <none>
pn resolvconf <none>
pn ufw <none>

-- debconf information excluded

[Daniel Kahn Gillmor]

Control: affects 1003982 + sasl-xoauth2
Control: affects 1006888 + src:sasl-xoauth2

Over in https://bugs.debian.org/1003982, Thomas Fargeix wrote:
> On 2022-01-18 23:19, Scott Kitterman wrote:
>> According to postconf(5) it's not needed. It says, "These are loaded
>> into memory before the smtp(8) client enters the chroot jail". Why
>> do you need it in the chroot?
>
> Then there is a different behavior between smtp(d)_tls_CAfile and
> tls_ca_cert_file from the postfix-ldap module (and maybe other TLS
> options from other modules? I have not see other errors in my setup
> but LDAP is my only non-default one). I use LDAP map for aliases,
> with tls_ca_cert_file to verify the certificate of the LDAP server,
> and the CA file was not loaded in memory before entering the chroot:

Aside from postfix-ldap as a lookup module, SASL modules might also need
the files to be in the chroot.

For example, I'm preparing the sasl-xoauth2 module for debian (see
https://bugs.debian.org/1006888) and the upstream developer for that
package (Tarick Bedeir, in Cc here) has some hooks in his upstream .deb
packaging (that targets ubuntu), which trying to copy
/etc/ssl/certs/ca-certificates.crt into the chroot whenever
ca-certificates is updated:

https://github.com/tarickb/sasl-xoauth2/blob/master/scripts/update-ca-certificates.sh
https://github.com/tarickb/sasl-xoauth2/blob/master/debian/install
https://github.com/tarickb/sasl-xoauth2/blob/master/debian/sasl-xoauth2.postinst

This seems to be a not-particularly-robust approach, including at
least:

https://github.com/tarickb/sasl-xoauth2/issues/13
https://github.com/tarickb/sasl-xoauth2/issues/14

I don't plan to adopt this particular approach for the debian package,
for (at least) a few reasons:

- the sasl-xoauth2 package isn't even explicitly related to postfix --
that's the main upstream test case, but that doesn't mean that the
sasl-xoauth2 package should fiddle with the default postfix
installation.

- This approach won't work for a multi-tenant postfix installation; it
doesn't transfer the CA directory, etc.

- /usr/share/doc/postfix/README.Debian.gz section 2A suggests that
/etc/default/postfix is supposed be the right way to ensure that these
files are updated on postfix restart.

My current plan is to drop a short note in
/usr/share/doc/sasl-xoauth2/README.Debian that encourages use of
/etc/default/postfix for postfix admins who install this module.

But it would be pretty cool if postfix could automagically figure out
that it needs the ca-certificates file if this sasl module is
configured.

Scott, if you have any suggestions for how to approach this going
forward, i'd be happy to try to adopt those suggestions in the
sasl-xoauth2 packaging. Or, if you can see that i'm making some kind of
mistake here, i'd appreciate hearing about it too.

Please let me know what you think!

--dkg

PS i recognize that some packaging/system-integration decisions might be
different were i to try to backport sasl-xoauth2 for the existing
debian stable; but i'd prefer to sort out the cleanest and most
easily-maintainable packaging for debian unstable first, which is why
i'm raising this here. Whoever wants to do fiddly stuff for
backports can do so as necessary, but i don't want to have to
maintain that fiddliness in the packaging going forward if i can
avoid it.