On June 3, 2022 3:20:31 PM UTC, Viktor Dukhovni <postfix-us...@dukhovni.org>
wrote:
>On Fri, Jun 03, 2022 at 09:27:15AM -0400, Viktor Dukhovni wrote:
>> On Fri, Jun 03, 2022 at 11:09:08AM +0200, Matus UHLAR - fantomas wrote:
>>
>> > >Also can you "apt-get source postfix", and post a link to the tarball?
>> >
>> > this will unpack the tarball in local directory.
>> > I use standard debian packages, there's SASL related patch but it doesn't
>> > seem to affect this issue
>> >
>> > https://sources.debian.org/patches/postfix/3.5.6-1/
>> > https://sources.debian.org/patches/postfix/3.5.6-1/07_sasl_config.diff/
>>
>> The patch introduces a "SASL_CB_GETCONFPATH" callback, that indeed adds
>> "/etc/postfix/sasl" to the SASL config search path. This creates two
>> conflicting ways to set the location, with the patch likely overriding
>> "cyrus_sasl_config_path", and not providing any mechanisms to choose
>> alternative locations.
>>
>> This patch is IMHO obsolete and counterproductive, and should be
>> deprecated. Debian should take advantage of "cyrus_sasl_config_path",
>> possibly with a custom compile-time default, or else just set at
>> install, or at upgrade time (if not already set, and the previous
>> Postfix version contains the patch).
>
>I am also a bit puzzled about memory correctness in this patch. It
>allocates the callback data with the Postfix concatenate(), which uses
>the Postfix mymalloc(), but if/when SASL ever frees the value, the docs
>say it is freed with the C library free(), unless the application
>configures a different "free_t" function, which I believe is not the
>case.
>
>All in all, I'd like to see this patch go away.
I looked and the patch is unchanged from before I got involved in Postfix
maintenance in Debian in 2016. As you no doubt recall, Lamont had a low
threshold for adding distribution patches. I think given the existence of
cyrus_sasl_config_path this can definitely go away.
Scott K
