headers
Alan Jones | 3 Oct 2005 03:51

Clam Roadmap Over all and Windows Versions?

I have only been following Clam for about 3 months now, I have been trying to dig around a little bit to learn
more as what I have seen so far has been impressive.

Most of my interest in in the Windows version, but I do have interest in other platforms also.

I was curious if the Clam AV developers have a road map of where they are wanting to go all the way to what
constitutes 1.0.

We are at .87 right now what is planned for the next release or so? ... and When?

Is there any specific Windows development in the near future?

I am not going to ask about a memory resident file access scanner. 

I would like to see the over all scanning speed greatly improved though.
I have watched as ClamWin will just sit for a long time on some files.  The slow speed of an over all system scan
even if one does not scan inside of archives seems like an area in need of great improvements.

Based on reading I know that virus removal is not a top priority, but I remember seeing some comments about
some removal features might be added at some point.  I could see macro removal from Word/Excel files as a
great benefit.  I know some people that just remove all macros if there is any indication of a problem.  Any
chance for that in the near future?

Just curious and wanted to see where the over all direction and Windows specific version were going.

thanks for the information

Alan

_______________________________________________
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bogusław Brandys | 3 Oct 2005 09:11
Picon
Favicon

Re: NT IFS filter driver


Tracy Camp wrote:
> 
> There where some threads back in April about a NT IFS filter driver,
> native win32 port of clamav and NT service code.  I couldn't find out
> where the various pieces might be posted, in particular the filter
> driver. I work on a IFS regularily and could insert some IFS filter
> testing/debugging in with my regular work, but am un-certain how to
> proceed in a useful manner here.
> 
> Thanks,
> 
> Tracy Camp

Probably  nobody is really working with that because it's complicated
for doing it alone and no serious team is still completed.If you have
IFS basic driver I could help with integration clamav engine with it ,
however it looks like need rewrite because clamav is strictly file based
not memory buffers (clamav is using a lot of temporary files) maybe it's
possible to rewrite cl_gentemp function to use memory mapped files.
IFS should postpone I/O operation during scan ,as I know it should be
done by resubmitting IRP from completion routine - quite mystery for me
because I'm  working with device drivers only from time to time but not
so frequently ;-D

P.S. I offer my little help if you are interested but please remember
that I'm now inactive due to extensive work (job issues)

Regards
Boguslaw Brandys
(Continue reading)

Permalink | Reply | 3 comments |
headers
Bogusław Brandys | 3 Oct 2005 09:15
Picon
Favicon

Re: Clam Roadmap Over all and Windows Versions?


Alan Jones wrote:
> I have only been following Clam for about 3 months now, I have been trying to dig around a little bit to learn
more as what I have seen so far has been impressive.
> 
> Most of my interest in in the Windows version, but I do have interest in other platforms also.
> 
> I was curious if the Clam AV developers have a road map of where they are wanting to go all the way to what
constitutes 1.0.
> 
> We are at .87 right now what is planned for the next release or so? ... and When?
> 
> Is there any specific Windows development in the near future?
> 
> I am not going to ask about a memory resident file access scanner. 
> 
> I would like to see the over all scanning speed greatly improved though.
> I have watched as ClamWin will just sit for a long time on some files.  The slow speed of an over all system scan
even if one does not scan inside of archives seems like an area in need of great improvements.
> 
> Based on reading I know that virus removal is not a top priority, but I remember seeing some comments about
some removal features might be added at some point.  I could see macro removal from Word/Excel files as a
> great benefit.  I know some people that just remove all macros if there is any indication of a problem.  Any
chance for that in the near future?
> 
> Just curious and wanted to see where the over all direction and Windows specific version were going.
> 
> 
> thanks for the information
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tracy Camp | 3 Oct 2005 16:58

Re: NT IFS filter driver

>
> Probably  nobody is really working with that because it's complicated
> for doing it alone and no serious team is still completed.If you have

