Thanks Frederik,
As far as I know, spamc is not considered an API but a client that
accepts messages using a specific protocol. We aren't changing the
protocol, just internal calls that implement the protocol. Can you
expand on this statement?
In my mind libspamc is an API that anyone willing to implement a spamc
client could use.
I can see your point here and I'm investigating this. See below.
Can you open a bug at https://issues.apache.org/SpamAssassin/?
In process, I'll post the bug # back.
Thanks. I've seen it. See below for the delay.
Also, do you have any emails or scenarios that test this race
condition because I don't know what you mean by out of tree user?
There's no chance that the NULL deref happens with spamc: it alwas passes
struct message from the stack.
It's just that a client using libspamc might crash using message_dump()
I'm currently asking the PMC if the SA project has ever advertised
spamc/d as an API. If we have, I want to tread lightly on changing
potentially externalized calls.
However, from everything I've found, it's simply a spamc/d client pair
and the protocol for spamd is publicized. Therefore, since we are not
changing the protocol and this is a good change, I would vote to
implement the patch and make it apparent in the Changelog should anyone
be compiling against libspamc.
Regards,
KAM
