On 2014/06/26 11:39, Shawn Webb wrote: > On Thu, Jun 26, 2014 at 11:31 AM, Stuart Henderson < > stu-clamav-l...@spacehopper.org> wrote: > > > > One complication with this is that the prototype for cl_initialize_crypto() > > is only in libclamav/crypto.h which doesn't get installed..(and for HAVP > > which > > doesn't normally use openssl, it would need extra build scaffolding there > > to > > do this via openssl rather than cl_initialize_crypto). > > > > As far as external users go, the approach in Sebastian's diff (calling > > cl_initialize_crypto from cl_init) seems far simpler. > > The patch here will go out with our next release of ClamAV, which adds the > function prototypes to clamav.h: > https://github.com/vrtadmin/clamav-devel/commit/9363412bbb2378a29f7ae7208ccec475a0c476d8
Thanks. > I'll talk with the team on Monday about whether to call > cl_initialize_crypto from cl_init. I have a few concerns with it, which is > why I originally opted to keep the function separate. cl_initialize_crypto > calls the OpenSSL initialization functions. A third-party application which > consumes both libclamav and OpenSSL might have already called the OpenSSL > initialization routines. From what I've read (sorry, I don't remember the > actual links off-hand), OpenSSL doesn't like to have its initialization > routines called multiple times. If I call cl_initialize_crypto inside of > cl_init, there is a possibility of that happening. > > I'll discuss the problem and potential solutions with the team on Monday > and we'll have a solution in place by later that day. At the very least, > the patch linked to above will help. Hmm, good point, there is at least a problem if OpenSSL init is called from multiple threads. BTW, clamav_scan from c-icap_modules clamav_mod is affected by this too (whereas clamd_mod and squidclamav are not). _______________________________________________ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/support/ml
