On Fri, Aug 12, 2016 at 2:51 PM, TR Shaw wrote:
> Actually there is always a probability that a detection will not occur if you
> beak apart at file into pieces This is due to the following
>
> 1) md5 signatures based upon any file type are applied on any file and match
> to the md4 hash of tha
On Thu, Aug 11, 2016 at 10:15 AM, G.W. Haywood
wrote:
> Hello once again,
>
> On Thu, 11 Aug 2016, sapientdust+cla...@gmail.com wrote:
>
>> I scan a 4.5 GB file in multiple instream calls, by scanning the first
>> 3 GB in one call, and then making a second instream call that provides
>> the first
Hello,
On Wed, Aug 10, 2016 at 10:11 AM, G.W. Haywood
wrote:
> Hello again,
>
> In August 2016, sapientdust+cla...@gmail.com wrote:
>
>> The specifics are not important to my question
>
>
> That's not what you said earlier. To be specific, you said:
>
>> >> In my case, the consequence factor is
On Tue, Aug 9, 2016 at 9:40 AM, G.W. Haywood wrote:
> Hi there,
>
> On Tue, 9 Aug 2016, sapientdust+cla...@gmail.com wrote:
> On Thu, Aug 4, 2016 at 7:14 PM, Al Varnell wrote:
>
>>> ... Risk = threat x vulnerability x consequence
>>
>>
>> I agree. In my case, the consequence factor is very large
On Thu, Aug 4, 2016 at 7:14 PM, Al Varnell wrote:
> ...
> With the ever increasing malware issues we face today, it’s important to
> consider this:
>
> Risk = threat x vulnerability x consequence
I agree. In my case, the consequence factor is very large, and I have
to scan even the large files s
I've recently run into the issue of clamd not being able to scan files
that are larger than a small number of GB, and I have seen the
warnings in `man clamd.conf` that say specified limits above 4GB are
ignored.
Could developers or other folks familiar with the clamd codebase
comment on the feasib
