Re: [clamav-users] Database updated over unencrypted connection?

2019-03-20 Thread Paul Kosinski via clamav-users
My comments were mainly concerning CVD *validation*, not HTTPS. Debian updates (for example) are delivered via plain HTTP, but they are validated using standard GPG tools. Firefox (ESR) updates are handled similarly (up to SHA512 hash, validated using GPG). I have more confidence in standard GPG

Re: [clamav-users] Database updated over unencrypted connection?

2019-03-20 Thread Al Varnell via clamav-users
I suspect we all read your concerns, but I have a problem understanding how that translates into defining a true vulnerability and the resultant level of severity. Assuming someone goes to all the trouble of figuring out what the hard coded public key embedded in ClamAV is, signs a fake .cvd

Re: [clamav-users] Slow reload

2019-03-20 Thread Arnaud Jacques
Hello Bowie, I did a check on the SecuriteInfo signatures.  I grepped my clamd logs for hits on SecuriteInfo signatures and then matched them to the file they came from. #1 was spam_marketing.ndb with 110 hits #2 was javascript.ndb with 10 hits And that was it.  securiteinfo.hdb,

Re: [clamav-users] freshclam -V output

2019-03-20 Thread Sean Clark via clamav-users
Arnaud, I now understand that we do not run the daemon. We update and scan from cron. I stumbled on a work around I *think* $ sigtool --version ClamAV 0.99.4/25394/Wed Mar 20 07:52:02 2019 VS $freshclam -V ClamAV 0.99.4 Thanks, Sean Clark <> Sr Network Engineer “An ounce of prevention is

Re: [clamav-users] Slow reload

2019-03-20 Thread Micah Snyder (micasnyd) via clamav-users
I think Alessandro was suggesting how it could work, not how it does work. Clamd doesn't work that way at present. It has been a feature request for a very long time, one that I hope we can address sometime soon, but I don't know when. Micah Micah Snyder ClamAV Development Talos Cisco

Re: [clamav-users] Slow reload

2019-03-20 Thread Steve Basford
On 2019-03-19 14:35, Bowie Bailey wrote: I do have a bunch of third party signatures installed from Sanesecurity and SecuriteInfo.  Is there a way to get timing information on which signature files are taking the longest to load?  Or is this mainly a function of file size? Here's a quick

Re: [clamav-users] Slow reload

2019-03-20 Thread Joel Esler (jesler) via clamav-users
All these times, I would imagine, would be based on the amount of CPU and RAM, even disk read speed, available to the machine loading. So these times are relative. Sent from my  iPhone > On Mar 20, 2019, at 07:48, Steve Basford > wrote: > >> On 2019-03-19 14:35, Bowie Bailey wrote: >>

Re: [clamav-users] Slow reload

2019-03-20 Thread Bowie Bailey
On 3/20/2019 2:57 AM, Arnaud Jacques wrote: > Hello Bowie, > >> I did a check on the SecuriteInfo signatures.  I grepped my clamd logs for >> hits on >> SecuriteInfo signatures and then matched them to the file they came from. >> >> #1 was spam_marketing.ndb with 110 hits >> #2 was javascript.ndb

Re: [clamav-users] Slow reload

2019-03-20 Thread Bowie Bailey
On 3/20/2019 8:42 AM, Alessandro Vesely via clamav-users wrote: > On Tue 19/Mar/2019 15:35:39 +0100 Bowie Bailey wrote: > >> ClamAV is taking about 2 1/2 minutes to reload its database on my mail >> server.  This >> seems to frequently happen when we are sending an email, so the Thunderbird >>

Re: [clamav-users] freshclam -V output

2019-03-20 Thread Sean Clark via clamav-users
Arnaud, Thank you so much for the direction! I am still having problems. I get a server working, but I try to apply what I thought was the fix to other servers and it does not work. I am missing the target  Could you/or someone help me with the failure scenarios? * the virus database is

Re: [clamav-users] Slow reload

2019-03-20 Thread Alessandro Vesely via clamav-users
On Tue 19/Mar/2019 15:35:39 +0100 Bowie Bailey wrote: > ClamAV is taking about 2 1/2 minutes to reload its database on my mail > server.  This > seems to frequently happen when we are sending an email, so the Thunderbird > will time > out on the send (although the message will frequently go

Re: [clamav-users] freshclam -V output

2019-03-20 Thread Arnaud Jacques
Sean, Here is the resolution I applied when I get this problem (on Debian OS) : # clamdscan -V ClamAV 0.100.0 (not information about loaded databases) vi /etc/systemd/system/clamav-daemon.socket.d/extend.conf [Socket] ListenStream=127.0.0.1:3310 (check if the 2 above lines are present)

Re: [clamav-users] Slow reload

2019-03-20 Thread Alessandro Vesely via clamav-users
On Wed 20/Mar/2019 14:53:28 +0100 Bowie Bailey wrote: > On 3/20/2019 8:42 AM, Alessandro Vesely via clamav-users wrote: >> On Tue 19/Mar/2019 15:35:39 +0100 Bowie Bailey wrote: >> >>> ClamAV is taking about 2 1/2 minutes to reload its database on my mail >>> server.  This >>> seems to frequently

Re: [clamav-users] Slow reload

2019-03-20 Thread Bowie Bailey
On 3/20/2019 2:57 PM, Alessandro Vesely via clamav-users wrote: > On Wed 20/Mar/2019 14:53:28 +0100 Bowie Bailey wrote: > >> On 3/20/2019 8:42 AM, Alessandro Vesely via clamav-users wrote: >>> On Tue 19/Mar/2019 15:35:39 +0100 Bowie Bailey wrote: >>> ClamAV is taking about 2 1/2 minutes to

Re: [clamav-users] Slow reload

2019-03-20 Thread G.W. Haywood via clamav-users
Hi there, On Wed, 20 Mar 2019, Micah Snyder wrote: On 3/20/19, 10:04 AM, "clamav-users on behalf of Bowie Bailey" wrote: On 3/20/2019 8:42 AM, Alessandro Vesely via clamav-users wrote: On Tue 19/Mar/2019 15:35:39 +0100 Bowie Bailey wrote: ClamAV is taking about 2 1/2 minutes to reload its

Re: [clamav-users] Slow reload

2019-03-20 Thread Bowie Bailey
On 3/20/2019 3:53 PM, Bowie Bailey wrote: > On 3/20/2019 2:57 PM, Alessandro Vesely via clamav-users wrote: >> On Wed 20/Mar/2019 14:53:28 +0100 Bowie Bailey wrote: >> >>> On 3/20/2019 8:42 AM, Alessandro Vesely via clamav-users wrote: On Tue 19/Mar/2019 15:35:39 +0100 Bowie Bailey wrote:

Re: [clamav-users] Slow reload

2019-03-20 Thread J.R. via clamav-users
> The simplest way to achieve this right now would probably be to use > two servers for scanning, and arrange for them to update their DBs > at different times. A simple milter with a knowledge of the update > schedule could choose which scanner to use just by checking the time. > I imagine that