Re: [clamav-users] ClamAV Scan - Data Read vs Data Scanned
On 03/11/2020 16:00, Paul Kosinski via clamav-users wrote: "(don't you love C?)" I have never understood why the originators of C didn't give integers explicit widths in bits: their scheme made C code often non-portable. Because C is intended to be very, very close to the machine architecture, only a step or tow above assembler, or doing the bit-twiddling by hand. When I wrote code in the mid 1990s for the DEC Alpha, ints were 32 bits while longs were 64 (unlike "standard" C). This made Alpha C code not portable to lesser CPUs. On the other hand, when I wrote C on DOS for the IBM PC in the late 1980s, ints were only 8 bits! It took some time to figure out why my C-compliant code failed so badly. In spite of all that, having started programming before C was invented, I can safely say that C is better than its predecessors for software like ClamAV. Uh, not a good example, I've written C code that is still in use on everything from 80286s (yes, Virginia, there are people who keep them alive, not just because they're cheap, sometimes just because they *can*) to DEC Alphas and Power and SPARC64 and PA-RISC, it's just a matter of knowing what you are doing, and sticking to it... P.S. Good code these days tends to use typedefs defining things like int32, uint64 etc. A shame the original ClamAV coders didn't do that. And none of this has *anything* to do with the original problem - seeing 0 when the value is 0.01, or so. This is a display problem, not a storage problem. You could declare something as PIC(999.99) and you will still only see 0 if you told it to display two decimal places. Cheers, GaryB-) ___ clamav-users mailing list clamav-users@lists.clamav.net https://lists.clamav.net/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
[clamav-users] Clamd.exe -- excluding files when scanning
I'm not a big Windows fan, but it sounds like ClamAV regexes are rather unfriendly to Windows since they don't seem to have an "ignore case" option (unlike most other regex-using programs). Assuming that is the case (sic), you might try: ExcludePath "[Cc]:\\[Ww][Ii][Nn][Dd][Oo][Ww][Ss]" as a shorter way to exclude all possible spellings of "Windows". The same rather ugly approach should work in other situations where you want to ignore case in a ClamAV regex to accommodate Windows' filename interpretation (which it inherited from DOS). On Sat, 24 Oct 2020 01:44:06 +0100 (BST) "G.W. Haywood via clamav-users" wrote: > Hello again, > > On Fri, 23 Oct 2020, Marcy Rogers via clamav-users wrote: > > > ... > > I followed the instructions for installing Clamav for Windows and placed > > the clamd.conf file in the c:\program files\clamav. > > ... > > In the config file, you will see this. > > ... > > ExcludePath "C:\Windows" > > There are two potential issues there. more below. > > > ... > > SelfCheck 3600 > > > > This was set at 600 before I changed it to 3600 minutes. Clamd.exe is > > reading to do a selfcheck every 3600 minutes but it is not reading to > > excludepath "c:\windows" > > It's good to know that the selfcheck interval has indeed changed from > the default to what you have set in the config file. At least that > shows that you have had some effect on the daemon. I'd just like to > be sure that the config file that you think is having that effect is > actually the file that's doing that, and that you don't have another > file somewhere with the 3600 second self-check interval set but _not_ > the ExcludePath line. If you change the interval to something like > 1200 seconds and wait for twenty minutes you should be able to verify > that you're working with the right file. Alternatively you can give > the config file path explicitly on the command line to make sure. > > A couple of other things: > > 1. > > On Fri, 23 Oct 2020, Mark Fortescue wrote: > > > Have you tried C:\\Windows or C:/Windows. > > Mr. Fortescue makes good suggestions. The ExcludePath directive takes > as its argument a 'regular expression', not just a string of text. > Regular expressions are kinds of patterns which are _compared_ with a > string of text - in this case the regex will be compared with a path > name. It either matches (and so the path is excluded) or it doesn't > (so it isn't excluded). Think about the '*' character that's often > used when you want to list the files in a directory which all have > names beginning with the same few characters. A regex is like that > with bells on. This isn't the place to talk about regular expressions > (if you aren't familiar with them, search for tutorials about them) > but we do need to mention the backslash I'm afraid. In most regular > expression (regex) libraries, the backslash character is 'special'. > It does not behave literally in a string as ordinary characters do; it > escapes the following character, if that is another special character, > thus making the special character _not_ special. But if the following > character is _not_ a special character, the non-special character is > taken literally as if the backslash were not there. That means that > the regex > > c:\Windows > > actually matches > > c:Windows > > and if you want to have a literal backslash in a regex you generally > have to double it, as in Mr. Fortescue's first suggestion. > > Linux, MacOS etc. pathnames use the forward slash character as the > directory separator. Windows has a quirk. On Windows, the directory > separator in the pathnames is the backslash character. Sometimes to > get around this quirk on Windows, tools which use regexes will accept > a forward slash instead of a backslash for the directory separator, > avoiding the need to double backslashes everywhere which can be messy > if there are many directories in the path. > > 2. > > In the config file I notice that you have > > ExcludePath "C:\Windows" > > but you say it continues to scan "c:\windows". As I said I don't use > ClamAV on Windows so I don't know if clamd behaves differently there > from how it behaves on Linux etc., but on the operating systems that > I'm used to working with ClamAV tools are case sensitive. That means > that "C:\Windows" and "c:\windows" would be two different paths, and > excluding one would not exclude the other. You can have more than > one ExcludePath directive in the file so it won't hurt to try several > > ExcludePath "C:\\Windows" > ExcludePath "C:\\WINDOWS" > ExcludePath "C:\\windows" > ExcludePath "C:\Windows" > ExcludePath "C:\WINDOWS" > ExcludePath "C:\windows" > ExcludePath "C:/Windows" > ExcludePath "C:/WINDOWS" > ExcludePath "C:/windows" > > and see if that helps. I'm afraid that I'm guessing here. Also I > left out the nine lines with a lower case 'c' but I'd be surprised if > anything on Windows would treat the drive letter case sensitively.
Re: [clamav-users] ClamAV Scan - Data Read vs Data Scanned
"(don't you love C?)"
I have never understood why the originators of C didn't give integers
explicit widths in bits: their scheme made C code often non-portable.
When I wrote code in the mid 1990s for the DEC Alpha, ints were 32 bits
while longs were 64 (unlike "standard" C). This made Alpha C code not
portable to lesser CPUs. On the other hand, when I wrote C on DOS for
the IBM PC in the late 1980s, ints were only 8 bits! It took some time
to figure out why my C-compliant code failed so badly. In spite of all
that, having started programming before C was invented, I can safely
say that C is better than its predecessors for software like ClamAV.
P.S. Good code these days tends to use typedefs defining things like
int32, uint64 etc. A shame the original ClamAV coders didn't do that.
On Tue, 3 Nov 2020 01:53:33 +
"Micah Snyder (micasnyd)" wrote:
> I hadn't really looked at the code. You raise a good point.
>
> Changing it isn't super simple. The info.blocks variable is passed through
> cli_scandesc_callback() and scan_common() where it's placed into the scan
> context. When data is scanned, the amount scanned is divided by
> CL_COUNT_PRECISION (also found in clamav.h), which is what you multiply the
> number by to get the value in bytes. Provided that all downstream
> applications use CL_COUNT_PRECISION as clamscan does, we could shrink the
> count precision from 4k to something lower, but that would also decrease the
> max amount of data which could be scanned.
>
> If the variable were a uint64_t, that'd probably be fine... but it's an
> unsigned long int... aka maybe 4 bytes or maybe 8 bytes (don't you love C?).
> On systems where an unsigned long is 4 bytes, then that'd cap the scan limit
> at 4GB. Changing the variable to be an uint64_t would be "best", but it
> would be a non-backwards compatible change to the API which is very much not
> worth it.
>
> Sigh :-/
>
> > -Original Message-
> > From: clamav-users On Behalf Of
> > Paul Kosinski via clamav-users
> > Sent: Monday, November 2, 2020 5:23 PM
> > To: clamav-users@lists.clamav.net
> > Cc: Paul Kosinski
> > Subject: Re: [clamav-users] ClamAV Scan - Data Read vs Data Scanned
> >
> > Can this really be done? I was looking at the code referred to by G.W.
> > Haywood, and I see that it uses "info.blocks" and "info.rblocks".
> > Looking at the definitions in "clamav-0.103.0/clamscan/", I see the
> > following:
> >
> > struct s_info {
> > unsigned int sigs; /* number of signatures */
> > unsigned int dirs; /* number of scanned directories */
> > unsigned int files;/* number of scanned files */
> > unsigned int ifiles; /* number of infected files */
> > unsigned int errors; /* number of errors */
> > unsigned long int blocks; /* number of *scanned* 16kb blocks */
> > unsigned long int rblocks; /* number of *read* 16kb blocks */ };
> >
> > This suggests that the counts for "scanned" and "read" are not really byte
> > counts, and EICAR's 68 bytes would always be recorded as 0 (if normal
> > rounding rules are applied).
> >
> >
> >
> > On Mon, 2 Nov 2020 23:59:20 +
> > "Micah Snyder \(micasnyd\) via clamav-users"
> > wrote:
> >
> > > I agree. We already have some logic in freshclam to convert bytes to
> > > human
> > readable B / KiB / MiB / GiB format. It should be pretty much a copypaste
> > effort to improve the data scanned/read output.
> > >
> > > -Micah
> > >
> > > On 11/2/20, 9:47 AM, "clamav-users on behalf of G.W. Haywood via clamav-
> > >
> > users" > us...@lists.clamav.net> wrote:
> > >
> > > Hi there,
> > >
> > > On Mon, 2 Nov 2020, Paul Kosinski via clamav-users wrote:
> > >
> > > > ... I still think it is a bad message that should be fixed.
> > >
> > > +1
> > >
> > > If you want to try a very quick and dirty tweak to get more precise
> > > numbers, change the value of
> > >
> > > 1) CL_COUNT_PRECISION in .../libclamav/clamav.h from 4096 to 1
> > >
> > > 2) replace '1024' with '1' in four places in clamscan/clamscan.c
> > >
> > > 3) change 'MB' to 'Bytes' in two places in clamscan/clamscan.c and
> > >
> > > 4) rebuild.
> > >
> > >
> > > 8<--
> > > ~/clamav-0.103.0-rc2: $ grep -C3 -r CL_COUNT_PRECISION clamscan
> > libclamav | ...
> > > ...
> > > ...
> > > clamscan/clamscan.c:mb = info.blocks * (CL_COUNT_PRECISION /
> > 1024) / 1024.0;
> > > clamscan/clamscan.c:logg("Data scanned: %2.2lf MB\n", mb);
> > > clamscan/clamscan.c:rmb = info.rblocks * (CL_COUNT_PRECISION
> > > /
> > 1024) / 1024.0;
> > > clamscan/clamscan.c:logg("Data read: %2.2lf MB (ratio
> > > %.2f:1)\n",
> > rmb, info.rblocks ? (double)info.blocks / (double)info.rblocks : 0);
> > > ...
> > > ...
> > > libclamav/clamav.h:#define CL_COUNT_PRECISION
Re: [clamav-users] Errir parsing PNG files and 451_mail_server_temporarily_rejected_message
Thanks Pablo, Just took a look - it seems that image001.gif is missing the final byte, a value "0x3B" should be at the end of every GIF file. Interestingly firefox rendered it, though clam didn't like it and 010editor's GIF template also couldn't handle it. Perhaps this is the sort of issue that should be overlooked when validating the format? I wonder if this is a common occurrence. I haven't seen it in my test set yet, but I'm still collecting more files to test with. -Micah On 11/2/20, 5:58 PM, "clamav-users on behalf of Pablo Murillo" wrote: I try so send several mails to the list with gifs attached, but none arrived to the list I'm sending a link to one gif that everyday is rejected by ClamAV Link to gif file: http://pablomurillo.com.ar/image001.gif On 11/2/2020 9:02 PM, Micah Snyder (micasnyd) via clamav-users wrote: > We disabled the PNG parser because of bugs in the code that need to be fixed. I'm actively working on the PNG and GIF parsers, and have started testing with larger sample sets to try to make sure they're more robust. T > > he GIF parser seems fairly stable though I'm putting a lot of effort into making the code readable and adding debug output. If you have GIF samples that are incorrectly throwing parse errors, can you share them with me? It would be very helpful. > > -Micah > > On 11/2/20, 11:50 AM, "clamav-users on behalf of Pablo Murillo" wrote: > > Hi > > What happened with this ? > Now I'm seeing some errors in GIF files too > > On 10/21/2020 2:04 PM, Pablo Murillo wrote: > > Ajajaja > > I feel better ! > > ajajaja > > > > Check the mail I sent few minutes ago with more info and more files > > (defug, config, the rights pngs, and the real error) > > > > Sorry my english ! > > > > > > On 10/21/2020 1:48 PM, Micah Snyder (micasnyd) via clamav-users wrote: > >> Thanks Pablo I'll check it out right away! I hope you're feeling > >> better now :D > >> > >> Best, > >> Micah > >> > >> On 10/20/20, 1:10 PM, "clamav-users on behalf of Pablo Murillo" > >> >> i...@pablomurillo.com.ar> wrote: > >> > >> Hi Micah > >> > >> I was ready to send a new mail when yours arrived > >> I made a lot of test and when I activated the option LogClean to > >> yes on > >> clamd.conf I found that not all PNG generate the problem ! > >> I'm sending some PNGs attached inside a tar.gz > >> > >> Now, I feel me better, I thought that I was the problem :D > >> > >> Pablo Murillo > >> > >> On 10/20/2020 4:40 PM, Micah Snyder (micasnyd) via clamav-users > >> wrote: > >> > Hi all, > >> > > >> > It seems as though the new PNG graphics format/CVE checker > >> added in 0.103 is causing trouble for you and for some others. We > >> will disable it for now, which we can do with an update to the daily > >> database. > >> > > >> > Pablo, if you're allowed to share some of the PNG files with > >> me that caused issues for you, the samples will help us find the bug > >> in the PNG parser. > >> > > >> > Regards, > >> > Micah > >> > > >> > > >> > Micah Snyder > >> > ClamAV Development > >> > Talos > >> > Cisco Systems, Inc. > >> > > >> > > >> > > >> > On 10/19/20, 11:26 AM, "clamav-users on behalf of Pablo > >> Murillo" >> i...@pablomurillo.com.ar> wrote: > >> > > >> > Hi > >> > > >> > I started seeing the error [ > >> > 451_mail_server_temporarily_rejected_message ] on > >> maillog, and looking > >> > in the clamd.log I found a lot of lines like this [ > >> /*/*/*/*.png: Can't > >> > parse data ERROR ] > >> > I added on clamd.conf the next line > >> > > >> > ExcludePath ^\.png$ > >> > > >> > But clamd is still sending the error > >> > Is there a way to avoid this ? > >> > Any mail qith a PNG file is rejected by clamd > >> > > >> > My config > >> > FreeBSD 11.3-RELEASE-p13 > >> > qmail (with a lot ot patches) > >> > SpamDyke 5.0.1 > >> > ClamAV 0.103.0 > >> > >
Re: [clamav-users] Errir parsing PNG files and 451_mail_server_temporarily_rejected_message
I try so send several mails to the list with gifs attached, but none arrived to the list I'm sending a link to one gif that everyday is rejected by ClamAV Link to gif file: http://pablomurillo.com.ar/image001.gif On 11/2/2020 9:02 PM, Micah Snyder (micasnyd) via clamav-users wrote: We disabled the PNG parser because of bugs in the code that need to be fixed. I'm actively working on the PNG and GIF parsers, and have started testing with larger sample sets to try to make sure they're more robust. T he GIF parser seems fairly stable though I'm putting a lot of effort into making the code readable and adding debug output. If you have GIF samples that are incorrectly throwing parse errors, can you share them with me? It would be very helpful. -Micah On 11/2/20, 11:50 AM, "clamav-users on behalf of Pablo Murillo" wrote: Hi What happened with this ? Now I'm seeing some errors in GIF files too On 10/21/2020 2:04 PM, Pablo Murillo wrote: > Ajajaja > I feel better ! > ajajaja > > Check the mail I sent few minutes ago with more info and more files > (defug, config, the rights pngs, and the real error) > > Sorry my english ! > > > On 10/21/2020 1:48 PM, Micah Snyder (micasnyd) via clamav-users wrote: >> Thanks Pablo I'll check it out right away! I hope you're feeling >> better now :D >> >> Best, >> Micah >> >> On 10/20/20, 1:10 PM, "clamav-users on behalf of Pablo Murillo" >> > i...@pablomurillo.com.ar> wrote: >> >> Hi Micah >> >> I was ready to send a new mail when yours arrived >> I made a lot of test and when I activated the option LogClean to >> yes on >> clamd.conf I found that not all PNG generate the problem ! >> I'm sending some PNGs attached inside a tar.gz >> >> Now, I feel me better, I thought that I was the problem :D >> >> Pablo Murillo >> >> On 10/20/2020 4:40 PM, Micah Snyder (micasnyd) via clamav-users >> wrote: >> > Hi all, >> > >> > It seems as though the new PNG graphics format/CVE checker >> added in 0.103 is causing trouble for you and for some others. We >> will disable it for now, which we can do with an update to the daily >> database. >> > >> > Pablo, if you're allowed to share some of the PNG files with >> me that caused issues for you, the samples will help us find the bug >> in the PNG parser. >> > >> > Regards, >> > Micah >> > >> > >> > Micah Snyder >> > ClamAV Development >> > Talos >> > Cisco Systems, Inc. >> > >> > >> > >> > On 10/19/20, 11:26 AM, "clamav-users on behalf of Pablo >> Murillo" > i...@pablomurillo.com.ar> wrote: >> > >> > Hi >> > >> > I started seeing the error [ >> > 451_mail_server_temporarily_rejected_message ] on >> maillog, and looking >> > in the clamd.log I found a lot of lines like this [ >> /*/*/*/*.png: Can't >> > parse data ERROR ] >> > I added on clamd.conf the next line >> > >> > ExcludePath ^\.png$ >> > >> > But clamd is still sending the error >> > Is there a way to avoid this ? >> > Any mail qith a PNG file is rejected by clamd >> > >> > My config >> > FreeBSD 11.3-RELEASE-p13 >> > qmail (with a lot ot patches) >> > SpamDyke 5.0.1 >> > ClamAV 0.103.0 >> > >> > Thanks >> > >> > >> > -- >> > This email has been checked for viruses by AVG. >> > https://www.avg.com >> > >> > >> > ___ >> > >> > clamav-users mailing list >> > clamav-users@lists.clamav.net >> > https://lists.clamav.net/mailman/listinfo/clamav-users >> > >> > >> > Help us build a comprehensive ClamAV guide: >> > https://github.com/vrtadmin/clamav-faq >> > >> > http://www.clamav.net/contact.html#ml >> > >> > >> > ___ >> > >> > clamav-users mailing list >> > clamav-users@lists.clamav.net >> > https://lists.clamav.net/mailman/listinfo/clamav-users >> > >> > >> > Help us build a comprehensive ClamAV guide: >> > https://github.com/vrtadmin/clamav-faq >> > >> > http://www.clamav.net/contact.html#ml >>
Re: [clamav-users] ClamAV Scan - Data Read vs Data Scanned
I hadn't really looked at the code. You raise a good point.
Changing it isn't super simple. The info.blocks variable is passed through
cli_scandesc_callback() and scan_common() where it's placed into the scan
context. When data is scanned, the amount scanned is divided by
CL_COUNT_PRECISION (also found in clamav.h), which is what you multiply the
number by to get the value in bytes. Provided that all downstream applications
use CL_COUNT_PRECISION as clamscan does, we could shrink the count precision
from 4k to something lower, but that would also decrease the max amount of data
which could be scanned.
If the variable were a uint64_t, that'd probably be fine... but it's an
unsigned long int... aka maybe 4 bytes or maybe 8 bytes (don't you love C?).
On systems where an unsigned long is 4 bytes, then that'd cap the scan limit at
4GB. Changing the variable to be an uint64_t would be "best", but it would be
a non-backwards compatible change to the API which is very much not worth it.
Sigh :-/
> -Original Message-
> From: clamav-users On Behalf Of
> Paul Kosinski via clamav-users
> Sent: Monday, November 2, 2020 5:23 PM
> To: clamav-users@lists.clamav.net
> Cc: Paul Kosinski
> Subject: Re: [clamav-users] ClamAV Scan - Data Read vs Data Scanned
>
> Can this really be done? I was looking at the code referred to by G.W.
> Haywood, and I see that it uses "info.blocks" and "info.rblocks".
> Looking at the definitions in "clamav-0.103.0/clamscan/", I see the
> following:
>
> struct s_info {
> unsigned int sigs; /* number of signatures */
> unsigned int dirs; /* number of scanned directories */
> unsigned int files;/* number of scanned files */
> unsigned int ifiles; /* number of infected files */
> unsigned int errors; /* number of errors */
> unsigned long int blocks; /* number of *scanned* 16kb blocks */
> unsigned long int rblocks; /* number of *read* 16kb blocks */ };
>
> This suggests that the counts for "scanned" and "read" are not really byte
> counts, and EICAR's 68 bytes would always be recorded as 0 (if normal
> rounding rules are applied).
>
>
>
> On Mon, 2 Nov 2020 23:59:20 +
> "Micah Snyder \(micasnyd\) via clamav-users"
> wrote:
>
> > I agree. We already have some logic in freshclam to convert bytes to human
> readable B / KiB / MiB / GiB format. It should be pretty much a copypaste
> effort to improve the data scanned/read output.
> >
> > -Micah
> >
> > On 11/2/20, 9:47 AM, "clamav-users on behalf of G.W. Haywood via clamav-
> users" us...@lists.clamav.net> wrote:
> >
> > Hi there,
> >
> > On Mon, 2 Nov 2020, Paul Kosinski via clamav-users wrote:
> >
> > > ... I still think it is a bad message that should be fixed.
> >
> > +1
> >
> > If you want to try a very quick and dirty tweak to get more precise
> > numbers, change the value of
> >
> > 1) CL_COUNT_PRECISION in .../libclamav/clamav.h from 4096 to 1
> >
> > 2) replace '1024' with '1' in four places in clamscan/clamscan.c
> >
> > 3) change 'MB' to 'Bytes' in two places in clamscan/clamscan.c and
> >
> > 4) rebuild.
> >
> > 8<--
> > ~/clamav-0.103.0-rc2: $ grep -C3 -r CL_COUNT_PRECISION clamscan
> libclamav | ...
> > ...
> > ...
> > clamscan/clamscan.c:mb = info.blocks * (CL_COUNT_PRECISION /
> 1024) / 1024.0;
> > clamscan/clamscan.c:logg("Data scanned: %2.2lf MB\n", mb);
> > clamscan/clamscan.c:rmb = info.rblocks * (CL_COUNT_PRECISION /
> 1024) / 1024.0;
> > clamscan/clamscan.c:logg("Data read: %2.2lf MB (ratio
> > %.2f:1)\n",
> rmb, info.rblocks ? (double)info.blocks / (double)info.rblocks : 0);
> > ...
> > ...
> > libclamav/clamav.h:#define CL_COUNT_PRECISION 4096
> > ...
> > ...
> >
> > 8<
> > --
> >
> > This is untested, YMMV. Obviously, if you're skilled in the art, this
> > can be done better. Note that 'MB' should in any case be 'MiB' as the
> > values printed are the counts divided by 2^20 and not by 10^6.
> >
> > --
> >
> > 73,
> > Ged.
>
> ___
>
> clamav-users mailing list
> clamav-users@lists.clamav.net
> https://lists.clamav.net/mailman/listinfo/clamav-users
>
>
> Help us build a comprehensive ClamAV guide:
> https://github.com/vrtadmin/clamav-faq
>
> http://www.clamav.net/contact.html#ml
___
clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users
Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq
http://www.clamav.net/contact.html#ml
Re: [clamav-users] ClamAV Scan - Data Read vs Data Scanned
Can this really be done? I was looking at the code referred to by G.W.
Haywood, and I see that it uses "info.blocks" and "info.rblocks".
Looking at the definitions in "clamav-0.103.0/clamscan/", I see the
following:
struct s_info {
unsigned int sigs; /* number of signatures */
unsigned int dirs; /* number of scanned directories */
unsigned int files;/* number of scanned files */
unsigned int ifiles; /* number of infected files */
unsigned int errors; /* number of errors */
unsigned long int blocks; /* number of *scanned* 16kb blocks */
unsigned long int rblocks; /* number of *read* 16kb blocks */
};
This suggests that the counts for "scanned" and "read" are not really
byte counts, and EICAR's 68 bytes would always be recorded as 0 (if
normal rounding rules are applied).
On Mon, 2 Nov 2020 23:59:20 +
"Micah Snyder \(micasnyd\) via clamav-users"
wrote:
> I agree. We already have some logic in freshclam to convert bytes to human
> readable B / KiB / MiB / GiB format. It should be pretty much a copypaste
> effort to improve the data scanned/read output.
>
> -Micah
>
> On 11/2/20, 9:47 AM, "clamav-users on behalf of G.W. Haywood via
> clamav-users" clamav-users@lists.clamav.net> wrote:
>
> Hi there,
>
> On Mon, 2 Nov 2020, Paul Kosinski via clamav-users wrote:
>
> > ... I still think it is a bad message that should be fixed.
>
> +1
>
> If you want to try a very quick and dirty tweak to get more precise
> numbers, change the value of
>
> 1) CL_COUNT_PRECISION in .../libclamav/clamav.h from 4096 to 1
>
> 2) replace '1024' with '1' in four places in clamscan/clamscan.c
>
> 3) change 'MB' to 'Bytes' in two places in clamscan/clamscan.c and
>
> 4) rebuild.
>
> 8<--
> ~/clamav-0.103.0-rc2: $ grep -C3 -r CL_COUNT_PRECISION clamscan libclamav
> | ...
> ...
> ...
> clamscan/clamscan.c:mb = info.blocks * (CL_COUNT_PRECISION /
> 1024) / 1024.0;
> clamscan/clamscan.c:logg("Data scanned: %2.2lf MB\n", mb);
> clamscan/clamscan.c:rmb = info.rblocks * (CL_COUNT_PRECISION /
> 1024) / 1024.0;
> clamscan/clamscan.c:logg("Data read: %2.2lf MB (ratio %.2f:1)\n",
> rmb, info.rblocks ? (double)info.blocks / (double)info.rblocks : 0);
> ...
> ...
> libclamav/clamav.h:#define CL_COUNT_PRECISION 4096
> ...
> ...
> 8<--
>
> This is untested, YMMV. Obviously, if you're skilled in the art, this
> can be done better. Note that 'MB' should in any case be 'MiB' as the
> values printed are the counts divided by 2^20 and not by 10^6.
>
> --
>
> 73,
> Ged.
___
clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users
Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq
http://www.clamav.net/contact.html#ml
Re: [clamav-users] Errir parsing PNG files and 451_mail_server_temporarily_rejected_message
We disabled the PNG parser because of bugs in the code that need to be fixed. I'm actively working on the PNG and GIF parsers, and have started testing with larger sample sets to try to make sure they're more robust. T he GIF parser seems fairly stable though I'm putting a lot of effort into making the code readable and adding debug output. If you have GIF samples that are incorrectly throwing parse errors, can you share them with me? It would be very helpful. -Micah On 11/2/20, 11:50 AM, "clamav-users on behalf of Pablo Murillo" wrote: Hi What happened with this ? Now I'm seeing some errors in GIF files too On 10/21/2020 2:04 PM, Pablo Murillo wrote: > Ajajaja > I feel better ! > ajajaja > > Check the mail I sent few minutes ago with more info and more files > (defug, config, the rights pngs, and the real error) > > Sorry my english ! > > > On 10/21/2020 1:48 PM, Micah Snyder (micasnyd) via clamav-users wrote: >> Thanks Pablo I'll check it out right away! I hope you're feeling >> better now :D >> >> Best, >> Micah >> >> On 10/20/20, 1:10 PM, "clamav-users on behalf of Pablo Murillo" >> > i...@pablomurillo.com.ar> wrote: >> >> Hi Micah >> >> I was ready to send a new mail when yours arrived >> I made a lot of test and when I activated the option LogClean to >> yes on >> clamd.conf I found that not all PNG generate the problem ! >> I'm sending some PNGs attached inside a tar.gz >> >> Now, I feel me better, I thought that I was the problem :D >> >> Pablo Murillo >> >> On 10/20/2020 4:40 PM, Micah Snyder (micasnyd) via clamav-users >> wrote: >> > Hi all, >> > >> > It seems as though the new PNG graphics format/CVE checker >> added in 0.103 is causing trouble for you and for some others. We >> will disable it for now, which we can do with an update to the daily >> database. >> > >> > Pablo, if you're allowed to share some of the PNG files with >> me that caused issues for you, the samples will help us find the bug >> in the PNG parser. >> > >> > Regards, >> > Micah >> > >> > >> > Micah Snyder >> > ClamAV Development >> > Talos >> > Cisco Systems, Inc. >> > >> > >> > >> > On 10/19/20, 11:26 AM, "clamav-users on behalf of Pablo >> Murillo" > i...@pablomurillo.com.ar> wrote: >> > >> > Hi >> > >> > I started seeing the error [ >> > 451_mail_server_temporarily_rejected_message ] on >> maillog, and looking >> > in the clamd.log I found a lot of lines like this [ >> /*/*/*/*.png: Can't >> > parse data ERROR ] >> > I added on clamd.conf the next line >> > >> > ExcludePath ^\.png$ >> > >> > But clamd is still sending the error >> > Is there a way to avoid this ? >> > Any mail qith a PNG file is rejected by clamd >> > >> > My config >> > FreeBSD 11.3-RELEASE-p13 >> > qmail (with a lot ot patches) >> > SpamDyke 5.0.1 >> > ClamAV 0.103.0 >> > >> > Thanks >> > >> > >> > -- >> > This email has been checked for viruses by AVG. >> > https://www.avg.com >> > >> > >> > ___ >> > >> > clamav-users mailing list >> > clamav-users@lists.clamav.net >> > https://lists.clamav.net/mailman/listinfo/clamav-users >> > >> > >> > Help us build a comprehensive ClamAV guide: >> > https://github.com/vrtadmin/clamav-faq >> > >> > http://www.clamav.net/contact.html#ml >> > >> > >> > ___ >> > >> > clamav-users mailing list >> > clamav-users@lists.clamav.net >> > https://lists.clamav.net/mailman/listinfo/clamav-users >> > >> > >> > Help us build a comprehensive ClamAV guide: >> > https://github.com/vrtadmin/clamav-faq >> > >> > http://www.clamav.net/contact.html#ml >> >> >> -- >> This email has been checked for viruses by AVG. >> https://www.avg.com >> >> >> ___ >> >> clamav-users mailing list >> clamav-users@lists.clamav.net >> https://lists.clamav.net/mailman/listinfo/clamav-users >> >> >> Help us build a comprehensive ClamAV guide: >>
Re: [clamav-users] ClamAV Scan - Data Read vs Data Scanned
I agree. We already have some logic in freshclam to convert bytes to human
readable B / KiB / MiB / GiB format. It should be pretty much a copypaste
effort to improve the data scanned/read output.
-Micah
On 11/2/20, 9:47 AM, "clamav-users on behalf of G.W. Haywood via clamav-users"
wrote:
Hi there,
On Mon, 2 Nov 2020, Paul Kosinski via clamav-users wrote:
> ... I still think it is a bad message that should be fixed.
+1
If you want to try a very quick and dirty tweak to get more precise
numbers, change the value of
1) CL_COUNT_PRECISION in .../libclamav/clamav.h from 4096 to 1
2) replace '1024' with '1' in four places in clamscan/clamscan.c
3) change 'MB' to 'Bytes' in two places in clamscan/clamscan.c and
4) rebuild.
8<--
~/clamav-0.103.0-rc2: $ grep -C3 -r CL_COUNT_PRECISION clamscan libclamav |
...
...
...
clamscan/clamscan.c:mb = info.blocks * (CL_COUNT_PRECISION / 1024)
/ 1024.0;
clamscan/clamscan.c:logg("Data scanned: %2.2lf MB\n", mb);
clamscan/clamscan.c:rmb = info.rblocks * (CL_COUNT_PRECISION /
1024) / 1024.0;
clamscan/clamscan.c:logg("Data read: %2.2lf MB (ratio %.2f:1)\n",
rmb, info.rblocks ? (double)info.blocks / (double)info.rblocks : 0);
...
...
libclamav/clamav.h:#define CL_COUNT_PRECISION 4096
...
...
8<--
This is untested, YMMV. Obviously, if you're skilled in the art, this
can be done better. Note that 'MB' should in any case be 'MiB' as the
values printed are the counts divided by 2^20 and not by 10^6.
--
73,
Ged.
___
clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users
Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq
http://www.clamav.net/contact.html#ml
___
clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users
Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq
http://www.clamav.net/contact.html#ml
Re: [clamav-users] Errir parsing PNG files and 451_mail_server_temporarily_rejected_message
Hi What happened with this ? Now I'm seeing some errors in GIF files too On 10/21/2020 2:04 PM, Pablo Murillo wrote: Ajajaja I feel better ! ajajaja Check the mail I sent few minutes ago with more info and more files (defug, config, the rights pngs, and the real error) Sorry my english ! On 10/21/2020 1:48 PM, Micah Snyder (micasnyd) via clamav-users wrote: Thanks Pablo I'll check it out right away! I hope you're feeling better now :D Best, Micah On 10/20/20, 1:10 PM, "clamav-users on behalf of Pablo Murillo" i...@pablomurillo.com.ar> wrote: Hi Micah I was ready to send a new mail when yours arrived I made a lot of test and when I activated the option LogClean to yes on clamd.conf I found that not all PNG generate the problem ! I'm sending some PNGs attached inside a tar.gz Now, I feel me better, I thought that I was the problem :D Pablo Murillo On 10/20/2020 4:40 PM, Micah Snyder (micasnyd) via clamav-users wrote: > Hi all, > > It seems as though the new PNG graphics format/CVE checker added in 0.103 is causing trouble for you and for some others. We will disable it for now, which we can do with an update to the daily database. > > Pablo, if you're allowed to share some of the PNG files with me that caused issues for you, the samples will help us find the bug in the PNG parser. > > Regards, > Micah > > > Micah Snyder > ClamAV Development > Talos > Cisco Systems, Inc. > > > > On 10/19/20, 11:26 AM, "clamav-users on behalf of Pablo Murillo" i...@pablomurillo.com.ar> wrote: > > Hi > > I started seeing the error [ > 451_mail_server_temporarily_rejected_message ] on maillog, and looking > in the clamd.log I found a lot of lines like this [ /*/*/*/*.png: Can't > parse data ERROR ] > I added on clamd.conf the next line > > ExcludePath ^\.png$ > > But clamd is still sending the error > Is there a way to avoid this ? > Any mail qith a PNG file is rejected by clamd > > My config > FreeBSD 11.3-RELEASE-p13 > qmail (with a lot ot patches) > SpamDyke 5.0.1 > ClamAV 0.103.0 > > Thanks > > > -- > This email has been checked for viruses by AVG. > https://www.avg.com > > > ___ > > clamav-users mailing list > clamav-users@lists.clamav.net > https://lists.clamav.net/mailman/listinfo/clamav-users > > > Help us build a comprehensive ClamAV guide: > https://github.com/vrtadmin/clamav-faq > > http://www.clamav.net/contact.html#ml > > > ___ > > clamav-users mailing list > clamav-users@lists.clamav.net > https://lists.clamav.net/mailman/listinfo/clamav-users > > > Help us build a comprehensive ClamAV guide: > https://github.com/vrtadmin/clamav-faq > > http://www.clamav.net/contact.html#ml -- This email has been checked for viruses by AVG. https://www.avg.com ___ clamav-users mailing list clamav-users@lists.clamav.net https://lists.clamav.net/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml -- This email has been checked for viruses by AVG. https://www.avg.com ___ clamav-users mailing list clamav-users@lists.clamav.net https://lists.clamav.net/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
Re: [clamav-users] ClamAV Scan - Data Read vs Data Scanned
Hi there,
On Mon, 2 Nov 2020, Paul Kosinski via clamav-users wrote:
... I still think it is a bad message that should be fixed.
+1
If you want to try a very quick and dirty tweak to get more precise
numbers, change the value of
1) CL_COUNT_PRECISION in .../libclamav/clamav.h from 4096 to 1
2) replace '1024' with '1' in four places in clamscan/clamscan.c
3) change 'MB' to 'Bytes' in two places in clamscan/clamscan.c and
4) rebuild.
8<--
~/clamav-0.103.0-rc2: $ grep -C3 -r CL_COUNT_PRECISION clamscan libclamav | ...
...
...
clamscan/clamscan.c:mb = info.blocks * (CL_COUNT_PRECISION / 1024) /
1024.0;
clamscan/clamscan.c:logg("Data scanned: %2.2lf MB\n", mb);
clamscan/clamscan.c:rmb = info.rblocks * (CL_COUNT_PRECISION / 1024) /
1024.0;
clamscan/clamscan.c:logg("Data read: %2.2lf MB (ratio %.2f:1)\n", rmb,
info.rblocks ? (double)info.blocks / (double)info.rblocks : 0);
...
...
libclamav/clamav.h:#define CL_COUNT_PRECISION 4096
...
...
8<--
This is untested, YMMV. Obviously, if you're skilled in the art, this
can be done better. Note that 'MB' should in any case be 'MiB' as the
values printed are the counts divided by 2^20 and not by 10^6.
--
73,
Ged.
___
clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users
Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq
http://www.clamav.net/contact.html#ml
Re: [clamav-users] ClamAV Scan - Data Read vs Data Scanned
When I first saw this message, I quickly concluded it was a roundoff
behavior. But I still think it is a bad message that should be fixed.
First, most file managers that only display file sizes in "human
readable" form, still display a non-zero size for small files. Second,
it is not logically impossible (in principle) that a file be enumerated
while not having any data read or scanned.
Third, and perhaps most important, it can make users new to ClamAV
doubt its design, implementation or reliability.
On Sun, 1 Nov 2020 19:53:18 -0800
Al Varnell via clamav-users wrote:
> The eicar test file is 68 bytes long which is .68 MB which rounded to two
> significant digits is 0.00 MB both scanned and read.
>
> There are various limits, depending on file and archive types as to how much
> is read and/or scanned. In most cases they will be exactly the same.
>
> -Al-
>
> > On Nov 1, 2020, at 19:40, Ankur Sharma via clamav-users
> > wrote:
> >
> > Hi All,
> >
> > I tried to scan an eicar test file and got the following scan output:
> >
> > {'Scanning /tmp/bucket-file-upload/eicar_com.zip!ZIP': 'eicar.com
> >