I thought somebody (you?) had a start on a filter driver.  I'd be happy to 
start another one, but I've never contemplated writting a GPL'd driver for 
NT before so would rather have an example to expand upon (I presume we 
start with freeifs.h?).  I've always just used the IFS kit ;)

> IFS basic driver I could help with integration clamav engine with it ,
> however it looks like need rewrite because clamav is strictly file based
> not memory buffers (clamav is using a lot of temporary files) maybe it's
> possible to rewrite cl_gentemp function to use memory mapped files.

> IFS should postpone I/O operation during scan ,as I know it should be
> done by resubmitting IRP from completion routine - quite mystery for me
> because I'm  working with device drivers only from time to time but not
> so frequently ;-D

Yes this is a very common technique in IFS drivers.  The NT Insider has 
quite a number of articals about various details of postponing IRPs.

http://www.osronline.com/section.cfm?section=20

This is a free and very worthy publication BTW.

t.

>
> P.S. I offer my little help if you are interested but please remember
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bogusław Brandys | 3 Oct 2005 19:22
Picon
Favicon

Re: NT IFS filter driver


Tracy Camp wrote:
>>
>> Probably  nobody is really working with that because it's complicated
>> for doing it alone and no serious team is still completed.If you have
> 
> 
> I thought somebody (you?) had a start on a filter driver.  I'd be happy
> to start another one, but I've never contemplated writting a GPL'd
> driver for NT before so would rather have an example to expand upon (I
> presume we start with freeifs.h?).  I've always just used the IFS kit ;)

