I'm still using HAVP for HTTP scanning, and it seems to still work OK with the latest ClamAV (i.e., libclamav etc.).
I hope that ClamAV doesn't become incompatible in a way that can't be accommodated. (I had to change HAVP's init temporarily during to the openssl hiccup). Paul Kosinski On Tue, 21 Jul 2015 12:00:01 -0400 [email protected] wrote: > > ------------------------------ > > > > Message: 2 > > Date: Thu, 2 Jul 2015 12:55:54 +0300 > > From: Henrik K <[email protected]> > > To: [email protected] > > Subject: Re: [clamav-users] Streaming support in ClamD > > Message-ID: <[email protected]> > > Content-Type: text/plain; charset=us-ascii > > > > > > Let's say you have a zip file. How do you expect ClamAV to scan it > > packet by > > packet? Or any other data really. I think there are very few wild > > signatures in database that are allowed to match any position > > anywhere in a "file". Only reliable way is to scan a complete > > file, so it knows the length and can decode it properly etc. > > > > The now abandoned HAVP proxy scanner does many tricks (filesystem > > mandatory locking to "pseudo-stream" files into clamav, zip header > > prefetch etc) to achieve near realtime scanning for large files and > > reduce "user hanging" to a minimum. I guess this is what you are > > after, but ICAP can't achieve such trickery. _______________________________________________ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
