Open jameshartig opened 1 year ago
Having cl_cvdgetage()
return the age of the youngest file is intentional. The main
and bytecode
cvd's are rarely updated and that's fine. What is important is the age of the youngest to know if it is older than expected. The discussion on this design is here: https://github.com/Cisco-Talos/clamav/pull/832#issuecomment-1475089461
@micahsnyder sorry for the confusion, I meant return the youngest file. Right now the issue is that print_version hardcodes a single file but if you have a more frequently updated file or you don't even load daily.cvd then it's not accurate. Rather than hardcoding a specific file can it just use this new function?
My point is that if you want to alert on the youngest file being older than x, that isn't easy to do because the API only looks at a single file on disk and ignores the rest.
I'm sorry @jameshartig I misunderstood the issue.
I see now that you're suggesting that you're unhappy with the database version and time stamp returned by the clamd
VERSION
command. This is also the same information you get when you call --version
for freshclam
, clamscan
, clamsubmit
, sigtool
, and clamdscan
.
The print_version()
function is from common/misc.c
line 127, which will print something like this, if daily.cvd
or daily.cld
was found:
ClamAV _clamversion/_dailyversion/_dailytimestamp
If the daily database was not found, then it simply prints:
ClamAV _clamversion
It sound like you're asking for is for the VERSION
command to include the modified timestamp of the youngest signature file in the database directory. Is this correct?
Due to our process, daily.cvd will always be the youngest CVD that we provide. And the new cl_cvdgetage()
function only works for CVDs. It won't give you the modified timestamp of the youngest non-CVD / non-CLD signature file. And of course those files won't have a version/revision number either. Only CVD/CLD have a version number. So I don't think that cl_cvdgetage()
is a good candidate to suit your needs.
Oh actually it's the same logic but the VERSION
command response is from here: https://github.com/micahsnyder/clamav-micah/blob/0bc766f15b93883687904166aae3033467c9e9fe/clamd/session.c#L475-L491
@micahsnyder I understand. I appreciate the clarification. Would you be open to adding another command (via the socket API) that returns the latest modified timestamp? Right now we don't have any way via the API of monitoring the state of any other file besides the daily file. Does that make sense?
Would you be open to adding another command (via the socket API) that returns the latest modified timestamp? Right now we don't have any way via the API of monitoring the state of any other file besides the daily file. Does that make sense?
Yes I'm open to that. It sounds like the best option to me.
Describe the bug
If you use other files rather than daily.cvd or if there are older files than daily.cvd you can't detect that with a version check via the API.
There was a new
cl_cvdgetage
that's should be used instead to get the age of the oldest file.How to reproduce the problem
Observe cvd directory and call
VERSION
from the API. Observe only the daily.cvd date matches.Attachments
If applicable, add screenshots to help explain your problem.
If the issue is reproducible only when scanning a specific file, attach it to the ticket.