Ahh...thats the problem.GPL one should not use IFS kit , and need one
created from scratch. Besides IFS kit cost about 1000$ as I know :-(

>> IFS basic driver I could help with integration clamav engine with it ,
>> however it looks like need rewrite because clamav is strictly file based
>> not memory buffers (clamav is using a lot of temporary files) maybe it's
>> possible to rewrite cl_gentemp function to use memory mapped files.
> 
> 
>> IFS should postpone I/O operation during scan ,as I know it should be
>> done by resubmitting IRP from completion routine - quite mystery for me
>> because I'm  working with device drivers only from time to time but not
>> so frequently ;-D
> 
> 
> Yes this is a very common technique in IFS drivers.  The NT Insider has
> quite a number of articals about various details of postponing IRPs.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tracy Camp | 3 Oct 2005 19:44

Re: NT IFS filter driver

>>
>> I thought somebody (you?) had a start on a filter driver.  I'd be happy
>> to start another one, but I've never contemplated writting a GPL'd
>> driver for NT before so would rather have an example to expand upon (I
>> presume we start with freeifs.h?).  I've always just used the IFS kit ;)
>
> Ahh...thats the problem.GPL one should not use IFS kit , and need one
> created from scratch. Besides IFS kit cost about 1000$ as I know :-(

Starting with longhorn the IFS Kit is just part of the DDK, which is sorta 
free-as-in-beer, but not GPL compliant by any means.  So to create a GPL'd 
driver you would need a free set of IFS headers, which freeifs.h mostly 
is, and may have enough in it to build a filter driver, may not, but the 
information to do so is in the public domain so one could be constructed. 
IANAL so I've no idea if the idea of the GPL violates the NT license or 
the NT license violates the GPL when you load the driver since some 
run-time linking certainly occurs ;)

Personally I'm okay with the idea of a 'non-GPL-free' as in 'public 
domain' IFS driver that GPL'd clamav and some GPL'd service code happens 
to communicate with.  But then again, one wouldn't want to step on toes in 
either direction (Microsoft or ClamAV developers).  I think in this 
senario using the official IFS kit is no problem, and as I said, its just 
part of the longhorn DDK now.

>>
>> Yes this is a very common technique in IFS drivers.  The NT Insider has
>> quite a number of articals about various details of postponing IRPs.
>>
>> http://www.osronline.com/section.cfm?section=20
(Continue reading)

Permalink | Reply | 0 comments |
headers
Blair Campbell | 4 Oct 2005 08:11
Picon

Re: Clamscan ported to DJGPP

Here I have a patch for the clamav CVS that allows compiliation of
libclamav and clamscan on DJGPP.  Note that in addition to the patch,
the ./configure script needs to also #define lstat stat and #define
d_ino d_namlen for DJGPP.

diff -ur clamav-devel.orig/clamscan/treewalk.c clamav/clamscan/treewalk.c
--- clamav-devel.orig/clamscan/treewalk.c       2005-08-03
07:31:22.000000000 +0000
+++ clamav/clamscan/treewalk.c  2005-08-31 12:27:34.000000000 +0000
 <at>  <at>  -106,7 +106,11  <at>  <at> 

                    /* stat the file */
                    if(lstat(fname, &statbuf) != -1) {
+                        #if defined(__DJGPP__)
+                        if(S_ISDIR(statbuf.st_mode) && recursion) {
+                        #else
                        if(S_ISDIR(statbuf.st_mode) &&
(S_ISLNK(statbuf.st_mode) && recursion) {
+                        #endif
                            if(treewalk(fname, root, user, opt,
limits, options, depth) == 1)
                                scanret++;
                        } else {
 <at>  <at>  -161,7 +165,11  <at>  <at> 

                        /* stat the file */
                        if(lstat(fname, &statbuf) != -1) {
+                            #if defined(__DJGPP__)
+                            if(S_ISDIR(statbuf.st_mode)) {
+                            #else
(Continue reading)

Permalink | Reply | 4 comments |
headers
Nigel Horne | 4 Oct 2005 10:22
Picon
Gravatar

Re: Clamscan ported to DJGPP

On Tue, 2005-10-04 at 07:11, Blair Campbell wrote:
> Here I have a patch for the clamav CVS that allows compiliation of
> libclamav and clamscan on DJGPP.  Note that in addition to the patch,
> the ./configure script needs to also #define lstat stat and #define
> d_ino d_namlen for DJGPP.

> mbox.c:
>  #if    C_SOLARIS && __GNUC__
>  #undef WITH_CURL
> +#elif defined(__DJGPP__)
> +#undef  WITH_CURL
>  #endif

Not needed - just specify --without-curl to configure. The Solaris way
is specific to that platform and is not a generic pointer for other
systems, which is they way you seem to have treated it.

Mind you, if
curl isn't supported on DJGPP, how come configure doesn't notice that.
You would be better to supply a patch to that, since putting operating
system specific mods to code isn't likely to be looked on favourably
unless it is absolutely necessary and no other workaround works. The
configure program is the place for OS specific code.

-Nigel

_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
(Continue reading)

Permalink | Reply | 3 comments |
headers
Blair Campbell | 4 Oct 2005 17:28
Picon

Re: Clamscan ported to DJGPP

> Mind you, if
> curl isn't supported on DJGPP, how come configure doesn't notice that.

CURL is supported on DJGPP, and I don't know how to modify configure
script.  However, adding CURL support in clamscan for DJGPP is bloat,
since DJGPP can only statically link binaries and linking in CURL and
WATT32 (the sockets library) would dramatically increase the size of
the binary (currently around 500kb).
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Permalink | Reply | 0 comments |
headers
Blair Campbell | 4 Oct 2005 21:58
Picon

Re: Clamscan ported to DJGPP

> > Here I have a patch for the clamav CVS that allows compiliation of
> > libclamav and clamscan on DJGPP.  Note that in addition to the patch,
> > the ./configure script needs to also #define lstat stat and #define
> > d_ino d_namlen for DJGPP.
>
> > mbox.c:
> >  #if    C_SOLARIS && __GNUC__
> >  #undef WITH_CURL
> > +#elif defined(__DJGPP__)
> > +#undef  WITH_CURL
> >  #endif
>
> Not needed - just specify --without-curl to configure. The Solaris way
> is specific to that platform and is not a generic pointer for other
> systems, which is they way you seem to have treated it.

Would it be possible to get the rest of the patch merged and for
someone who is experienced in editing configure scripts to add the
neccessary defines to modify the configure script?  (#define d_ino
d_namlen #define lstat stat)
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Permalink | Reply | 1 comment |

Gmane