On Thu, Jun 26, 2014 at 11:31 AM, Stuart Henderson < stu-clamav-l...@spacehopper.org> wrote:
> On 2014/06/26 11:10, Shawn Webb wrote: > > On Thu, Jun 26, 2014 at 12:37 AM, Paul Kosinski <cla...@iment.com> > wrote: > > > > > I'm using HAVP (0.92) on Linux (openSuSE 13.1) as a virus scanning > > > filter for HTTP traffic. It worked perfectly with ClamAV 0.98.3 (and > > > many previous versions), but now it won't start at all with 0.98.4. > > > > > > HAVP uses libclamav.so to do the actual scanning (more efficient > > > than even the socket interface), so it starts by loading the various > > > CVD files. > > > > > > With 0.98.4, HAVP fails thus: > > > > > > 25/06/2014 20:30:54 === Starting HAVP Version: 0.92 > > > 25/06/2014 20:30:54 Running as user: havp, group: havp > > > 25/06/2014 20:30:54 --- Initializing ClamAV Library Scanner > > > 25/06/2014 20:30:54 ClamAV: Using database directory: > > > /opt/clamav/share/clamav > > > 25/06/2014 20:30:54 ClamAV: Could not load database: Can't allocate > > > memory > > > 25/06/2014 20:30:54 Error initializing ClamAV Library Scanner! > > > > > > While with 0.98.3, HAVP succeeds: > > > > > > 25/06/2014 20:32:48 === Starting HAVP Version: 0.92 > > > 25/06/2014 20:32:48 Running as user: havp, group: havp > > > 25/06/2014 20:32:48 --- Initializing ClamAV Library Scanner > > > 25/06/2014 20:32:48 ClamAV: Using database directory: > > > /opt/clamav/share/clamav > > > 25/06/2014 20:32:55 ClamAV: Loaded 3470096 signatures (engine 0.98.3) > > > 25/06/2014 20:32:56 ClamAV Library Scanner passed EICAR virus test > > > (Eicar-Test-Signature) > > > 25/06/2014 20:32:56 --- All scanners initialized > > > > > > A previous posting to this list implied that such (presumably bogus) > > > memory errors might be related to the switch to OpenSSL. In both > > > cases, I'm using OpenSSL 1.0.1h-1.60.1 (openSuSE's latest version), > > > and the clamd.conf file and HAVP binary are the same. > > > > > > Hey Paul, > > > > It looks like HAVP is calling into libclamav directly. That means that > HAVP > > will need to either initialize OpenSSL prior to calling the cl_init() > > function in libclamav, or it will need to call cl_initialize_crypto() > prior > > to calling cl_init(). We have an open bug on our end to track this issue > > (bugzilla bug 11037). Additionally, a bug report should be opened with > HAVP > > to document the issue on their end. I will be discussing with the team > soon > > potential solutions going forward. > > 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 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. Thanks, Shawn _______________________________________________ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/support/ml
