[Clamav-devel] New 0.95 API concerns
Gentlemen,
I have a couple of concerns about the new libclamav API introduced in
0.95 (rc1). I understand the reason to remove cl_limits structure, but I
think that the way it was done is, hmm, suboptimal.
cl_engine_set() and cl_engine_get() accessors have void* for the
argument, which may point to different type of variables: uint32, uint64
or char. The type of expected argument is dependent on the value of
cl_engine_field, and there is no type check of any kind, i.e. nothing
that prevents passing of e.g. a char pointer where in32 pointer was
expected. If, by chance, the types of arguments change in a future
release, the user program will recompile cleanly, and the change won't
be noticed. It's actually worse than it was when cl_limits was exposed:
when you assigned a value to a field of cl_limits structure, at least
basic type checking (and/or automatic conversion) was performed.
To mitigate this problem (if you *really* want to get rid of cl_limits
structure exposed to the user), you might introduce separate pairs of
accessor functions for different types of arguments, e.g.:
cl_engine_{get|set}_size(...,uint64_t *val)
cl_engine_{get|set}_int(...,uint32_t *val)
cl_engine_{get|set}_str(...,char *val)
This way, there will be no chance to pass the argument of wrong type.
And here we are coming to my second concern. By requiring the the user
to use bit-size-specific types (uint32_t, uint64_t), you force them to
deploy all the dark magic of having these types defined portably on
different systems, and to essentially duplicate the logic implemented in
cltypes.h. I believe that there is no good reason for that. While there
may be necessary to have bit-size-specific types *inside* clamav, having
them leaking through the API is not justified, in my opinion. I think
that it would be cleaner to use more common types in the API, like this:
cl_engine_{get|set}_size(...,off_t *val)
cl_engine_{get|set}_int(...,int *val)
cl_engine_{get|set}_str(...,char *val)
And a final note: I think it's worth mentioning in the documentation
what is the relation between options passed to cl_init() and options
passed to scanning functions. If they are different, maybe it's better
to name them differently, like init_options and scan_options.
Thanks for consideration,
Regards,
Eugene
signature.asc
Description: OpenPGP digital signature
___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
[Clamav-devel] New ClamAV Milter + Patch
Hi, I have been looking at the RC1 for ClamAV. With the rewrite of the Milter it has removed one important (for us) feature. That is the ability to notify clients that there mail has been intercepted. As an ISP here in Luxembourg we stand liable if we intercept and remove mail without informing the client. Our current system informs the recipient about filtered Virus mail and delivers UCE tagged (or delivered to a Spam folder). I have had a look at the source to the new Milter and have seen that it has simplified the program and made it much simpler. This is great. I looked at the possibility for re-adding the notification possibility and have had initial success with only a small patch. The style of the patch, I believe, stays within the spirit of the re-write. Before doing any further development, I wanted to get an idea if this might make it into the upstream code or if something like this would end up being an in-house patch. Regards Chris ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: [Clamav-devel] New ClamAV Milter + Patch
Patch now on Bugzilla (sorry for the mess, not use to the submission process). Bug: 1448 Chris Chris Moules wrote: Hi, I have been looking at the RC1 for ClamAV. With the rewrite of the Milter it has removed one important (for us) feature. That is the ability to notify clients that there mail has been intercepted. As an ISP here in Luxembourg we stand liable if we intercept and remove mail without informing the client. Our current system informs the recipient about filtered Virus mail and delivers UCE tagged (or delivered to a Spam folder). I have had a look at the source to the new Milter and have seen that it has simplified the program and made it much simpler. This is great. I looked at the possibility for re-adding the notification possibility and have had initial success with only a small patch. The style of the patch, I believe, stays within the spirit of the re-write. Before doing any further development, I wanted to get an idea if this might make it into the upstream code or if something like this would end up being an in-house patch. Regards Chris ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
[Clamav-devel] Binhex and PDF decoders
Hi. I am compiling clamav on a platform that does not provide mmap (required by pdf and binhex decoders), so I wrote a small patch that adds support for those formats without use of mmap (for platforms that don't provide it). Anybody interested? The patch is in bug #1432. ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: [Clamav-devel] New ClamAV Milter + Patch
Chris Moules wrote: As an ISP here in Luxembourg we stand liable if we intercept and remove mail without informing the client. Our current system informs the recipient about filtered Virus mail and delivers UCE tagged (or delivered to a Spam folder). Hi Chris, I think the quarantine queue and the x-headers already offer quite a good base for postprocessing the infected messages and, standing the very peculiar needs of each mail server and deployment environment, I'm not very keen to add postprocessing functionalities to the milter unless these are extremely generic. Failing that, I'd rather leave the postprocessing entirely to the admin. I have had a look at the source to the new Milter and have seen that it has simplified the program and made it much simpler. This is great. I looked at the possibility for re-adding the notification possibility and have had initial success with only a small patch. The style of the patch, I believe, stays within the spirit of the re-write. Before doing any further development, I wanted to get an idea if this might make it into the upstream code or if something like this would end up being an in-house patch. The patch is indeed small but it's not really about notifications. In fact it destroys the malicious message replacing its content and subjects with some static lines (BTW, what if the mail carries let's say a mua-specific exploit in its headers?). Now I'm pretty sure this works good enough in your very case, but frankly I don't see such a feature of much interest for general use. OTOH, a generic notification system possibly together with blackholing (as in your case), 5xx'ing or tagging, would benefit much more users... Except the milter interface is not really designed with such things in mind, which re-introduces a series of issues like determining if the recipient is to be notified (e.g. local vs remote), assembling the message, forking, invoking sendmail, etc... But again, if you consider that the very same effect can be achieved with about 3 lines of code in a sitewide procmail recipe or in a cronned shell/perl mailq -qQ parser, you would probably agree that doing it in the milter is not the way to go. Cheers, -aCaB ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
