Re: [Clamav-devel] Making the shared directory a convenience library
On Mon, Aug 24, 2009 at 01:06:10PM +0300, Török Edwin said:
> On 2009-08-23 03:24, Stephen Gran wrote:
> > Hi all,
> >
> > This patch makes the shared/ subdirectory build a convenience library.
>
> Hi Stephen,
>
> Did you git add shared/Makefile.am? I don't see it in your patch.
Arg, I must not have. Sorry about that. It boiled down to a very
simplistic:
noinst_LTLIBRARIES= libshared.la
libshared_la_SOURCES =
LIBS = $(top_sourcedir)/libclamav/libclamav.la
> > This means that on builds, each object file is only built once, then
> > compiled into a static, partially linked object file. This has obvious
> > advantages for the build time, as you only build these files once. It
> > also has advantages for the maintenance of various Makefile.am's, since
> > you just include the .la file and let libtool do the rest.
> >
> > Including inline since I think the list strips attachments.shar
>
> There are some ifdefs in shared/, CL_NOLIBCLAMAV, and CL_NOTHREADS, with
> your patch
> all the code would be built as if those would not be defined.
Right. I think what was underlying my rather simple minded approach was
a general feeling that some of the things being done for linker
optimization in clamav might be unnecessary.
The c library on all the POSIX platforms I'm familiar with provide stub
functions for the pthread functions that are weak symbols and can be
masked out by a thread library when linked to one, but can be effectively
no-ops otherwise. Consider this simple bit of c:
#include
#include
#include
int main (void) {
int x = 0;
pthread_mutex_t mut = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_lock(&mut);
x++;
pthread_mutex_unlock(&mut);
printf("%d\n", x);
exit(0);
}
It compiles, links and runs whether or not I add a thread library to
the link line. Are there POSIX platforms that this doesn't work on?
If (as I hope and suspect) not, can't the same principle be applied in
clamav - let the link line of the application being compiled determine
whether these pthread symbols are relocated to the thread library or
left as stubs in the c library? You don't need to link -lshared to
-lpthread (or -lthread, or ) - just link clamd to the thread library.
As you're effectively objcopying in symbols from libshared.a at that
point, the linker should deal with it correctly. No guarantees, of
course, I realize there are plenty of broken platforms out there.
> NOLIBCLAMAV is needed by clamav-milter, clamdscan, and clamdtop. I
> t is particularly important for clamdscan, we don't want clamdscan to
> link libclamav!
This is another one I'm not sure I understand the importance of. If
there are no symbols being used from libclamav, the relocation overhead
at startup is pretty minimal. I agree you may be able to shave a few
milliseconds off of startup time by not having a .NEEDED entry for
libclamav at all, but it hardly seems worth the effort. I may be
missing something obvious though, so feel free to correct me.
> I'm not particularly fond of the way NOLIBCLAMAV is handled, maybe it
> would be better to split mis.c into two files, and have
> 2 shared.la files built: shared_nolibclamav.la, shared_libclamav.la, and
> have clamdscan link only shared_nolibclamav.la.
>
> Not sure what should be done about NOTHREADS, but I think currently
> these permutations are needed:
> shared_nolibclamav
> shared_libclamav
> shared_threads_libclamav
> shared_threads_nolibclamav
>
> Not all files in shared/ use those defines, so you may avoid rebuilding
> each with different CFLAGS.
That way seems to lie combinatorial madness. The current solution is
far better than that :)
Cheers,
--
--
| Stephen Gran | I don't like this official/unofficial |
| st...@lobefin.net | distinction. It sound, er, officious. |
| http://www.lobefin.net/~steve | -- Larry Wall in|
|| <199702221943.laa20...@wall.org>|
--
signature.asc
Description: Digital signature
___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
[Clamav-devel] Making the shared directory a convenience library
\ -$(top_srcdir)/shared/misc.c \ -$(top_srcdir)/shared/misc.h \ -$(top_srcdir)/shared/cdiff.c \ -$(top_srcdir)/shared/cdiff.h \ -$(top_srcdir)/shared/tar.c \ -$(top_srcdir)/shared/tar.h \ vba.c \ vba.h \ sigtool.c DEFS = @DEFS@ -DCL_NOTHREADS AM_CPPFLAGS = -I$(top_srcdir) -I$(top_srcdir)/shared -I$(top_srcdir)/libclamav -LIBS = $(top_builddir)/libclamav/libclamav.la @FRESHCLAM_LIBS@ @THREAD_LIBS@ +LIBS = $(top_builddir)/libclamav/libclamav.la $(top_builddir)/shared/libshared.la @FRESHCLAM_LIBS@ @THREAD_LIBS@ CLEANFILES=*.gcda *.gcno Cheers, -- ---------- | Stephen Gran | Do not underestimate the value of print | | st...@lobefin.net | statements for debugging. Don't have| | http://www.lobefin.net/~steve | aesthetic convulsions when using them, | || either. | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: [Clamav-devel] use system libtommath when present
On Fri, Feb 20, 2009 at 11:56:30AM +0200, Török Edwin said: > On 2009-02-20 02:12, Stephen Gran wrote: > > Hopefully this will be a useful patch. > > > > Cheers, > > > > [PATCH] Modify build system to conditionally use system install of > > libtommath - > > it will be used if it is installed, or if it is explicitly enabled in > > configure > > Signed-off-by: Stephen Gran > > > > > > Does this prefer the included tommath over the system one? This patch prefers the system one (since that's generally my preference :), but it's easy to reverse the order of the logic. I won't be able to look at the issue until late tonight or tomorrow sometime, but if you'd prefer it that way around, I'm happy to send a patch for that behavior. Cheers, -- -- | Stephen Gran | He's just a politician trying to save | | st...@lobefin.net | both his faces... | | http://www.lobefin.net/~steve | | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: [Clamav-devel] [fabio....@libero.it: [Pkg-clamav-devel] Bug#512776: License incompatibility with libgmp ("GPLv2 only" linking to "LGPLv3 or later")]
On Fri, Feb 20, 2009 at 11:52:17AM +0200, Török Edwin said: > On 2009-02-20 03:13, Stephen Gran wrote: > > Now that I've been doing some looking, I see that there is also a > > bundled -ltdl in the source tree. I'm not aware of any license issues > > with libtool (although as it's an FSF project, I wouldn't be surprised > > to see it move to v3 in the future). Is this just a convenience copy, > > or is because of a license problem I'm unaware of? > > > > If it's just a convenience copy, can we give it the same treatment, and > > preferentially use the system copy? It'll probably mean patching the > > version of the ltdl m4 that you have in favor of something that doesn't > > produce totally broken make targets when you try to get it to use the > > system libtool. > > > > Currently, if you pass --with-ltdl-dir=/usr/lib, it add -L/usr/lib as > > a preprequisite, and if you pass --with-ltdl-dir=/usr/lib/libltdl.la, > > configure goes off and looks for /usr/lib/libltdl.la/libltdl.la and > > doesn't find it and exits. > > > > It already picks the system ltdl, *IF* you have libltdl7-dev installed > (which is currently in experimental, waiting to be uploaded in sid). > It won't work with an older ltdl, and I don't think it would be wise to > downgrade libtool. Ah, that's all right then - I can just wait on that making it to unstable to develop against it. Cheers, -- -- | Stephen Gran | "I'd love to go out with you, but I'm | | st...@lobefin.net | taking punk totem pole carving."| | http://www.lobefin.net/~steve | | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: [Clamav-devel] [fabio....@libero.it: [Pkg-clamav-devel] Bug#512776: License incompatibility with libgmp ("GPLv2 only" linking to "LGPLv3 or later")]
On Sat, Jan 24, 2009 at 11:17:02AM +0100, Tomasz Kojm said: > On Sat, 24 Jan 2009 01:21:34 + > Stephen Gran wrote: > > > I've just received the bug report below via the Debian bug tracking > > system. There's obviously not a whole lot I can do about it myself, but > > I just thought I'd bring it to your attention. > > Yeah, we got this information as well: > > https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1366 Now that I've been doing some looking, I see that there is also a bundled -ltdl in the source tree. I'm not aware of any license issues with libtool (although as it's an FSF project, I wouldn't be surprised to see it move to v3 in the future). Is this just a convenience copy, or is because of a license problem I'm unaware of? If it's just a convenience copy, can we give it the same treatment, and preferentially use the system copy? It'll probably mean patching the version of the ltdl m4 that you have in favor of something that doesn't produce totally broken make targets when you try to get it to use the system libtool. Currently, if you pass --with-ltdl-dir=/usr/lib, it add -L/usr/lib as a preprequisite, and if you pass --with-ltdl-dir=/usr/lib/libltdl.la, configure goes off and looks for /usr/lib/libltdl.la/libltdl.la and doesn't find it and exits. Grrr. -- -- | Stephen Gran | Look before you leap. -- Samuel | | st...@lobefin.net | Butler | | http://www.lobefin.net/~steve | | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: [Clamav-devel] use system libtommath when present
On Fri, Feb 20, 2009 at 12:12:11AM +, Stephen Gran said: > Hopefully this will be a useful patch. And if you add this one, it even compiles with the bundled tommath. sorry about that - autotools after midnight is never a good idea. [PATCH] and fix up my various errors Signed-off-by: Stephen Gran --- configure.in |4 ++-- libclamav/Makefile.am |9 +++-- 2 files changed, 5 insertions(+), 8 deletions(-) diff --git a/configure.in b/configure.in index e400644..3a22ff9 100644 --- a/configure.in +++ b/configure.in @@ -511,12 +511,12 @@ if test "x$enable_system_tommath" = "xauto"; then AC_CHECK_HEADER([tommath.h],[have_tommath_h=yes],) fi -if test "x$have_tommath_h" = "xyes" || "x$enable_system_tommath" = "xyes"; then +if test "x$have_tommath_h" = "xyes" || test "x$enable_system_tommath" = "xyes"; then AC_DEFINE([USE_SYSTEM_TOMMATH], 1, [use system lintommath]) TOMMATH_LIBS="-ltommath" AC_SUBST([TOMMATH_LIBS]) fi -AM_CONDITIONAL([SYSTEM_TOMMATH], test "x$ac_cv_use_system_tommath" = "xyes") +AM_CONDITIONAL([SYSTEM_TOMMATH], [test "x$ac_cv_use_system_tommath" = "xyes"]) AC_ARG_ENABLE([zlib-vcheck], [ --disable-zlib-vcheck do not check for buggy zlib version ], diff --git a/libclamav/Makefile.am b/libclamav/Makefile.am index 931c852..73d836a 100644 --- a/libclamav/Makefile.am +++ b/libclamav/Makefile.am @@ -89,23 +89,20 @@ libclamav_internal_utils_la_SOURCES=str.c \ regex/regex2.h \ regex/utils.h -if SYSTEM_TOMMATH -else +lib_LTLIBRARIES += libclamavtommath.la libclamavtommath_la_SOURCES = \ bignum.c \ bignum.h \ bignum_class.h -lib_LTLIBRARIES += libclamavtommath.la libclamavtommath_la_LDFLAGS =-static libclamavtommath_la_CFLAGS= -fPIC -DPIC -endif libclamav_internal_utils_la_LDFLAGS=-static libclamav_internal_utils_la_CFLAGS= -fPIC -DPIC -libclamav_la_LIBADD = @LIBLTDL@ $(IFACELIBADD) lzma/liblzma.la libclamav_internal_utils.la @LIBCLAMAV_LIBS@ @THREAD_LIBS@ @TOMMATH_LIBS@ -libclamav_la_DEPENDENCIES = @LIBLTDL@ $(IFACEDEP) libclamav_internal_utils.la +libclamav_la_LIBADD = @LIBLTDL@ $(IFACELIBADD) lzma/liblzma.la libclamavtommath.la libclamav_internal_utils.la @LIBCLAMAV_LIBS@ @THREAD_LIBS@ @TOMMATH_LIBS@ +libclamav_la_DEPENDENCIES = @LIBLTDL@ $(IFACEDEP) libclamav_internal_utils.la libclamavtommath.la libclamav_la_LDFLAGS = @TH_SAFE@ -version-info @LIBCLAMAV_VERSION@ -no-undefined if VERSIONSCRIPT -- 1.6.0.6 -- -- | Stephen Gran | Beer -- it's not just for breakfast | | st...@lobefin.net | anymore.| | http://www.lobefin.net/~steve | | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
[Clamav-devel] use system libtommath when present
Hopefully this will be a useful patch. Cheers, [PATCH] Modify build system to conditionally use system install of libtommath - it will be used if it is installed, or if it is explicitly enabled in configure Signed-off-by: Stephen Gran --- configure.in | 13 + libclamav/Makefile.am| 19 ++- libclamav/bignum.c |6 ++ libclamav/bignum.h |6 ++ libclamav/bignum_class.h |6 ++ libclamav/dsig.c |4 libclamav/dsig.h |4 7 files changed, 53 insertions(+), 5 deletions(-) diff --git a/configure.in b/configure.in index 3454abf..e400644 100644 --- a/configure.in +++ b/configure.in @@ -505,6 +505,19 @@ fi AC_MSG_RESULT([$ZLIB_HOME]) ]) +AC_ARG_ENABLE(system_tommath, +[ --enable-system-tommath Enable use of system libtommath (default=auto)], enable_system_tommath=$enableval, enable_system_tommath="auto" ) +if test "x$enable_system_tommath" = "xauto"; then +AC_CHECK_HEADER([tommath.h],[have_tommath_h=yes],) +fi + +if test "x$have_tommath_h" = "xyes" || "x$enable_system_tommath" = "xyes"; then +AC_DEFINE([USE_SYSTEM_TOMMATH], 1, [use system lintommath]) +TOMMATH_LIBS="-ltommath" +AC_SUBST([TOMMATH_LIBS]) +fi +AM_CONDITIONAL([SYSTEM_TOMMATH], test "x$ac_cv_use_system_tommath" = "xyes") + AC_ARG_ENABLE([zlib-vcheck], [ --disable-zlib-vcheck do not check for buggy zlib version ], zlib_check=$enableval, zlib_check="yes") diff --git a/libclamav/Makefile.am b/libclamav/Makefile.am index dd85399..931c852 100644 --- a/libclamav/Makefile.am +++ b/libclamav/Makefile.am @@ -87,15 +87,24 @@ libclamav_internal_utils_la_SOURCES=str.c \ regex/cname.h \ regex/regex.h \ regex/regex2.h \ - regex/utils.h \ - bignum.c \ - bignum.h \ - bignum_class.h + regex/utils.h + +if SYSTEM_TOMMATH +else +libclamavtommath_la_SOURCES = \ + bignum.c \ + bignum.h \ + bignum_class.h + +lib_LTLIBRARIES += libclamavtommath.la +libclamavtommath_la_LDFLAGS =-static +libclamavtommath_la_CFLAGS= -fPIC -DPIC +endif libclamav_internal_utils_la_LDFLAGS=-static libclamav_internal_utils_la_CFLAGS= -fPIC -DPIC -libclamav_la_LIBADD = @LIBLTDL@ $(IFACELIBADD) lzma/liblzma.la libclamav_internal_utils.la @LIBCLAMAV_LIBS@ @THREAD_LIBS@ +libclamav_la_LIBADD = @LIBLTDL@ $(IFACELIBADD) lzma/liblzma.la libclamav_internal_utils.la @LIBCLAMAV_LIBS@ @THREAD_LIBS@ @TOMMATH_LIBS@ libclamav_la_DEPENDENCIES = @LIBLTDL@ $(IFACEDEP) libclamav_internal_utils.la libclamav_la_LDFLAGS = @TH_SAFE@ -version-info @LIBCLAMAV_VERSION@ -no-undefined diff --git a/libclamav/bignum.c b/libclamav/bignum.c index b46be20..7c60f1d 100644 --- a/libclamav/bignum.c +++ b/libclamav/bignum.c @@ -1,3 +1,8 @@ +#if HAVE_CONFIG_H +#include "clamav-config.h" +#endif + +#ifndef USE_SYSTEM_TOMMATH /* LibTomMath, multiple-precision integer library -- Tom St Denis * * LibTomMath is a library that provides multiple-precision @@ -9514,3 +9519,4 @@ int KARATSUBA_MUL_CUTOFF = 80, /* Min. number of digits before Karatsub /* EOF */ +#endif diff --git a/libclamav/bignum.h b/libclamav/bignum.h index f50ac6f..59ba109 100644 --- a/libclamav/bignum.h +++ b/libclamav/bignum.h @@ -1,3 +1,8 @@ +#if HAVE_CONFIG_H +#include "clamav-config.h" +#endif + +#ifndef USE_SYSTEM_TOMMATH /* LibTomMath, multiple-precision integer library -- Tom St Denis * * LibTomMath is a library that provides multiple-precision @@ -582,3 +587,4 @@ extern const char *mp_s_rmap; /* $Source: /cvs/libtom/libtommath/tommath.h,v $ */ /* $Revision: 1.8 $ */ /* $Date: 2006/03/31 14:18:44 $ */ +#endif diff --git a/libclamav/bignum_class.h b/libclamav/bignum_class.h index be38efc..858d980 100644 --- a/libclamav/bignum_class.h +++ b/libclamav/bignum_class.h @@ -1,3 +1,8 @@ +#if HAVE_CONFIG_H +#include "clamav-config.h" +#endif + +#ifndef USE_SYSTEM_TOMMATH /* LibTomMath, multiple-precision integer library -- Tom St Denis * * LibTomMath is a library that provides multiple-precision @@ -1004,3 +1009,4 @@ /* $Revision: 1.3 $ */ /* $Date: 2005/07/28 11:59:32 $ */ #endif +#endif diff --git a/libclamav/dsig.c b/libclamav/dsig.c index e1f9d46..a0bb048 100644 --- a/libclamav/dsig.c +++ b/libclamav/dsig.c @@ -31,7 +31,11 @@ #include &
Re: [Clamav-devel] [fabio....@libero.it: [Pkg-clamav-devel] Bug#512776: License incompatibility with libgmp ("GPLv2 only" linking to "LGPLv3 or later")]
On Mon, Jan 26, 2009 at 09:15:14PM +0100, Tomasz Kojm said: > On Mon, 26 Jan 2009 20:47:48 +0100 > Reini Urban wrote: > > > Stephen Gran schrieb: > > > If you guys don't have the copyright, or can't grant the excemption for > > > other reasons, distributors like myself will most likely have to build > > > without gmp going forward, which seem unfortunate. > > > > Well, we could link against gmp-4.2.1 which has still the old license. > > For cygwin we would have to create a gmp-compat package based on gmp-4.2.1 Distributors like Debian and Redhat generally don't keep old versions of libraries laying around, so it's not all that great a solution. > The problem has been fixed in SVN - we're now using LibTomMath (bundled with > ClamAV) instead of libgmp. Can we make it a configure option to use the system version of the library instead? (Debian currently ships 0.39, which appears to have been around a while and should be reasonably close to whatever version you're going to pick) I vastly prefer that in the general case; all the usual arguments about security support and memory footprint and etc. apply - I'll take it as read that we all know them :) If you're not interested in that work, or it seems difficult and you have better things to do, let me know and I'll have a look. Cheers, -- -- | Stephen Gran | You know, Callahan's is a peaceable | | st...@lobefin.net | bar, but if you ask that dog what his | | http://www.lobefin.net/~steve | favorite formatter is, and he says | || "roff! roff!", well, I'll just have | || to... | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: [Clamav-devel] [fabio....@libero.it: [Pkg-clamav-devel] Bug#512776: License incompatibility with libgmp ("GPLv2 only" linking to "LGPLv3 or later")]
On Sat, Jan 24, 2009 at 11:17:02AM +0100, Tomasz Kojm said: > On Sat, 24 Jan 2009 01:21:34 + > Stephen Gran wrote: > > > I've just received the bug report below via the Debian bug tracking > > system. There's obviously not a whole lot I can do about it myself, but > > I just thought I'd bring it to your attention. > > Yeah, we got this information as well: > > https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1366 As I understand the issue, the problem is that the GPLv2 does not allow for the extra restrictions imposed by the LGPLv3, and this is what make the two licenses incompatible (i.e., the problem is solely in clamav's court, not GMP's). So, I think that if the clamav team could make a public license excemption for this linking, the problems for distributors goes away. It would be great if it was in the licensing statement in the release, but failing that, a mail to the mailing list would probably be enough for me to convince our archive administrators that it's ok. This of course assumes that the clamav team holds all the copyright for the code that links GMP, which, given that the #include gmp.h is in the library, might be slightly difficult. If you guys don't have the copyright, or can't grant the excemption for other reasons, distributors like myself will most likely have to build without gmp going forward, which seem unfortunate. Cheers, -- ------ | Stephen Gran | Chess tonight. | | st...@lobefin.net | | | http://www.lobefin.net/~steve | | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: [Clamav-devel] [fabio....@libero.it: [Pkg-clamav-devel] Bug#512776: License incompatibility with libgmp ("GPLv2 only" linking to "LGPLv3 or later")]
On Sat, Jan 24, 2009 at 01:21:34AM +, Stephen Gran said: > I've just received the bug report below via the Debian bug tracking > system. There's obviously not a whole lot I can do about it myself, but > I just thought I'd bring it to your attention. Oh damn. I forgot how the list strips attachments. Well, it's viewable here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=512776 Sorry about that. -- ------ | Stephen Gran | If you don't have a nasty obituary you | | st...@lobefin.net | probably didn't matter. -- Freeman| | http://www.lobefin.net/~steve | Dyson | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
[Clamav-devel] [fabio....@libero.it: [Pkg-clamav-devel] Bug#512776: License incompatibility with libgmp ("GPLv2 only" linking to "LGPLv3 or later")]
I've just received the bug report below via the Debian bug tracking system. There's obviously not a whole lot I can do about it myself, but I just thought I'd bring it to your attention. Cheers, -- ---------- | Stephen Gran | Your job is being a professor and | | st...@lobefin.net | researcher: That's one hell of a good | | http://www.lobefin.net/~steve | excuse for some of the brain-damages of | || minix. -- Linus Torvalds to Andrew| || Tanenbaum | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: [Clamav-devel] installation of 64bit libaries in /usr/lib ?
On Thu, Aug 28, 2008 at 12:37:17PM +0200, Per Jessen said: > Stephen Gran wrote: > > >> > > What OS? > >> > > On my amd64 Debian Linux /usr/lib64 is a symlink to /usr/lib. > >> > > >> > openSUSE 10.3. /usr/lib/ is used for 32-bit versions of various > >> > libraries. > >> > >> OK, so according to the FHS this is correct. We'll probably need some > >> additional configure check to handle it. > > > > Please don't. The multiarch fiasco is working it's ponderous way > > towards one of a number of possible solutions. > > Do you know which one? No. There's lots and lots of proposals and half-baked implementations, but none looks like top of the heap last I looked (which was a while ago, to be fair). > > Having clamav reimplement the logic in it's configure script is not > > helpful, and probably mildly harmful. Wait until it stabilizes, and > > then the tools will do the work for you. > > > > The OPs 'problem' could have been solved with the current build system > > by passing --libdir. > > Yes of course, but it seems like that sort of thing is exactly what > autoconf should be doing. Which is sort of precisely my point - once the multiarch people come up with something that doesn't suck, autoconf will be patched to support it, and then the clamav configure.in won't need to do anything. -- -- | Stephen Gran | A copy of the universe is not what is | | [EMAIL PROTECTED] | required of art; one of the damned | | http://www.lobefin.net/~steve | things is ample. -- Rebecca West | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: [Clamav-devel] installation of 64bit libaries in /usr/lib ?
On Thu, Aug 28, 2008 at 11:09:16AM +0200, Tomasz Kojm said: > On Thu, 28 Aug 2008 10:49:02 +0200 > Per Jessen <[EMAIL PROTECTED]> wrote: > > > Török Edwin wrote: > > > > > On 2008-08-28 11:00, Per Jessen wrote: > > >> I've just built 0.93.3 on an AMD64 machine - for some reason, the > > >> libraries were installed in /usr/lib, not /usr/lib64. Is that > > >> intentional ? > > > > > > What OS? > > > On my amd64 Debian Linux /usr/lib64 is a symlink to /usr/lib. > > > > openSUSE 10.3. /usr/lib/ is used for 32-bit versions of various > > libraries. > > OK, so according to the FHS this is correct. We'll probably need some > additional configure check to handle it. Please don't. The multiarch fiasco is working it's ponderous way towards one of a number of possible solutions. Having clamav reimplement the logic in it's configure script is not helpful, and probably mildly harmful. Wait until it stabilizes, and then the tools will do the work for you. The OPs 'problem' could have been solved with the current build system by passing --libdir. -- -- | Stephen Gran | It's always darkest just before the | | [EMAIL PROTECTED] | lights go out. -- Alex Clark | | http://www.lobefin.net/~steve | | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: [Clamav-devel] why is clamav source have clamav db files in the tarball ?
On Wed, Jul 16, 2008 at 09:43:08PM +0200, Benny Pedersen said: > > why is clamav installing new db when upgrade from sources ? > > should it not be sufficient with a run of freshclam before install ? > > problem with db in tarball is that it sometimes even downgrade db that > is installed, this problem comes mostly when new clamav is buildt from > source > > should this be solved in package managers or upstream ? Since clamd, clamscan, and so on won't start without a valid database file or two, it makes sense to make the default install contain a database. Currently the Debian packages conditionally install the databases shipped with a new release, taking care not to overwrite existing files. It would be nice if make install had the same behavior, but that's not trivial to do with automake, and I'm not sure it's worth the time it would take to get the logic right. -- ------ | Stephen Gran | The rule on staying alive as a | | [EMAIL PROTECTED] | forecaster is to give 'em a number or | | http://www.lobefin.net/~steve | give 'em a date, but never give 'em | || both at once. -- Jane Bryant Quinn| -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: [Clamav-devel] symbol visibilty, public API, and internal function useage
On Tue, Nov 20, 2007 at 09:59:21PM +0200, Török Edwin said: > Stephen Gran wrote: > > Hi all, > > > > So I've been thinking about how to reduce the breakage that occasionally > > happens to other bits of software on upgrades of libclamav, and I think > > I've come up with something that might be of some use. libtool lets you > > use a version script to (on platforms that support it) hide symbols from > > being globally visible and version those that are. [...] > This reminds me of https://wwws.clamav.net/bugzilla/show_bug.cgi?id=272 Yes, that's exactly the same issue. > > It also > > doesn't actually help with API/ABI changing modifications in the public > > API itself - > Ulrich Drepper says in his DSO howto > (http://people.redhat.com/drepper/dsohowto.pdf) that API/ABI stability > can be maintained via versioning. But that is stuff for post 1.0 IMHO. Agreed. I just meant that symbol visibilty doesn't actually force you guys to maintain a stable public API - you can still change that every release if you want. It just makes it easier to break the private functions as often as you want :) > Did any breakage occur due to changes in cli_* functions? People should > really not use those directly. I think so. I can't remember the details now, but when we did the libclamav1 -> libclamav2 transition in Debian, there were a few applications that either used functions not in the public headers, or messed about with the internals of private structs. We all know that's bad behavior on the part of those applications - I'm just trying to force them to use the interface that they're given. > > My personal preference is 2. It incurs some on disk and memory > > overhead, as these symbols will be loaded once for each application, > > rather than the normal shared library memory saving techniques. That > > being said, it is the simplest to manage, and is the most effective at > > making sure other applications do not link to private functions within > > the clamav suite that change between releases. > > Actually if we have export maps the size of the .so will be cut down, so > maybe it would compensate for it. That's a point I hadn't considered. You may be right. I sort of feel that on most hardware capable of running clamav, we're unlikely to notice a real difference with any of the proposed changes, but I'm generally in favor of efficiency. > > Ok, so long preamble over. > > > > version script: > > [.] > > vba56_dir_read; > > vba_decompress; > > I guess this is only used by sigtool. I wouldn't mind linking sigtool > statically with libclamav, it is not a tool used on a day-by-day basis > by end-users. > I think if you don't consider sigtool you can significantly shorten this > list. I got a half dozen from each app, unfortunately. The milter is a heavy user of several output functions as well as cli_malloc/realloc and friends, clamd uses a bunch of tmpfile related functions, and so on. I could make up a list of what each app uses if you like, but it's trivial to discover. Just make a version script where cl_* is the only thing in global: and watch what breaks :) > Besides if people see this list in an export map they'll start using it, > because they'll consider it public :( No more than they do now, I'm sorry to say. I am viewing this as a step to reducing what other projects are _able_ to use from clamav. This will mean some changes in clamav as well, though. > I was also thinking of using -fvisibility feature of gcc to hide > internals functions, which has the nice benefit of > avoiding an indirect call (usually symbols not declared static need an > extra indirection due to -fPIC). > However I didn't like the way -fvisibility has to be used. > I either have to explicitly declare the visibility of all functions > exported, or declare visibility on all functions being hidden. > Even on functions declared as extern! Sure, we could do an EXTERN macro > that also adds the visibility attribute ... Yes, that's why I decided on the version script approach. I find -fvisibility painful to use well. > However linker export maps can be implemented independently of > -fivisibility :) Very true. > Yes it would be nice to narrow down the list to this. > Does this work with GNU ld only? (it is supposed to work with Solaris's > ld too) As far as I know, it work on at least Solaris, Linux and the BSDs. I may be wrong, though - I tend not to spend a lot of time working on platforms besides linux these days. At any rate, it'll be more than what there is now, and people will generally be compiling 3rd party software against clamav on one
[Clamav-devel] symbol visibilty, public API, and internal function useage
vial. Is this something people are interested in? If so, how can I help to get the list down to global: cl_*; local: *; ? Happy hacking, -- ---------- | Stephen Gran | that's a Kludge(TM) It | | [EMAIL PROTECTED] | Works(tm) AIX works(TM) | | http://www.lobefin.net/~steve | no it doesn't => | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: [Clamav-devel] Clamav 0.90.X defects
On Sun, Mar 04, 2007 at 05:13:03PM -0700, Dave Shariff Yadallee - System Administrator a.k.a. The Root of the Problem said: > On Mon, Mar 05, 2007 at 12:04:26AM +0000, Stephen Gran wrote: > > On Sun, Mar 04, 2007 at 03:06:21PM -0700, Dave Shariff Yadallee - System > > Administrator a.k.a. The Root of the Problem said: > > > Can anyone explain why Clamav 0.90.X cannot find /usr/lib/libmilter.a > > > on BSD/OS 4.3.1 ?? Calamav 0.88.X can do so. > > > > Probably because it's actually looking for /usr/lib/libmilter.so ? > > > > Rebuild your milter library as a shared object, unless you really want > > static linking. > > Hmm!!! sendmail 8.13.8 is not so oriented as far as I see. I beg to differ: [EMAIL PROTECTED]:~$ ll /usr/lib/libmilter.so lrwxrwxrwx 1 root root 14 2007-01-09 11:14 /usr/lib/libmilter.so -> libmilter.so.0 [EMAIL PROTECTED]:~$ dpkg -l libmilter-dev ii libmilter-dev8.13.8-3 Sendmail Mail Filter API (Milter) It certainly can be done. I don't know anything about your specific environment or build arguments, but I assume it will work. At any rate, how to rebuild sendmail is probably wandering off topic for a list about ClamAV development issues, so I'll stop here. -- ------ | Stephen Gran | Our little systems have their day; They | | [EMAIL PROTECTED] | have their day and cease to be; They| | http://www.lobefin.net/~steve | are but broken lights of thee. -- | || Tennyson| -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: [Clamav-devel] Clamav 0.90.X defects
On Sun, Mar 04, 2007 at 03:06:21PM -0700, Dave Shariff Yadallee - System Administrator a.k.a. The Root of the Problem said: > Can anyone explain why Clamav 0.90.X cannot find /usr/lib/libmilter.a > on BSD/OS 4.3.1 ?? Calamav 0.88.X can do so. Probably because it's actually looking for /usr/lib/libmilter.so ? Rebuild your milter library as a shared object, unless you really want static linking. -- ------ | Stephen Gran | Argue for your limitations, and sure| | [EMAIL PROTECTED] | enough, they're yours. -- Messiah's | | http://www.lobefin.net/~steve | Handbook : Reminders for the Advanced | || Soul| -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: [Clamav-devel] (clamav-milter) is this check valuable?
On Mon, Feb 19, 2007 at 01:21:33AM +, Stephen Gran said: > Hello all, > > In clamav-milter.c, I see: I've changed the subject a bit to try to catch Nigel's attention. Sorry about following up to myself. -- ---------- | Stephen Gran | Oh my GOD -- the SUN just fell into | | [EMAIL PROTECTED] | YANKEE STADIUM!!| | http://www.lobefin.net/~steve | | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: [Clamav-devel] cl_scanbuff function
On Mon, Feb 19, 2007 at 12:55:14PM -0500, Dale Walsh said: > It appears that the "cl_scanbuff" function is no longer exported or > available from the library, is there a replacement function? Not as far as I know. You'll need to use the cl_scanfile routine instead. Which is painful, because it's easy to use cl_scanbuf when you only have a file (mmap) but harder to use cl_scanfile when you only have a buffer. But there we are. -- ------ | Stephen Gran | What color is a chameleon on a mirror? | | [EMAIL PROTECTED] | | | http://www.lobefin.net/~steve | | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: [Clamav-devel] defining clamav version
On Mon, Feb 19, 2007 at 05:36:59AM +0100, Robert Allerstorfer said:
> Hi,
>
> I have a question: Why is ClamAV's version currently defined in 2
> places ('configure.in' and 'configure')? In most C programs I have
> seen it is defined in a single file ('version.h').
configure is autogenerated from configure.in. It is just another way fo
doing it.
--
------
| Stephen Gran | Sight is a faculty; seeing is an art. |
| [EMAIL PROTECTED] | |
| http://www.lobefin.net/~steve | |
--
signature.asc
Description: Digital signature
___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
[Clamav-devel] is this check valuable?
Hello all,
In clamav-milter.c, I see:
/*
* Using TCP/IP for the sendmail->clamav-milter connection
*/
if((hostmail = smfi_getsymval(ctx, "{if_name}")) == NULL) {
if(use_syslog)
syslog(LOG_ERR, _("Can't get sendmail hostname"));
return cl_error;
}
However, I see here:
http://www.milter.info/sendmail/milter-ahead/CHANGES.TXT
When {if_addr}, {if_name}, and j macros are underfined fall
back onto the value of interface-name instead of "[127.0.0.1]"
for use with the call-ahead HELO.
And here:
http://blog.gmane.org/gmane.mail.postfix.devel/page=5
{if_name} interface name client connected to;
NULL for loopback
Both of these lead me to believe that it is a valid condition for
{if_name} to be NULL.
So I am curious what the value of the check is. This all came up
because a Debian user was trying to use postfix with clamav-milter over
a tcp socket. It is unclear to me whether postfix just does not set
this macro, or if it was a problem of a connection over lo.
So, my question is: if {if_name} returns NULL on loopback connections,
is the test in clamav-milter.c valid? Or should it just set hostmail to
127.0.0.1 in this case? Or am I missing something and this is a postfix
problem that we should not try to support? I admit to not knowing the
milter API all that well, so I can easily believe I'm missing something
here.
Thanks,
--
----------
| Stephen Gran | You will pioneer the first Martian |
| [EMAIL PROTECTED] | colony. |
| http://www.lobefin.net/~steve | |
--
signature.asc
Description: Digital signature
___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: [Clamav-devel] umask for clamav-milter.sock creation
On Tue, Jan 02, 2007 at 01:43:22PM -0200, Renato Botelho said: > Hello, > > I maintain clamav ports on FreeBSD systems, but I don't use clamav-milter. > > Recently, a user asked me he is using clamav-milter with postfix and > postfix was asking him to change socket permissions to 700. > > Is there a way to configure it to do it? If not i'll try a local > solution changing attributes after start clamav-milter. Currently, no. I am facing the same problem for Debian, so maybe we can pool ideas, or get a proper patch into the milter to allow socket permission setting. Take care, -- ------ | Stephen Gran | "Flattery is all right -- if you don't | | [EMAIL PROTECTED] | inhale." -- Adlai Stevenson | | http://www.lobefin.net/~steve | | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html
Re: [Clamav-devel] Proposed darwin patch
On Thu, Dec 28, 2006 at 03:05:08PM -0500, Dale Walsh said: > Thomasz, back on November 13 I submitted a patch related to Darwin/ > OSX that has to be applied every time a new release becomes available > to make the software more Darwin/OSX environment friendly. > > What are the chances of having the patch applied permanently thus > alleviating the need to track down a new patch after version changes > because the patch isn't included? > > As well, it was previously suggested that the patch didn't have to be > Darwin/OSX specific and that it could be applied across the board > without any ill-effects and I have no objections to it if this is the > route you wish to take. As the person (not a clamav dev team member, so my opinion is my own), I have a couple of questions. What are the advantages of your patch over, say, running freshclam with Foreground in the config file? Can you explain why you apply the patch, and what functionality it adds? It would help me to appreciate what it is you're doing, at least. As I said, I can't speak for any of the others, but it looks to me like duplication of existing functionality, and conditionally applied at that, which seems an odd way to go. -- ------ | Stephen Gran | Memory fault -- brain fried | | [EMAIL PROTECTED] | | | http://www.lobefin.net/~steve | | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html
[Clamav-devel] a cry for help
Hello all, I've tried before, and failed, mostly due to the fact that I treat email as a real time communication mechanism, when it clearly isn't. Currently, the Debian packages of clamav carry a 1.5-2.0 MB diff with every release, since I have to re-autotool the source in order to make it build on some of the architectures Debian supports. I would love to see this end (mostly for the admittedly selfish reason of not having to forward port the patch or deal with the pain of re-autotoling every release), but also because it will make the generic upstream tarball more portable. My past failures have mostly been that I propose a patch against a released version that does not apply to cvs, or I propose a patch against cvs that does not apply due to the often laggy nature of email based communication. So, I propose this: I can be found in #clamav on the freenode network of irc, or #debian-devel on oftc. If any of the devel team are interested in updating the autotools tree, /msg me and I will update whatever source tree is deemed appropriate, and give a url to an approriate patch. I am willing to do whatever would be useful to make this issue disappear. If you want to do it by phone even, email me off list and we can set something up. Thanks all, -- -- | Stephen Gran | Hmmm ... A hash-singer and a cross-eyed | | [EMAIL PROTECTED] | guy were SLEEPING on a deserted island, | | http://www.lobefin.net/~steve | when ...| -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html
[Clamav-devel] implicit function declarations patch
Hello all,
Pretty straight forward stuff, really.
Thanks,
Index: clamd/tcpserver.c
===
--- clamd/tcpserver.c (revision 274)
+++ clamd/tcpserver.c (working copy)
@@ -28,6 +28,9 @@
#include
#include
#include
+#ifdef HAVE_UNISTD_H
+#include
+#endif
#ifndefC_WINDOWS
#include
#include
Index: clamd/localserver.c
===
--- clamd/localserver.c (revision 274)
+++ clamd/localserver.c (working copy)
@@ -28,6 +28,9 @@
#include
#include
#include
+#ifdef HAVE_UNISTD_H
+#include
+#endif
#include "libclamav/clamav.h"
Index: libclamav/unrar/unrar20.c
===
--- libclamav/unrar/unrar20.c (revision 274)
+++ libclamav/unrar/unrar20.c (working copy)
@@ -23,6 +23,7 @@
#include
+#include "others.h"
#include "unrar.h"
#include "unrar20.h"
Index: libclamav/unrar/unrar15.c
===
--- libclamav/unrar/unrar15.c (revision 274)
+++ libclamav/unrar/unrar15.c (working copy)
@@ -22,6 +22,7 @@
*/
#include "unrar.h"
+#include
#define STARTL1 2
static unsigned int dec_l1[]={0x8000,0xa000,0xc000,0xd000,0xe000,0xea00,
Index: libclamav/mspack/system.c
===
--- libclamav/mspack/system.c (revision 274)
+++ libclamav/mspack/system.c (working copy)
@@ -12,6 +12,7 @@
#endif
#include
+#include
#include "others.h"
#include "system.h"
Index: libclamav/filetypes.c
===
--- libclamav/filetypes.c (revision 274)
+++ libclamav/filetypes.c (working copy)
@@ -26,6 +26,10 @@
#include
#include
#include
+#include
+#ifdef HAVE_UNISTD_H
+#include
+#endif
#include "clamav.h"
#include "filetypes.h"
--
--
| Stephen Gran | We do not colonize. We conquer. We|
| [EMAIL PROTECTED] | rule. There is no other way for us.|
| http://www.lobefin.net/~steve | -- Rojan, "By Any Other Name", stardate |
|| 4657.5 |
--
signature.asc
Description: Digital signature
___
http://lurker.clamav.net/list/clamav-devel.html
Re: [Clamav-devel] proposed patch
On Mon, Nov 13, 2006 at 07:23:53PM -0500, Dale Walsh said: > Tomasz, a patch is manually applied without exception when the ClamAV > software is built to work properly within the darwin environment and > there are several variation of the patch but the end changes are the > same, adding command-line options to manipulate the daemons. > > I've updated the patch to work like other OS dependant code changes/ > exceptions in the related files, can this be applied permanently so a > new patch doesn't have to be generated and applied whenever a new > ClamAV source becomes available please? Why does it have to be OS dependant? Can't the command line option be available on all platforms? -- ------ | Stephen Gran | Heard that the next Space Shuttle is| | [EMAIL PROTECTED] | supposed to carry several Guernsey | | http://www.lobefin.net/~steve | cows? It's gonna be the herd shot | || 'round the world. | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html
Re: [Clamav-devel] configure.in patch, please
On Tue, Oct 24, 2006 at 08:55:45AM +0200, Tom G. Christensen said: > Stephen Gran wrote: > > >(e.g., I'm not sure > >whether or not clamav compiles with gcc 2.x - I do remember that for a > >while the milter at least failed with that compiler)? > > > I build every release on RHEL 2.1 and my notes says this was fixed in > 0.87.1. Good to know, thanks. For a while, I was also building every release against woody, which shipped with 2.95, but I have finally dropped it. At any rate, I think an 8 year old standard is probably recent enough to ask for some level of compliance. But as always, it's up to the dev team to decide how they'd like to do this (if at all). Thanks, -- ---------- | Stephen Gran | A verbal contract isn't worth the paper | | [EMAIL PROTECTED] | it's written on. -- Samuel Goldwyn| | http://www.lobefin.net/~steve | | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html
Re: [Clamav-devel] configure.in patch, please
On Thu, Oct 19, 2006 at 12:54:43PM +0100, Stephen Gran said:
> On Wed, Oct 18, 2006 at 10:48:29PM +0100, Stephen Gran said:
> > This is in reference to debian bug #393672, viewable at
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=393672
>
> Sorry, the previous patch was wrong
As was that one, apparently - I thought I had tested it, but I clearly
hadn't. Some artifact of the error producing machine that pounds on the
keys, apparently. Some lessons learned:
When evaluating a shell variable, remember to use $variable (not variable)
Shells other than bash don't expand [:class:]+ - use [[:class:]]*
Quote variables that might be unset before testing them
This go round was actually tested and seems to produce the right results
now:
Index: configure.in
===
--- configure.in(revision 168)
+++ configure.in(working copy)
@@ -178,9 +178,30 @@
sendmailver_b=`echo $sendmailver | awk -F. '{printf $2}'`
sendmailver_c=`echo $sendmailver | awk -F. '{printf $3}'`
-AC_DEFINE_UNQUOTED(SENDMAIL_VERSION_A, $sendmailver_a, [major version of
Sendmail])
-AC_DEFINE_UNQUOTED(SENDMAIL_VERSION_B, $sendmailver_b, [minor version of
Sendmail])
-AC_DEFINE_UNQUOTED(SENDMAIL_VERSION_C, $sendmailver_c, [subversion of
Sendmail])
+case "$sendmailver_a" in
+ [[[:digit:]]]*) ;;
+ *) sendmailver_a= ;;
+esac
+
+case "$sendmailver_b" in
+ [[[:digit:]]]*) ;;
+ *) sendmailver_b= ;;
+esac
+
+case "$sendmailver_c" in
+ [[[:digit:]]]*) ;;
+ *) sendmailver_c= ;;
+esac
+
+if test -n "$sendmailver_a"; then
+ AC_DEFINE_UNQUOTED(SENDMAIL_VERSION_A, $sendmailver_a, [major version of
Sendmail])
+fi
+if test -n "$sendmailver_b"; then
+ AC_DEFINE_UNQUOTED(SENDMAIL_VERSION_B, $sendmailver_b, [minor version of
Sendmail])
+fi
+if test -n "$sendmailver_c"; then
+ AC_DEFINE_UNQUOTED(SENDMAIL_VERSION_C, $sendmailver_c, [subversion of
Sendmail])
+fi
fi
fi
===
Sorry for so much noise for so little gain.
--
--
| Stephen Gran | Remember, even if you win the rat race |
| [EMAIL PROTECTED] | -- you're still a rat. |
| http://www.lobefin.net/~steve | |
--
signature.asc
Description: Digital signature
___
http://lurker.clamav.net/list/clamav-devel.html
Re: [Clamav-devel] configure.in patch, please
On Mon, Oct 23, 2006 at 09:01:25AM -0400, Brian A. Reiter said: > > > My one fear is that some older shells on > > > systems supported by clamav might not support the POSIX character > > > class [:digit:] - it is POSIX, but that doesn't actuall gurantee > > > portability between operating systems, as I've found out > > the hard way > > > :) > > > > Why not replace "[:digit:]" with old good "[0-9]"? > > It's portable and even shorter. > > [not that I know what the patch is about...] > > > > I imagine Stephen was attracted to [:digit]: because it is defined as the > set of "digits" in all locales and character sets. For example, [0-9] would > match on the Arabic numerals used in ASCII ( 0x30 - 0x39 ), but would not > work on Unicode Indic numerals used in Arabic ( 0x0660 - 0x0669 ) or any of > the host of other numeral systems used throughout central and east Asia. Couldn't have said it better, thanks. [:digit:] is specified in POSIX.2, which came out in 1998. I realize there are going to be some people running decade old OSes, but are they really running them without updates, and would clamav build on them as is anyway (e.g., I'm not sure whether or not clamav compiles with gcc 2.x - I do remember that for a while the milter at least failed with that compiler)? Take care, -- -- | Stephen Gran | The trouble with doing something right | | [EMAIL PROTECTED] | the first time is that nobody | | http://www.lobefin.net/~steve | appreciates how difficult it was. | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html
Re: [Clamav-devel] configure.in patch, please
On Wed, Oct 18, 2006 at 10:48:29PM +0100, Stephen Gran said:
> This is in reference to debian bug #393672, viewable at
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=393672
Sorry, the previous patch was wrong - the m4 expansion swallows one set
of square brackets, so they need to be doubled. Corrected patch below.
Index: configure.in
===
--- configure.in(revision 186)
+++ configure.in(revision 188)
@@ -178,9 +178,30 @@
sendmailver_b=`echo $sendmailver | awk -F. '{printf $2}'`
sendmailver_c=`echo $sendmailver | awk -F. '{printf $3}'`
-AC_DEFINE_UNQUOTED(SENDMAIL_VERSION_A, $sendmailver_a, [major version of
Sendmail])
-AC_DEFINE_UNQUOTED(SENDMAIL_VERSION_B, $sendmailver_b, [minor version of
Sendmail])
-AC_DEFINE_UNQUOTED(SENDMAIL_VERSION_C, $sendmailver_c, [subversion of
Sendmail])
+case sendmailver_a in
+ [[:digit:]]+) ;;
+ *) sendmailver_a= ;;
+esac
+
+case sendmailver_b in
+ [[:digit:]]+) ;;
+ *) sendmailver_b= ;;
+esac
+
+case sendmailver_c in
+ [[:digit:]]+) ;;
+ *) sendmailver_c= ;;
+esac
+
+if test -n "$sendmailver_a"; then
+ AC_DEFINE_UNQUOTED(SENDMAIL_VERSION_A, $sendmailver_a, [major version of
Sendmail])
+fi
+if test -n "$sendmailver_b"; then
+ AC_DEFINE_UNQUOTED(SENDMAIL_VERSION_B, $sendmailver_b, [minor version of
Sendmail])
+fi
+if test -n "$sendmailver_c"; then
+ AC_DEFINE_UNQUOTED(SENDMAIL_VERSION_C, $sendmailver_c, [subversion of
Sendmail])
+fi
fi
fi
Thanks again,
--
------
| Stephen Gran | A man without a woman is like a statue |
| [EMAIL PROTECTED] | without pigeons.|
| http://www.lobefin.net/~steve | |
--
signature.asc
Description: Digital signature
___
http://lurker.clamav.net/list/clamav-devel.html
[Clamav-devel] configure.in patch, please
Hello all,
This is in reference to debian bug #393672, viewable at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=393672
The gist of it is that apparently some mailers are brain dead. No real
surprise there, I suppose, but the attached patch makes it easier to
build clamav in automated build environments where these brain dead
mailers might be installed. My one fear is that some older shells on
systems supported by clamav might not support the POSIX character class
[:digit:] - it is POSIX, but that doesn't actuall gurantee portability
between operating systems, as I've found out the hard way :)
Thanks for considering it,
Index: debian/unstable/configure.in
===
--- debian/unstable/configure.in(revision 185)
+++ debian/unstable/configure.in(working copy)
@@ -178,9 +178,30 @@
sendmailver_b=`echo $sendmailver | awk -F. '{printf $2}'`
sendmailver_c=`echo $sendmailver | awk -F. '{printf $3}'`
-AC_DEFINE_UNQUOTED(SENDMAIL_VERSION_A, $sendmailver_a, [major version of
Sendmail])
-AC_DEFINE_UNQUOTED(SENDMAIL_VERSION_B, $sendmailver_b, [minor version of
Sendmail])
-AC_DEFINE_UNQUOTED(SENDMAIL_VERSION_C, $sendmailver_c, [subversion of
Sendmail])
+case sendmailver_a in
+ [:digit:]+) ;;
+ *) sendmailver_a= ;;
+esac
+
+case sendmailver_b in
+ [:digit:]+) ;;
+ *) sendmailver_b= ;;
+esac
+
+case sendmailver_c in
+ [:digit:]+) ;;
+ *) sendmailver_c= ;;
+esac
+
+if test -n "$sendmailver_a"; then
+ AC_DEFINE_UNQUOTED(SENDMAIL_VERSION_A, $sendmailver_a, [major version of
Sendmail])
+fi
+if test -n "$sendmailver_b"; then
+ AC_DEFINE_UNQUOTED(SENDMAIL_VERSION_B, $sendmailver_b, [minor version of
Sendmail])
+fi
+if test -n "$sendmailver_c"; then
+ AC_DEFINE_UNQUOTED(SENDMAIL_VERSION_C, $sendmailver_c, [subversion of
Sendmail])
+fi
fi
fi
--
------
| Stephen Gran | BOFH excuse #426: internet is needed |
| [EMAIL PROTECTED] | to catch the etherbunny |
| http://www.lobefin.net/~steve | |
--
signature.asc
Description: Digital signature
___
http://lurker.clamav.net/list/clamav-devel.html
[Clamav-devel] acinclude.m4 update, please
Hello all, So yesterday I was building Debian packages of the new version, and I was updating the libtool version and so forth, and wondering why I have more trouble doing so with clamav than other projects, so I finally took a real look. It turns out AC_PROG_LIBTOOL is AC_DEFUN'd in acinclude.m4, rather than aclocal.m4. This prevents a run of aclocal from updating it to a newer version. The best way to fix this is just to remove the 3,800 lines from acinclude.m4, and run aclocal again. I could send a patch, but I'm not sure anyone here wants a patch approaching 4000 lines to go the mailing list :) If you want a patch mailed to you outside of the list, let me know - I'd be happy to provide one. Thanks, -- ---------- | Stephen Gran | He that would govern others, first | | [EMAIL PROTECTED] | should be the master of himself.| | http://www.lobefin.net/~steve | | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html
Re: [Clamav-devel] libclamav compile patch for Interix
On Mon, Jun 05, 2006 at 04:15:33PM -0400, Brian A. Reiter said: > I feel like a yutz, but the patches didn't go through again. I'm now trying > one at a time: > > - libclamav.patch: The changes here are to get a compile on Interix. Put the patches inline - the MLM seems to eat attachments. -- ------ | Stephen Gran | A sadist is a masochist who follows the | | [EMAIL PROTECTED] | Golden Rule.| | http://www.lobefin.net/~steve | | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html
Re: [Clamav-devel] Can I Use Clam AV to search a drive for customer data
On Wed, May 03, 2006 at 02:20:39PM +, Colin said: > Hello, I would like some advice on an idea I have. I want to create an > application that will help my company audit our network storage to ensure > that > we are not storing private customer data in any accessable files. > > For example, my idea is to search files for signatures of credit card numbers > (maybe addresses etc). Since I am basically looking for patterns that might > be > a credit card number, I thought that this would essentially be a virus > scanner > that isn't looking for viruses. > > I found CLAM AV (open source virus scanner) and I am wondering if it seems > that > using CLAM AV would be suited to this type of application, or am I choosing > the > wrong kind of solution. Debian has already used clamav for arbitrary scans, so this is quite doable. A good example is a recent one: xpdf had a security flaw announced. Many applications embed bits of xpdf code, unfortunately, and they all had to be found and patched. So a signature was written that matched the vulnerable functions, and the archive was scanned. It considerably shortened the hunt time. Take care, -- ------ | Stephen Gran | Conquering Russia should be done steppe | | [EMAIL PROTECTED] | by steppe. | | http://www.lobefin.net/~steve | | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html
Re: [Clamav-devel] Re: [Clamav-users] clamav-0.88.1 segmentation fault on 64bit systems
On Wed, Apr 12, 2006 at 12:10:53PM -0500, Damian Menscher said: > So, this is the third report I've seen of people getting bitten by > this bug. I've been warning friends not to upgrade as a result. > > There needs to be another release to correct this issue. It's silly > to argue otherwise (so please don't bother). No point holding off. This bug has, as far as I can tell from the CVS timestamps, been there since mid-November. I have had several reports of 64 bit issues via the Debian BTS before now (oddly, starting roughly the same time as the CVS changes that added cli_dbgmsg), but hadn't been able to track it down to that. So, anyone running clamav version >=0.88 already has the bug. I am not sure why it's manifesting itself now, but it's not particular to this release. Take care, -- ------ | Stephen Gran | QOTD: "I'd never marry a woman who | | [EMAIL PROTECTED] | didn't like pizza... I might play golf | | http://www.lobefin.net/~steve | with her, but I wouldn't marry her!"| -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html
Re: [Clamav-devel] Patch for (mostly) missing includes
Continuing in this vein, I built on amd64 to see if there were any
furhter issues. There were, but they were relatively minor. Attached is
a patch that fixes the issues here.
The chmunpack.c ifdef may not be the best way to handle it - I know
__WORDSIZE will be defined with gnu utils, but I don't about other
platforms. There is another way to handle the conversion between %llu
on non-64 bit platforms to %lu on 64 bit platforms with PRIu64, but I
can't remember if that is C99 or not. If so, that might be the better
way to go.
Take care,
diff -Nru clamav-0.88.1.bak/clamav-milter/clamav-milter.c
clamav-0.88.1/clamav-milter/clamav-milter.c
--- clamav-0.88.1.bak/clamav-milter/clamav-milter.c 2006-04-08
17:19:30.0 +0100
+++ clamav-0.88.1/clamav-milter/clamav-milter.c 2006-04-09 00:17:14.0
+0100
@@ -2487,7 +2487,7 @@
int nbytes;
if(logVerbose)
- syslog(LOG_DEBUG, _("clamfi_envbody: %u bytes"), len);
+ syslog(LOG_DEBUG, _("clamfi_envbody: %zu bytes"), len);
#ifdef CL_DEBUG
cli_dbgmsg(_("clamfi_envbody: %u bytes\n"), len);
#endif
@@ -3371,7 +3371,7 @@
char buf[32];
strerror_r(errno, buf, sizeof(buf));
syslog(LOG_ERR,
- _("write failure (%u bytes) to
%s: %s"),
+ _("write failure (%zu bytes) to
%s: %s"),
len, privdata->filename, buf);
#else
syslog(LOG_ERR, _("write failure (%u
bytes) to %s: %s"),
@@ -3388,10 +3388,10 @@
char buf[32];
strerror_r(errno, buf, sizeof(buf));
syslog(LOG_ERR,
- _("write failure (%u bytes) to
clamd: %s"),
+ _("write failure (%zu bytes) to
clamd: %s"),
len, buf);
#else
- syslog(LOG_ERR, _("write failure (%u
bytes) to clamd: %s"), len, strerror(errno));
+ syslog(LOG_ERR, _("write failure (%zu
bytes) to clamd: %s"), len, strerror(errno));
#endif
}
checkClamd();
diff -Nru clamav-0.88.1.bak/libclamav/chmunpack.c
clamav-0.88.1/libclamav/chmunpack.c
--- clamav-0.88.1.bak/libclamav/chmunpack.c 2006-04-05 00:20:22.0
+0100
+++ clamav-0.88.1/libclamav/chmunpack.c 2006-04-09 00:13:07.0 +0100
@@ -974,8 +974,12 @@
entry = entry->next;
continue;
}
-
+
+# if __WORDSIZE == 64
+ snprintf((char *) filename, 1024, "%s/%d-%lu.chm", dirname,
count, entry->offset);
+# else
snprintf((char *) filename, 1024, "%s/%d-%llu.chm", dirname,
count, entry->offset);
+# endif
ofd = open((char *) filename, O_WRONLY|O_CREAT|O_TRUNC,
S_IRWXU);
if (ofd < 0) {
entry = entry->next;
--
--
| Stephen Gran | I'll say it again for the logic |
| [EMAIL PROTECTED] | impaired. -- Larry Wall|
| http://www.lobefin.net/~steve | |
--
signature.asc
Description: Digital signature
___
http://lurker.clamav.net/list/clamav-devel.html
[Clamav-devel] Patch for (mostly) missing includes
ion 44)
+++ libclamav/scanners.c(working copy)
@@ -69,6 +69,7 @@
#include "untar.h"
#include "special.h"
#include "binhex.h"
+#include "tnef.h"
#ifdef HAVE_ZLIB_H
#include
@@ -378,7 +379,7 @@
* Bit 6: Strong encryption was used
* Bit 13: Encrypted central directory
*/
- encrypted = (zdirent.d_flags & 0x2041 != 0);
+ encrypted = ((zdirent.d_flags & 0x2041) != 0);
cli_dbgmsg("Zip: %s, crc32: 0x%x, offset: %d, encrypted: %d,
compressed: %u, normal: %u, method: %d, ratio: %d (max: %d)\n", zdirent.d_name,
zdirent.d_crc32, zdirent.d_off, encrypted, zdirent.d_csize, zdirent.st_size,
zdirent.d_compr, zdirent.d_csize ? (zdirent.st_size / zdirent.d_csize) : 0,
limits ? limits->maxratio : 0);
@@ -1394,8 +1395,7 @@
int cli_magic_scandesc(int desc, const char **virname, unsigned long int
*scanned, const struct cl_node *root, const struct cl_limits *limits, unsigned
int options, unsigned int arec, unsigned int mrec)
{
- int ret = CL_CLEAN, nret;
- int bread = 0;
+ int ret = CL_CLEAN;
cli_file_t type;
struct stat sb;
Index: libclamav/special.c
===
--- libclamav/special.c (revision 44)
+++ libclamav/special.c (working copy)
@@ -28,6 +28,7 @@
#include "clamav.h"
#include "others.h"
#include "cltypes.h"
+#include "special.h"
#define FALSE (0)
#define TRUE (1)
Index: libclamav/mbox.c
===
--- libclamav/mbox.c(revision 44)
+++ libclamav/mbox.c(working copy)
@@ -2329,6 +2329,12 @@
switch(messageGetEncoding(aMessage)) {
case NOENCODING:
case EIGHTBIT:
+ case QUOTEDPRINTABLE:
+ case BASE64:
+ case UUENCODE:
+ case YENCODE:
+ case EEXTENSION:
+ case BINHEX:
case BINARY:
if(encodingLine(aMessage) == NULL) {
/*
Index: libclamav/htmlnorm.c
===
--- libclamav/htmlnorm.c(revision 44)
+++ libclamav/htmlnorm.c(working copy)
@@ -1138,6 +1138,8 @@
}
state = HTML_RFC2397_DATA;
break;
+ case HTML_SPECIAL_CHAR:
+ break;
case HTML_ESCAPE_CHAR:
value *= 16;
length++;
Index: libclamav/zziplib/zzip-zip.c
===
--- libclamav/zziplib/zzip-zip.c(revision 44)
+++ libclamav/zziplib/zzip-zip.c (working copy)
@@ -16,6 +16,7 @@
#endif
#include "target.h"
+#include "others.h"
#include /* archive handling */
#include
--
--
| Stephen Gran | Is knowledge knowable? If not, how do |
| [EMAIL PROTECTED] | we know that? |
| http://www.lobefin.net/~steve | |
--
signature.asc
Description: Digital signature
___
http://lurker.clamav.net/list/clamav-devel.html
[Clamav-devel] KFreeBSD patch
Hello all,
Can you please apply the following patch? It allows ClamAV to build on
KFreeBSD (Gnu Libc on a FreeBSD kernel). I have been carrying this
patch locally for a while, as this seemed like a Debian only project,
but it seems like it is making some progress, so I am now asking if this
can be merged.
Thanks,
--- clamav-0.88.1.orig/configure.in
+++ clamav-0.88.1/configure.in
@@ -365,6 +365,21 @@
;;
esac
;;
+kfreebsd*-gnu)
+AC_DEFINE(C_KFREEBSD_GNU,1,[target is kfreebsd-gnu])
+if test "$have_pthreads" = "yes"; then
+ LIBCLAMAV_LIBS="$LIBCLAMAV_LIBS -lpthread"
+ TH_SAFE="-thread-safe"
+ AC_DEFINE(CL_THREAD_SAFE,1,[thread safe])
+ AC_DEFINE(_REENTRANT,1,[thread safe])
+ CLAMD_LIBS="$CLAMD_LIBS -lpthread"
+ CLAMAV_MILTER_LIBS="$CLAMAV_MILTER_LIBS -lpthread"
+ if test "$want_clamuko" = "yes"; then
+ AC_DEFINE(CLAMUKO,1,[enable clamuko])
+ fi
+ CLAMSCAN_LIBS="$CLAMSCAN_LIBS -lpthread"
+fi
+;;
cygwin*)
AC_DEFINE(C_CYGWIN,1,[os is cygwin])
if test "$test_clamav" = "yes"; then
--- clamav-0.88.1.orig/clamav-config.h.in
+++ clamav-0.88.1/clamav-config.h.in
@@ -54,6 +54,9 @@
/* os is irix */
#undef C_IRIX
+/* target is kfreebsd-gnu */
+#undef C_KFREEBSD_GNU
+
/* target is linux */
#undef C_LINUX
--- clamav-0.88.1.orig/libclamav/blob.c
+++ clamav-0.88.1/libclamav/blob.c
@@ -405,7 +405,8 @@
(int)(sizeof(fullname) - 9 - strlen(dir)), filename);
#endif
-#ifdefined(C_LINUX) || defined(C_BSD) || defined(HAVE_MKSTEMP) ||
defined(C_SOLARIS) || defined(C_CYGWIN) || defined(C_QNX6)
+#ifdefined(C_LINUX) || defined(C_BSD) || defined(HAVE_MKSTEMP) ||
defined(C_SOLARIS) || defined(C_CYGWIN) || defined(C_QNX6) ||
defined(C_KFREEBSD_GNU)
+
cli_dbgmsg("fileblobSetFilename: mkstemp(%s)\n", fullname);
fd = mkstemp(fullname);
#else
--- clamav-0.88.1.orig/libclamav/mbox.c
+++ clamav-0.88.1/libclamav/mbox.c
@@ -3049,7 +3049,7 @@
return i;
ptr = &buf[--len];
-#ifdefined(UNIX) || defined(C_LINUX) || defined(C_DARWIN) /* watch - it
may be in shared text area */
+#ifdefined(UNIX) || defined(C_LINUX) || defined(C_DARWIN) ||
defined(C_KFREEBSD_GNU) /* watch - it may be in shared text area */
do
if(*ptr)
*ptr = '\0';
--- clamav-0.88.1.orig/libclamav/untar.c
+++ clamav-0.88.1/libclamav/untar.c
@@ -245,7 +245,7 @@
}
snprintf(fullname, sizeof(fullname) - 1 - suffixLen,
"%s/%.*sXX", dir,
(int)(sizeof(fullname) - 9 - suffixLen -
strlen(dir)), name);
-#ifdefined(C_LINUX) || defined(C_BSD) || defined(HAVE_MKSTEMP) ||
defined(C_SOLARIS) || defined(C_CYGWIN)
+#ifdefined(C_LINUX) || defined(C_BSD) || defined(HAVE_MKSTEMP) ||
defined(C_SOLARIS) || defined(C_CYGWIN) || defined(C_KFREEBSD_GNU)
fd = mkstemp(fullname);
#else
(void)mktemp(fullname);
--
--
| Stephen Gran | Culus: are you awake?|
| [EMAIL PROTECTED] | no |
| http://www.lobefin.net/~steve | |
--
signature.asc
Description: Digital signature
___
http://lurker.clamav.net/list/clamav-devel.html
Re: [Clamav-devel] clamav embedded setup
On Mon, Apr 03, 2006 at 04:45:57PM +0200, [EMAIL PROTECTED] said: > I see however at least 3 clamd processes , each claiming > VmRSS: 10736 kB and after a while (running overnight without > scanning) claiming over 19000 kB (but presumably much of > it beeing shared libraries). These 3 threads are there always after > a'startup and not only during scanning. > > When comparing this with the linux version (current debian sarge, clamav 0.88, > kernel 2.6.15.6 ) and using the same configuratin I see only one thread, > claiming > VmRSS: 10104 kB > > Should I expect to see only a single clamd thread when choosing MaxThreads 1 > ? > What is the memory consumption I should expect after running clamd for > a longer time with the above configuration ? There are generally speaking always at least a couple of threads (I think 3 is correct), but how 'ps' displays processes vs threads is very system dependant. On the sarge machine, I think either of ps -elF or ps axH will show you the threads as seperate LWP ids. As for the rest, I will defer to others for now. -- ------ | Stephen Gran | Rome was not built in one day. -- | | [EMAIL PROTECTED] | John Heywood| | http://www.lobefin.net/~steve | | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html
Re: [Clamav-devel] patch for various compiler warnings
On Tue, Mar 07, 2006 at 11:14:01AM +0100, Tomasz Kojm said: > On Tue, 28 Feb 2006 00:28:29 + > Stephen Gran <[EMAIL PROTECTED]> wrote: > > > Hello all, > > > > This patch fixes all compiler warnings on the two architectures I have > > access to rapidly (amd64 and i386). > > Hi Stephen, > > changes for zziplib applied in CVS. Thanks! -- ---------- | Stephen Gran | Keep the number of passes in a compiler | | [EMAIL PROTECTED] | to a minimum. -- D. Gries | | http://www.lobefin.net/~steve | | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html
[Clamav-devel] patch for various compiler warnings
disk */
-char z_finaldisk[2]; /* number of the disk with the start of the central
dir */
-char z_entries[2]; /* total number of entries in the central dir on this
disk */
-char z_finalentries[2]; /* total number of entries in the central dir */
-char z_rootsize[4]; /* size of the central directory */
-char z_rootseek[4]; /* offset of start of central directory with respect
to *
+unsigned char z_magic[4]; /* end of central dir signature (0x06054b50) */
+unsigned char z_disk[2]; /* number of this disk */
+unsigned char z_finaldisk[2]; /* number of the disk with the start of the
central dir */
+unsigned char z_entries[2]; /* total number of entries in the central dir
on this disk */
+unsigned char z_finalentries[2]; /* total number of entries in the
central dir */
+unsigned char z_rootsize[4]; /* size of the central directory */
+unsigned char z_rootseek[4]; /* offset of start of central directory with
respect to *
* the starting disk number */
-char z_comment[2]; /* zipfile comment length */
+unsigned char z_comment[2]; /* zipfile comment length */
/* followed by zipfile comment (of variable size) */
} __attribute__((packed));
--- clamav-0.88.orig/clamav-milter/clamav-milter.c
+++ clamav-0.88/clamav-milter/clamav-milter.c
@@ -281,7 +281,7 @@
static int fflag = 0; /* force a scan, whatever */
static int oflag = 0; /* scan messages from our machine? */
static int lflag = 0; /* scan messages from our site? */
-static const char*progname; /* our name - usually clamav-milter */
+static char*progname; /* our name - usually clamav-milter */
/* Variables for --external */
static int external = 0; /* scan messages ourself or use clamd? */
--- clamav-0.88.orig/libclamav/zziplib/zzip-io.c
+++ clamav-0.88/libclamav/zziplib/zzip-io.c
@@ -61,11 +61,9 @@
{
&open,
&close,
-/* (int (*)(int, void*, unsigned)) */
-&zzip_wrap_read,
-/* (zzip_off_t (*)(int, zzip_off_t, int)) */
-&zzip_wrap_lseek,
-&zzip_filesize,
+(int (*)(int, void*, unsigned)) &zzip_wrap_read,
+(zzip_off_t (*)(int, zzip_off_t, int)) &zzip_wrap_lseek,
+(zzip_off_t (*)(int)) &zzip_filesize,
1
};
--
--
| Stephen Gran | To order, call toll-free. |
| [EMAIL PROTECTED] | |
| http://www.lobefin.net/~steve | |
--
signature.asc
Description: Digital signature
___
http://lurker.clamav.net/list/clamav-devel.html
Re: [Clamav-devel] Re: bug in in function mdprintf() from fileshared/output.c
On Tue, Feb 28, 2006 at 12:17:43AM +0300, Anton Yuzhaninov said:
> AY> In attach two patches for 0.88 (tested on FreeBSD 5.4-STABLE):
> 2. From me
>
> --- shared/output.c.origSun Feb 26 00:12:11 2006
> +++ shared/output.c Mon Feb 27 23:50:09 2006
> @@ -71,8 +71,14 @@
> int bytes;
>
> va_start(args, str);
> -bytes = vsnprintf(buff, 512, str, args);
> +bytes = vsnprintf(buff, sizeof(buff), str, args);
> va_end(args);
> +
> +if (bytes >= sizeof(buff))
> + bytes = sizeof(buff) - 1;
> +
> write(desc, buff, bytes);
> return bytes;
> }
There are two things we want to know: vsnprintf's return code, and
sizeof(buff). These are not the same thing. So, this might be better
written as something like:
if ( ( bytes = vsnprintf(buff, sizeof(buff), str, args) ) > 0 ) {
if (bytes > sizeof(buff))
bytes = sizeof(buff);
write(desc, buff, bytes);
free(buff);
return bytes;
} else {
return -1;
}
Team, I can code up a formal patch if my reasoning looks right to you -
this is just a quick idea for now.
--
------
| Stephen Gran | Confucius say too much. -- Recent |
| [EMAIL PROTECTED] | Chinese Proverb |
| http://www.lobefin.net/~steve | |
--
signature.asc
Description: Digital signature
___
http://lurker.clamav.net/list/clamav-devel.html
Re: [Clamav-devel] Regression in ClamAV 0.88?
On Sun, Jan 15, 2006 at 02:49:08AM -0600, Damian Menscher said: > On Wed, 11 Jan 2006, David F. Skoll wrote: > > >With ClamAV 0.87.1, the command: > >clamscan --unzip msg-1212-47.zip > >finds the EICAR, but with 0.88 it does not. I believe I found the > >problem; below is a patch than makes 0.88 work. If Clam developers > >could check it out to make sure there are no bad side effects, I'd > >appreciate it. > > I have two questions: > > What is the impact of this regression? Will it reduce the functionality > of a server configured to scan incoming email? Only if you use clamscan as a fall back, like some do (amavis, maybe?) Or at least that's how I understand the bug. > Is a new release (0.88.1) forthcoming to correct this regression? The > lead developers have been silent There my guess is as good as yours. -- ------ | Stephen Gran | What an author likes to write most is | | [EMAIL PROTECTED] | his signature on the back of a cheque. | | http://www.lobefin.net/~steve | -- Brendan Francis | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html
Re: [Clamav-devel] ClamAV infinite loop
On Sun, Nov 27, 2005 at 02:03:59PM +, Nigel Horne said:
> On Wed, 2005-11-16 at 21:41, Brian Bebeau wrote:
>
> > cli_realloc() doesn't fail, so it never breaks out of the loop
> > from that.
>
> >From cli_realloc:
>
> if(!size || size > MAX_ALLOCATION) {
> cli_errmsg("Attempt to allocate %d bytes. Please report to
> [EMAIL PROTECTED]", size);
> return NULL;
> }
>
> Looks like a failure to me!
That only fails if the size parmaeter is NULL or too big. If they are of
normal size it succeeds, and continues to the next bit where it allocates
memory and returns, and then the calling function continues on until it
fails and loops again. The question is really, why does the calling
function loop if the first time failed? Shouldn't it return an error?
--
------
| Stephen Gran | I want to marry a girl just like the|
| [EMAIL PROTECTED] | girl that married dear old dad. --|
| http://www.lobefin.net/~steve | Freud |
--
signature.asc
Description: Digital signature
___
http://lurker.clamav.net/list/clamav-devel.html
[Clamav-devel] alarm() for freshclam?
Hello all, Recently I got a bug report for freshclam saying that a couple of times a month, the submitter finds freshclam stuck on a read from fd 4 (the network socket). So, freshclam gets stuck in the middle of a download and never returns. Looking things over, it looks to me like the simplest fix might be an alarm() inside downloadmanager (I think) with a handler that unlinks tempname, frees tempname, current (and maybe remote?) and closes hostfd. I guess it could also be set up to fork() before download, but the way that the post download hooks have been set up, it seems like fork()ing would be more difficult to manage. Let me know what you think - if you agree, I'll try to put something together. Thanks, -- -- | Stephen Gran | It is the nature of extreme self- | | [EMAIL PROTECTED] | lovers, as they will set an house on| | http://www.lobefin.net/~steve | fire, and it were but to roast their| || eggs. -- Francis Bacon| -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html
[Clamav-devel] discussion: Oversized.{Zip,RAR} and BLOCKMAX
Hello all, Recently I got a bug report that eventually boiled down to asking, "why aren't the Oversized.foo tests wrapped in an if (BLOCKMAX) test like the other archive checks?" My first reaction is that --block-max is not set by default, but this one test is important enough to be enabled by default. The submitter is not happy with my logic - they feel that if it is returning CL_VIRUS when it's not actually a virus, it should be governed by BLOCKMAX. So, I promised them that I would ask if there was something I was missing, and so I am. I am not asking to change the behavior, just asking for a discussion in case I'm missing something. I am well aware that you can't please all the people all the time, but I wanted to bring it up for discussion. Thanks, -- ------ | Stephen Gran | udp - universal dropping of an | | [EMAIL PROTECTED] | pigeon | | http://www.lobefin.net/~steve | | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html
Re: [Clamav-devel] libclamav alignment problem
On Mon, Nov 21, 2005 at 10:40:27PM +0100, Tomasz Kojm said: > On Sat, 13 Aug 2005 13:36:57 -0400 > Stephen Gran <[EMAIL PROTECTED]> wrote: > > > Background: > > The zip routines generate a SIGBUS on sparc64 due to alignment problems. > > The patch below fixes it, although not portably enough. > > I have implemented the fix in CVS. Much appreciated, thanks. -- ---------- | Stephen Gran | By trying we can easily learn to endure | | [EMAIL PROTECTED] | adversity. Another man's, I mean. -- | | http://www.lobefin.net/~steve | Mark Twain | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html
Re: [Clamav-devel] local setbit vs. mpz_setbit
On Sun, Oct 30, 2005 at 03:05:20PM +0100, Tomasz Kojm said:
> On Sun, 30 Oct 2005 13:54:47 +0000 Stephen Gran wrote:
> > On Mon, Oct 24, 2005 at 03:44:41PM +0100, Trog said:
> > > On Mon, 2005-10-24 at 09:01 +0100, Stephen Gran wrote:
> > >
> > > > But the implementation raised a question - the fix for the bug
> > > > is basically a reimplementation of some functions already
> > > > present in gmp, and gmp is already one of the libraries used at
> > > > compile time. Is there some reason to reimplement the function
> > > > locally instead of just using the ones already present? Is it
> > > > that you don't want to force building with gmp?
> > >
> > > gmp is optional.
> >
> > Well, I understand that it is literally optional - you can compile
> > clamav without it. However, since freshclam kicks up giant warnings
> > without it, it is effectively required. Is there some reason not to
> > just make it required? Does some platform that clamav wants to
> > support not also support libgmp?
>
> ClamAV is being used on embedded devices that don't support libgmp for
> various reasons.
Well, I guess I can understand that. Let me explain my misgivings.
Every time you reimplement something internally, it is prone to all the
bugs that the original has, with less scrutiny and a smaller testing base.
It seems like the kind of solution that lends itself to bitrot fairly
easily, so without a pressing reason, I tend to prefer using an already
available function in a well tested library.
I see that gmp is available for arm and mips{,el}, so I wouldn't have
thought they should be unable to use a couple of functions from it, but
if you feel strongly, I won't push it any more.
Take care,
--
--
| Stephen Gran | To one large turkey add one gallon of |
| [EMAIL PROTECTED] | vermouth and a demijohn of Angostura|
| http://www.lobefin.net/~steve | bitters. Shake. -- F. Scott |
|| Fitzgerald, recipe for turkey cocktail. |
--
signature.asc
Description: Digital signature
___
http://lurker.clamav.net/list/clamav-devel.html
Re: [Clamav-devel] local setbit vs. mpz_setbit
On Mon, Oct 24, 2005 at 03:44:41PM +0100, Trog said: > On Mon, 2005-10-24 at 09:01 +0100, Stephen Gran wrote: > > > But the implementation raised a question - the fix for the bug is > > basically a reimplementation of some functions already present in gmp, > > and gmp is already one of the libraries used at compile time. Is there > > some reason to reimplement the function locally instead of just using > > the ones already present? Is it that you don't want to force building > > with gmp? > > gmp is optional. > > -trog Well, I understand that it is literally optional - you can compile clamav without it. However, since freshclam kicks up giant warnigs without it, it is effectively required. Is there some reason not to just make it required? Does some platform that clamav wants to support not also support libgmp? Just sort of curious - it seems like more work than is necessary to reinvent the wheel. -- ---------- | Stephen Gran | BOFH excuse #149: Dew on the telephone | | [EMAIL PROTECTED] | lines. | | http://www.lobefin.net/~steve | | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html
[Clamav-devel] local setbit vs. mpz_setbit
Hello all, I just did a CVS checkout to see if CAN-2005-3239 was fixed in CVS yet. Sure enough it is (nice time to fix, BTW - thanks). But the implementation raised a question - the fix for the bug is basically a reimplementation of some functions already present in gmp, and gmp is already one of the libraries used at compile time. Is there some reason to reimplement the function locally instead of just using the ones already present? Is it that you don't want to force building with gmp? Thanks, -- -- | Stephen Gran | Q: What do you have when you have a | | [EMAIL PROTECTED] | lawyer buried up to his neck in sand? | | http://www.lobefin.net/~steve | A: Not enough sand. | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html
[Clamav-devel] FSF has new address
Hello all, The COPYING file has the old address for the FSF - it is now Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA. Could you please update it? Thanks, -- -- | Stephen Gran | Computer programmers never die, they| | [EMAIL PROTECTED] | just get lost in the processing.| | http://www.lobefin.net/~steve | | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html
Re: [Clamav-devel] VERSION command don't show the main database version
On Fri, Sep 02, 2005 at 12:20:46PM +0200, Justo Alonso said: > Why clamd version command don't show this information ?? > > I attach a patch to solve this. > > in the SOURCE/clamd directory: > > patch < patch.clamav.session.c > > thanks in advance Can you resend with the patch attached? I don't see it. Thanks, -- ------ | Stephen Gran | Is this going to involve RAW human | | [EMAIL PROTECTED] | ecstasy?| | http://www.lobefin.net/~steve | | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html
Re: [Clamav-devel] Multiple signedness mismatches
On Wed, Sep 07, 2005 at 06:58:09AM -0400, Dale Walsh said: > > On Aug 13, 2005, at 03:16 PM, Stephen Gran wrote: > > >Hello all, > > > >I see that gcc-4.x is much pickier about all sorts of things than the > >3.x series was, and emits warnings for any kind of mismatch. Most of > >them are admittedly harmless, but I do like seeing as clean a > >compile as > >possible. Would you be interested in a patch to clean up signedness > >issues? It is likely to be rather large, and tedious work, so I > >wanted > >to ask before spending the time on it. > > > >Take care, > > DId you ever work on this as you had suggested/offered??? I have (almost) finished a fairly disruptive transatlantic move, during which most of my computers were basically unusable for development work. Now that they are back on, and I am somewhat settled in, I am going to take a look at it. -- ------ | Stephen Gran | direct brain implants :)| | [EMAIL PROTECTED] | xtifr - yah, then using | | http://www.lobefin.net/~steve | computers would actually require some | || of these idiots to think! ;> | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html
[Clamav-devel] Multiple signedness mismatches
Hello all, I see that gcc-4.x is much pickier about all sorts of things than the 3.x series was, and emits warnings for any kind of mismatch. Most of them are admittedly harmless, but I do like seeing as clean a compile as possible. Would you be interested in a patch to clean up signedness issues? It is likely to be rather large, and tedious work, so I wanted to ask before spending the time on it. Take care, -- -- | Stephen Gran | My little brother got this fortune: | | [EMAIL PROTECTED] | nohup rm -fr /& So he did...| | http://www.lobefin.net/~steve | | -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html
[Clamav-devel] libclamav alignment problem
Background:
The zip routines generate a SIGBUS on sparc64 due to alignment problems.
The patch below fixes it, although not portably enough.
Can you all review the discussion at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=322396 and let me know
how you would like to fix it?
Thanks,
- Forwarded message from Clint Adams <[EMAIL PROTECTED]> -
From: Clint Adams <[EMAIL PROTECTED]>
To: Stephen Gran <[EMAIL PROTECTED]>
Date: Sat, 13 Aug 2005 13:06:37 -0400
Subject: Bug#322396: libclamav alignment problem
Cc: [EMAIL PROTECTED]
User-Agent: Mutt/1.5.9i
Reply-To: Clint Adams <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Delivery-date: Sat, 13 Aug 2005 13:22:33 -0400
X-Debian-PR-Message: report 322396
X-Debian-PR-Package: clamav-daemon
X-Debian-PR-Keywords: upstream
X-Scanned-By: ClamAV at mail.lobefin.net
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on mercury
So this patch fixes clamscan. I've switched back to using clamd to see
if it is happier.
I imagine that upstream will probably want a more portable fix, as this
requires gcc.
--- /tmp/zzip-zip.c 2005-08-13 12:37:05.966677144 -0400
+++ libclamav/zziplib/zzip-zip.c2005-08-13 12:37:51.226796560 -0400
@@ -616,7 +616,7 @@
{
zzip_error_t rv;
zzip_off_t filesize;
-struct zzip_disk_trailer trailer;
+struct zzip_disk_trailer trailer __attribute__ ((aligned (8)));
/* if (! dir || dir->fd < 0)
* { rv = EINVAL; goto error; }
*/
- End forwarded message -
--
----------
| Stephen Gran | "Even nowadays a man can't step up and |
| [EMAIL PROTECTED] | kill a woman without feeling just a bit |
| http://www.lobefin.net/~steve | unchivalrous ..." -- Robert Benchley |
--
signature.asc
Description: Digital signature
___
http://lurker.clamav.net/list/clamav-devel.html
[Clamav-devel] Unaligned trap on alpha (revisited)
Hello all,
I received the patch below (touched up so it applies to a recent version
of clamav). Could you please consider it for inclusion? It appears to
do the right thing for this, namely, making i386 assumptions only happen
on i386.
Thanks,
--
--
| Stephen Gran | new, adj.: Different color from|
| [EMAIL PROTECTED] | previous model. |
| http://www.lobefin.net/~steve | |
--
--- libclamav/upx.c.old 2005-06-23 16:03:12.0 -0400
+++ libclamav/upx.c 2005-08-04 08:33:17.0 -0400
@@ -193,7 +193,7 @@
static int doubleebx(char *src, int32_t *myebx, int *scur, int ssize)
{
int32_t oldebx = *myebx;
-#if WORDS_BIGENDIAN == 1
+#ifndef __i386__
char *pt;
int32_t shift, i = 0;
#endif
@@ -202,7 +202,7 @@
if ( !(oldebx & 0x7fff)) {
if (*scur<0 || ssize-*scur<4)
return -1;
-#if WORDS_BIGENDIAN == 0
+#ifndef __i386__
oldebx = *(int*)(src+*scur);
#else
oldebx = 0;
--- libclamav/others.c.old 2005-07-24 19:30:32.0 -0400
+++ libclamav/others.c 2005-08-04 08:32:16.0 -0400
@@ -573,8 +573,8 @@
{
int32_t ret;
-#if WORDS_BIGENDIAN == 0
-ret = *(int32_t *) buff;
+#if WORDS_BIGENDIAN == 0 && defined(__GNUC__)
+ret = ((struct { int32_t x; } __attribute__((packed)) *) buff)->x;
#else
ret = buff[0] & 0xff;
ret |= (buff[1] & 0xff) << 8;
signature.asc
Description: Digital signature
___
http://lurker.clamav.net/list/clamav-devel.html
Re: [Clamav-devel] RE: Clamd STREAM instability
On Fri, Jul 22, 2005 at 10:04:34AM -0400, Brian A. Reiter said: > > I am experiencing a problem with clamd crashing shortly after > > a scan using the STREAM protocol. This affects recent > > versions of clamd including 0.86.1 and clamav-devel in CVS > > running on Interix. > > I have spent a little time looking into this. The segv happens when the > thread pool spins down the worker threads after the idle timeout for the > thread has elapsed. However it only segvs if all of the following are true: > > scanstream() was queued to the worker thread > cfgopt(copt, "TCPSocket"))->enabled) == TRUE > cfgopt(copt, "TCPAddr"))->enabled) == TRUE > > That pretty much says to me that the code that causes the instability is the > call to gethostbyname(3) to get the sin_addr for binding the STREAM socket > because the alternate execution path of binding to INADDR_ANY is > trouble-free. > > I'm trying to decide if I should replace gethostbyname(3) and the pthread > locks with gethostbyname_r/lwres_gethostbyname_r(3) (reentrant) or if there > is something in BIND9 on Interix that is broken. > > It would help if I knew if this is a problem that can be reproduced on other > platforms than Interix. It does not appear to be reproducible on linux, either with a 2.4 or 2.6 kernel. I usually bind to 127.0.0.1, but have several machines that bind to one of the public interfaces. I have never experienced this crash on reload. It does sound like perhaps the implementation of gethostbyname is not reeentrant. Take care, -- -- | Stephen Gran | "Ask not what A Group of Employees can | | [EMAIL PROTECTED] | do for you. But ask what can All | | http://www.lobefin.net/~steve | Employees do for A Group of Employees." | || -- Mike Dennison| -- signature.asc Description: Digital signature ___ http://lurker.clamav.net/list/clamav-devel.html
Re: [Clamav-devel] configure.in and SENDMAIL_VERSION*
On Sun, Jun 19, 2005 at 12:38:58AM +0200, Tomasz Kojm said:
> On Sat, 18 Jun 2005 14:20:20 -0400
> Stephen Gran <[EMAIL PROTECTED]> wrote:
>
> > the following patch corrects this,a nd results in
> > /* #undef SENDMAIL_VERSION_A */
> > which is correct if sendmail is not installed
>
> Fixed in CVS.
The second part of this patch, to make it compile with gcc-4.0
(currently complains about no left operand)
--- clamav-milter/clamav-milter.c.old 2005-06-19 13:13:40.157521584 -0400
+++ clamav-milter/clamav-milter.c 2005-06-19 13:15:57.435610442 -0400
@@ -1054,9 +1054,11 @@
if(cfgopt(copt, "LogVerbose")) {
logVerbose = 1;
+#if defined SENDMAIL_VERSION_A && defined SENDMAIL_VERSION_B
#if((SENDMAIL_VERSION_A > 8) || ((SENDMAIL_VERSION_A == 8) &&
(SENDMAIL_VERSION_B >= 13)))
smfi_setdbg(6);
#endif
+#endif
}
use_syslog = 1;
@@ -1573,12 +1575,14 @@
return EX_UNAVAILABLE;
}
+#if defined SENDMAIL_VERSION_A && defined SENDMAIL_VERSION_B
#if((SENDMAIL_VERSION_A > 8) || ((SENDMAIL_VERSION_A == 8) &&
(SENDMAIL_VERSION_B >= 13)))
if(smfi_opensocket(1) == MI_FAILURE) {
cli_errmsg("Can't open/create %s\n", port);
return EX_CONFIG;
}
#endif
+#endif
signal(SIGPIPE, SIG_IGN); /* libmilter probably does this as well
*/
Thanks,
--
--
| Stephen Gran | Let us live!!! Let us love!!! Let us|
| [EMAIL PROTECTED] | share the deepest secrets of our|
| http://www.lobefin.net/~steve | souls!!! You first.|
--
signature.asc
Description: Digital signature
___
http://lurker.clamav.net/list/clamav-devel.html
[Clamav-devel] configure.in and SENDMAIL_VERSION*
Hello all,
the tests in configure.in (and finally configure) do the wrong thing for
the SENDMAIL_VERSION* macros if sendmail isn't found. Currently they
define SENDMAIL_VERSION_A and so forth, but give them a null value, like
#define SENDMAIL_VERSION_A
the following patch corrects this,a nd results in
/* #undef SENDMAIL_VERSION_A */
which is correct if sendmail is not installed
--- configure.in.old2005-06-18 14:16:23.345795850 -0400
+++ configure.in2005-06-18 14:12:20.830173318 -0400
@@ -172,14 +172,15 @@
AC_DEFINE_UNQUOTED(SENDMAIL_BIN, "$sendmailprog", [location of Sendmail
binary])
sendmailver=`$sendmailprog -d0 < /dev/null | head -1 | awk '{print $2}'`
- sendmailver_a=`echo $sendmailver | awk -F. '{printf $1}'`
- sendmailver_b=`echo $sendmailver | awk -F. '{printf $2}'`
- sendmailver_c=`echo $sendmailver | awk -F. '{printf $3}'`
-
- AC_DEFINE_UNQUOTED(SENDMAIL_VERSION_A, $sendmailver_a, [major version of
Sendmail])
- AC_DEFINE_UNQUOTED(SENDMAIL_VERSION_B, $sendmailver_b, [minor version of
Sendmail])
- AC_DEFINE_UNQUOTED(SENDMAIL_VERSION_C, $sendmailver_c, [subversion of
Sendmail])
-
+ if test -n "$sendmailver"; then
+sendmailver_a=`echo $sendmailver | awk -F. '{printf $1}'`
+sendmailver_b=`echo $sendmailver | awk -F. '{printf $2}'`
+sendmailver_c=`echo $sendmailver | awk -F. '{printf $3}'`
+
+AC_DEFINE_UNQUOTED(SENDMAIL_VERSION_A, $sendmailver_a, [major version of
Sendmail])
+AC_DEFINE_UNQUOTED(SENDMAIL_VERSION_B, $sendmailver_b, [minor version of
Sendmail])
+AC_DEFINE_UNQUOTED(SENDMAIL_VERSION_C, $sendmailver_c, [subversion of
Sendmail])
+ fi
fi
AC_ARG_ENABLE(dsig,
Thanks,
--
--
| Stephen Gran | A woman can look both moral and |
| [EMAIL PROTECTED] | exciting -- if she also looks as if it |
| http://www.lobefin.net/~steve | were quite a struggle. -- Edna Ferber |
--
signature.asc
Description: Digital signature
___
http://lurker.clamav.net/list/clamav-devel.html
[Clamav-devel] milter and verifyIncomingSocketName
Hey all,
I would appreciate a way to skip the test in verifyIncomingSocketName.
It is a useful thing, but it can be too smart for itself sometimes, at
least IMHO. It can break things like unattended installs (or even fresh
installs) and also prevent running it on a currently non-sendmail system
if you still have a sendmail.cf laying around (I found this out after
moving my laptop away from sendmail a few months ago). I agree that it
should be the default to check for socket agreement, but I just want to
be able to bypass it in some circumstances.
The attached patch does so, and my feelings won't be hurt if you come up
with better long and short option names :)
Thanks,
--- clamav-milter/clamav-milter.c.old 2005-06-11 11:37:22.889679067 -0400
+++ clamav-milter/clamav-milter.c 2005-06-11 11:37:02.364168670 -0400
@@ -391,6 +391,7 @@
* claiming to be from us that must be false
* Requires that -o, -l or -f are NOT given
*/
+static short check_socket = 1;
static short use_syslog = 0;
static const char*pidFile;
static int logVerbose = 0;
@@ -471,6 +472,7 @@
puts(_("\t--config-file=FILE\t-c FILE\tRead configuration from FILE."));
puts(_("\t--debug\t\t\t-D\tPrint debug messages."));
puts(_("\t--detect-forged-local-address\t-L\tReject mails that claim to
be from us."));
+ puts(_("\t--dont-check-socket\t-Z\tDon't add an entry to syslog that a
mail is clean."));
puts(_("\t--dont-log-clean\t-C\tDon't add an entry to syslog that a
mail is clean."));
puts(_("\t--dont-scan-on-error\t-d\tPass e-mails through unscanned if a
system error occurs."));
puts(_("\t--dont-wait\t\t\tAsk remote end to resend if max-children
exceeded."));
@@ -567,9 +569,9 @@
for(;;) {
int opt_index = 0;
#ifdef CL_DEBUG
- const char *args =
"a:AbB:c:CdDefF:lLm:nNop:PqQ:hHs:St:T:U:VwW:x:0:";
+ const char *args =
"a:AbB:c:CdDefF:lLm:nNop:PqQ:hHs:St:T:U:VwW:x:0:Z";
#else
- const char *args =
"a:AbB:c:CdDefF:lLm:nNop:PqQ:hHs:St:T:U:VwW:0:";
+ const char *args =
"a:AbB:c:CdDefF:lLm:nNop:PqQ:hHs:St:T:U:VwW:0:Z";
#endif
static struct option long_options[] = {
@@ -591,6 +593,9 @@
{
"detect-forged-local-address", 0, NULL, 'L'
},
+ {
+ "dont-check-socket", 0, NULL, 'Z'
+ },
{
"dont-log-clean", 0, NULL, 'C'
},
@@ -810,6 +815,9 @@
case 'x':
debug_level = atoi(optarg);
break;
+ case 'Z':
+ check_socket = 0;
+ break;
#endif
default:
#ifdef CL_DEBUG
@@ -830,9 +838,11 @@
}
port = argv[optind];
- if(verifyIncomingSocketName(port) < 0) {
- fprintf(stderr, _("%s: socket-addr (%s) doesn't agree with
sendmail.cf\n"), argv[0], port);
- return EX_CONFIG;
+ if(check_socket) {
+ if(verifyIncomingSocketName(port) < 0) {
+ fprintf(stderr, _("%s: socket-addr (%s) doesn't agree
with sendmail.cf\n"), argv[0], port);
+ return EX_CONFIG;
+ }
}
if(strncasecmp(port, "inet:", 5) == 0)
if(!lflag) {
--- docs/man/clamav-milter.8.old2005-06-11 11:45:59.845854961 -0400
+++ docs/man/clamav-milter.82005-06-11 11:45:48.091716819 -0400
@@ -227,6 +227,11 @@
When starting, clamav\-milter runs some sanity checks against the sendmail.cf
file, usually in /etc/sendmail.cf or /etc/mail/sendmail.cf. This directive
tells clamav\-milter where to find the sendmail.cf file.
+.TP
+\fB\-\-dont-check-socket, \-Z\fR
+When starting, clamav\-milter runs some sanity checks against the sendmail.cf
+file, usually in /etc/sendmail.cf or /etc/mail/sendmail.cf. This directive
+disables those tests.
.SH "BUGS"
There is no support for IPv6.
.SH "EXAMPLES"
--
--
| Stephen Gran | Body by Nautilus, Brain by Mattel. |
| [EMAIL PROTECTED] | |
| http://www.lobefin.net/~steve | |
--
signature.asc
Description: Digital signature
___
http://lurker.clamav.net/list/clamav-devel.html
[Clamav-devel] output patch
Hello all, I have written a patch that simplifies output handling for all the clamav programs - it moves most of the logic of how to handle output into the logg() function, and changes all of the programs to use logg() instead of the many functions they currently use (mdprintf, mprintf, printf, cli_*msg, etc). It shortens the code base by several hundred lines, and I believe it does so with no loss of functionality. The reason for this patch is that I recently noticed that several programs were using the cli_*msg calls to write warnings, even when daemonized. Also, syslog vs. LogFile was handled differently across programs. This means that I was not seeing potentially important information in the logs of my headless servers across town. This patch will (hopefully) allow all information to go to whatever logfile it should, while still letting programs that write to stdout/stderr to do so without any problems. The usual disclaimers apply - it is a large patch, so I assume I have missed something. I have a feeling that in particualr, clamav-milter will need some looking over to make sure I have done nothing seriously wrong there. The patch can be found at http://lobefin.net/~steve/clamav-output-patch-round2.gz It is about 35K zipped, so I didn't want to just send it to the list. Thanks all, -- -- | Stephen Gran | Do you realize how many holes there | | [EMAIL PROTECTED] | could be if people would just take the | | http://www.lobefin.net/~steve | time to take the dirt out of them? | -- pgp7qVm0YOdZH.pgp Description: PGP signature ___ http://lurker.clamav.net/list/clamav-devel.html
Re: [Clamav-devel] Extremely high load
On Tue, May 31, 2005 at 03:26:47PM -0300, Aecio F. Neto said: > I will give it try. Just to understand the big picture here: is there > any known performance issue in clamav for linux using sparc? Or any > other option/lib I should be worried about? There is one that I know of: part of the Portable Executable routine aligns data on a 32 bit boundary, which means the kernel has to do some memory adjustment on 64 bit platforms. This does slow things down a bit, although not as hugely as what you are seeing. There is a patch in the Debian bug tracking system for this issue, but I have yet to hear back from the team members about it. The patch and report are viewable at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=289187 if you want to rule out that issue first. I doubt that will make the kind of difference needed, though. HTH, -- -- | Stephen Gran | We are governed not by armies and | | [EMAIL PROTECTED] | police but by ideas. -- Mona Caird, | | http://www.lobefin.net/~steve | 1892| -- pgpKV5OPezr8g.pgp Description: PGP signature ___ http://lurker.clamav.net/list/clamav-devel.html
[Clamav-devel] documentation typo fixes
Attached is a patch that I believe catches all the manpage typos. Probably a few of the changes are due to differences between American and British English, and can be ignored. Most of them are just typos, however. Thanks, -- -- | Stephen Gran | What's this stuff about people being| | [EMAIL PROTECTED] | "released on their own recognizance"? | | http://www.lobefin.net/~steve | Aren't we all out on our own| || recognizance? | -- diff -Nru clamav-devel-latest.old/docs/man/clamav-milter.8 clamav-devel-latest/docs/man/clamav-milter.8 --- clamav-devel-latest.old/docs/man/clamav-milter.82005-05-13 09:30:51.0 -0400 +++ clamav-devel-latest/docs/man/clamav-milter.82005-05-24 10:22:36.439299626 -0400 @@ -58,7 +58,7 @@ \fB\-x n, \-\-debug\-level=n\fR Set the debug level to n (where n from [0..9]) if \fBclamav\-milter\fR was configured and compiled with \-\-clamav-debug enabled. -Will be replaced by \-\-debug for compatability with other programs in the +Will be replaced by \-\-debug for compatibility with other programs in the suite. .TP \fB-A, \-\-advisory\fR @@ -76,7 +76,7 @@ When a virus is intercepted, broadcast a UDP message to the TCPSocket port set in \fBclamd.conf\fR. If the optional \fIiface\fR option is given, broadcasts will be sent on -that interface. The default is set by the opertating system, usually to the +that interface. The default is set by the operating system, usually to the first NIC. A future network management program (yet to be written) will intercept these broadcasts to raise a warning on the operator's desk. @@ -92,7 +92,7 @@ generally causes the message to remain in the queue. .TP \fB-f, \-\-force-scan\fR -Always scan, whereever the message came from (see also --local and --outgoing). +Always scan, wherever the message came from (see also --local and --outgoing). You probably don't want this. .TP \fB-e, \-\-external\fR @@ -151,13 +152,12 @@ .TP \fB-U, \-\-quarantine-dir=DIR\fR If this option is given, infected files are left in this directory. -The directory must not be publically readable or writeable, if it is, +The directory must not be publically readable or writable, if it is, clamav\-milter will issue an error and fail to start. \fBNote\fR - this option only works when using LocalSocket. .TP \fB\-\-server=HOSTNAME/ADDRESS, \-s HOSTNAME/ADDRESS\fR @@ -207,9 +207,9 @@ sendmail. .TP \fB\-\-timeout=n \-T n\fR -Used in conjuction with max\-children. If clamav\-milter waits for more than +Used in conjunction with max\-children. If clamav\-milter waits for more than \fIn\fR seconds (default 0) it proceeds with scanning. Setting \fIn\fR to zero -will turn off the timeout and clamav\-milter will wait indefinately for the +will turn off the timeout and clamav\-milter will wait indefinitely for the scanning to quit. In practice the timeout set by sendmail will then take over. .TP \fB\-\-detect-forged-local-address \-L\fR diff -Nru clamav-devel-latest.old/docs/man/clamd.conf.5.in clamav-devel-latest/docs/man/clamd.conf.5.in --- clamav-devel-latest.old/docs/man/clamd.conf.5.in2005-02-13 18:01:50.0 -0500 +++ clamav-devel-latest/docs/man/clamd.conf.5.in2005-05-24 10:22:57.097723713 -0400 @@ -146,7 +146,7 @@ Default: disabled .TP \fBExitOnOOM\fR -Stop deamon when libclamav reports out of memory condition. +Stop daemon when libclamav reports out of memory condition. .br Default: disabled .TP @@ -210,7 +210,7 @@ Default: enabled .TP \fBScanHTML\fR -Enables HTML detection and normalisation. +Enables HTML detection and normalization. .br Default: enabled .TP @@ -255,7 +255,7 @@ Default: 250 .TP \fBArchiveLimitMemoryUsage\fR -Use slower decompression algorithm which uses less memory. This option affects bzip2 decompressor only. +Use slower decompression algorithm which uses less memory. This option affects bzip2 decompresser only. .br Default: disabled .TP @@ -290,7 +290,7 @@ Default: disabled .TP \fBClamukoIncludePath STRING\fR -Set the include paths (all files and directories in them will be scanned). You can have multiple ClamukoIncludePath directives but each directory must be added in a seperate line). +Set the include paths (all files and directories in them will be scanned). You can have multiple ClamukoIncludePath directives but each directory must be added in a separate line). .br Default: disabled .TP diff -Nru clamav-devel-latest.old/docs/man/clamscan.1 clamav-devel-latest/docs/man/clamscan.1 --- clamav-devel-latest.old/docs/man/clamscan.1 2005-05-10 20:54:13.0 -0400 +++ clamav-devel-latest/docs/man/clamscan.1 2005-05-24 10:24:04.479752294 -0400 @@ -38,7 +38,7 @@ Save s
Re: [Clamav-devel] request some help on virus samples
On Thu, Apr 28, 2005 at 09:04:42AM +0100, Trog said: > Please don't help to spread viruses in this way. If he's a researcher, > then I'm the new pope. All hail pope Trog I! -- ------ | Stephen Gran | Overdrawn? But I still have checks | | [EMAIL PROTECTED] | left! | | http://www.lobefin.net/~steve | | -- pgpJ01r3os5rm.pgp Description: PGP signature ___ http://lurker.clamav.net/list/clamav-devel.html
[Clamav-devel] Re: [Clamav-users] Another race condition in ClamAV ??
On Sun, Apr 24, 2005 at 07:24:51PM -0400, Dale Walsh said: > > If freshdb overwrite the virus databases when clamd was in the middle > of reloading them, clamd might end up having loaded corrupted > databases. Does everyone agree that such a window exists ? The freshclam part is atomic - it downloads to a tempfile, and then renames to a real name. There does exist the possibility of clamd noticing that one db is updated while freshclam is still downloading the second, and reloading only the first one. Since freshclam will issue the RELOAD command after downloading the second one, I am not sure what the harm is (except for possibly a few wasted cycles redoing the reload spin cycle). clamd should not, AIUI, attempt a reload unless it either receives the RELOAD command, or it notices the databases have changed. ergo, it should not reload before an update, only after. If I'm missing something, please enlghten me. -- ------ | Stephen Gran | Never put off until tomorrow what you | | [EMAIL PROTECTED] | can do today. There might be a law | | http://www.lobefin.net/~steve | against it by that time.| -- pgpLpOxGHFEL1.pgp Description: PGP signature ___ http://lurker.clamav.net/list/clamav-devel.html
Re: [Clamav-devel] Re: [Clamav-announce] announcing ClamAV 0.84rc1
On Tue, Apr 12, 2005 at 02:10:15AM +0200, Tomasz Kojm said: > On Thu, 7 Apr 2005 17:54:58 -0500 (CDT) > Damian Menscher <[EMAIL PROTECTED]> wrote: > > > I was hoping that clmilter_watch would make it into this release. Was > > it intentionally omitted, or was it just an oversight? It's available > > at http://www.itg.uiuc.edu/itg_software/clmilter_watch/ and is > > Have you got any feedback on this tool? How long was the testing period? I have been using it on a couple of machines for a couple of weeks now, so far with no false results. I helped (slightly) during the debugging period prior to that. As I don't know enough about the milter protocol itself, I can't comment on the API used, except to say that it works well. Take care, -- ------ | Stephen Gran | BOFH excuse #390: Increased sunspot| | [EMAIL PROTECTED] | activity. | | http://www.lobefin.net/~steve | | -- pgph1DCqTCZWx.pgp Description: PGP signature ___ http://lurker.clamav.net/list/clamav-devel.html
Re: [Clamav-devel] Minor freshclam debugging output patch
On Fri, Mar 04, 2005 at 03:17:33AM +0100, Tomasz Kojm said:
> On Wed, 16 Feb 2005 21:30:51 -0500
> Stephen Gran <[EMAIL PROTECTED]> wrote:
>
> > --- freshclam/manager.c.old 2005-01-26 19:32:57.0 -0500
> > +++ freshclam/manager.c 2005-02-16 21:27:50.483773976 -0500
> > @@ -280,6 +280,7 @@
> > return 52;
> > } else {
> > mprintf("*Connected to %s (IP: %s).\n", hostname, ipaddr);
> > + mprintf("*Trying to retrieve http://%s/%s\n";, hostname,
> > localname);
>
> s/localname/remotename
>
> > +mprintf("*Retrieving http://%s/%s\n";, hostname, localname);
>
> s/localname/remotename
Right - sorry. Wrote that too close to bedtime, I see :)
> Applied in CVS.
Thanks,
--
--
| Stephen Gran | Convention is the ruler of all. --|
| [EMAIL PROTECTED] | Pindar |
| http://www.lobefin.net/~steve | |
--
pgp6ghurPzT4t.pgp
Description: PGP signature
___
http://lurker.clamav.net/list/clamav-devel.html
[Clamav-devel] [oo...@users.sf.net: Re: Bug#295547: clamav-freshclam: seems that there's no way to pass RC to eg. OnErrorExecute script(s)]
otified: Could not write to %s socket\n",
socktype);
perror("write()");
close(sockd);
- return 1;
+ return 98;
}
/* TODO: Handle timeout */
@@ -126,7 +126,7 @@
if(!strstr(buff, "RELOADING")) {
mprintf("@Clamd was NOT notified: Unknown answer from clamd:
'%s'\n", buff);
close(sockd);
- return 1;
+ return 99;
}
close(sockd);
diff -urN clamav-0.83/freshclam/options.c clamav-0.83.1/freshclam/options.c
--- clamav-0.83/freshclam/options.c Sat Feb 12 00:02:44 2005
+++ clamav-0.83.1/freshclam/options.c Fri Feb 18 16:16:21 2005
@@ -38,7 +38,7 @@
int ret, opt_index, i, len;
struct optstruct *opt;
- const char *getopt_parameters = "hvdp:Vl:c:u:";
+ const char *getopt_parameters = "hvdfp:Vl:c:u:";
static struct option long_options[] = {
/*
@@ -55,6 +55,7 @@
{"log-verbose", 0, 0, 0}, /* not used */
{"stdout", 0, 0, 0},
{"daemon", 0, 0, 'd'},
+ {"foreground", 0, 0, 'f'},
{"pid", 1, 0, 'p'},
{"user", 1, 0, 'u'}, /* not used */
{"config-file", 1, 0, 0},
- End forwarded message -
--
--
| Stephen Gran | "Whatever the missing mass of the |
| [EMAIL PROTECTED] | universe is, I hope it's not|
| http://www.lobefin.net/~steve | cockroaches!" -- Mom |
--
pgpcNKripO0H8.pgp
Description: PGP signature
___
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-devel
Re: [Clamav-devel] freshclam signal bug
On Thu, Feb 17, 2005 at 09:36:55AM +, Trog said: > On Wed, 2005-02-16 at 12:53 -0500, Stephen Gran wrote: > > On Wed, Feb 09, 2005 at 09:04:52PM -0500, Stephen Gran said: > > > Hello all, > > > > > > It seems that freshclam can be hung if it receives a HUP shortly after > > > receiving an alrm (that is, when waking up to check for a new version). > > > > OK, so some further research shows it to be a problem because the logg*() > > code is threaded (ifdef CL_THREAD_SAFE, of course), but freshclam does > > not itself use threads. > > > > The logg() code isn't threaded per se, but does use a mutex. The correct > solution to this is to remove the logg() call in the signal handler. OK, will that be done? -- -- | Stephen Gran | Some husbands are living proof that a | | [EMAIL PROTECTED] | woman can take a joke. | | http://www.lobefin.net/~steve | | -- pgphandbecEwv.pgp Description: PGP signature ___ http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-devel
[Clamav-devel] Minor freshclam debugging output patch
Hello all,
As you may be guessing, this is my week for 'clean up those minor
annoyances' - you guys are doing a good enough job clearing out the
major ones, and my c is still a little rusty to chase around some of the
others. That being said, I have had (in the past, before I got a little
better at reading the output) a minor issue with freshclam's debugging
output on failed database downloads, so I thought I might try to add a
little clarity for help debugging in case of failure. This patch only
lets you know the url that is being tried for download, to guide people
in debugging problems. It is minor and harmless, but no hard feelings
if it seems like more cruft.
--- freshclam/manager.c.old 2005-01-26 19:32:57.0 -0500
+++ freshclam/manager.c 2005-02-16 21:27:50.483773976 -0500
@@ -280,6 +280,7 @@
return 52;
} else {
mprintf("*Connected to %s (IP: %s).\n", hostname, ipaddr);
+ mprintf("*Trying to retrieve http://%s/%s\n";, hostname, localname);
}
if(!ip[0])
@@ -350,6 +351,7 @@
*/
tempname = cli_gentemp(".");
+mprintf("*Retrieving http://%s/%s\n";, hostname, localname);
if((ret = get_database(remotename, hostfd, tempname, hostname, proxy,
user, pass))) {
mprintf("@Can't download %s from %s (IP: %s)\n", remotename, hostname,
ipaddr);
unlink(tempname);
--
------
| Stephen Gran | Most places distinguish them merely by |
| [EMAIL PROTECTED] | using the appropriate value. Hooray for |
| http://www.lobefin.net/~steve | context... -- Larry Wall |
|| in <[EMAIL PROTECTED]> |
--
pgpoHMh0J2Tbs.pgp
Description: PGP signature
___
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-devel
Re: [Clamav-devel] freshclam signal bug
On Wed, Feb 09, 2005 at 09:04:52PM -0500, Stephen Gran said: > Hello all, > > It seems that freshclam can be hung if it receives a HUP shortly after > receiving an alrm (that is, when waking up to check for a new version). OK, so some further research shows it to be a problem because the logg*() code is threaded (ifdef CL_THREAD_SAFE, of course), but freshclam does not itself use threads. I can see a couple of ways of patching this, but I wanted to know what the devlopment team thought would be the way to move forward before changing anything. I was thinking of something passed to logg() in the way that (!|*|etc) are currently passed, and do an if .. else block to determine whether or not to use pthreads. Then for logg_close() and the others, I guess passing something small, like a single char or a bool, would do the same. As this involves a fair amount of patching, I wanted to make sure that that approach seemed sane before starting on it. Other ideas also welcome. The last thing I want to do is split out new logg*() functions just for freshclam, or introduce threads into freshclam, but I would like to get this fixed at some point. As it is not something that happens all the time (and needs a fair amount of luck to hit, in fact) this is not a high priority project for me, but as it turns out I have a little time to devote to fixing some nagging things. Thanks, -- ------ | Stephen Gran | All your people must learn before you | | [EMAIL PROTECTED] | can reach for the stars. -- Kirk, | | http://www.lobefin.net/~steve | "The Gamesters of Triskelion", stardate | || 3259.2 | -- pgp4E7eHMSLEs.pgp Description: PGP signature ___ http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-devel
[Clamav-devel] milter pidfile removal
Hello,
The attached patch removes the pidfile on shutdown for the milter. Low
priority, but it would be nice if it could clean up after itself fully
:)
--- clamav-0.83.old/clamav-milter/clamav-milter.c 2005-02-13
16:44:28.0 -0500
+++ clamav-0.83/clamav-milter/clamav-milter.c 2005-02-16
12:31:24.622042712 -0500
@@ -794,6 +794,7 @@
static voidquit(void);
static voidbroadcast(const char *mess);
static int loadDatabase(void);
+const char *pidfile = NULL;
#ifdef SESSION
static pthread_mutex_t version_mutex = PTHREAD_MUTEX_INITIALIZER;
@@ -5047,6 +5048,9 @@
perror(tmpdir);
broadcast(_("Stopping clamav-milter"));
+ if (pidfile) {
+ unlink(pidfile);
+ }
}
static void
--
--
| Stephen Gran | Go slowly to the entertainments of thy |
| [EMAIL PROTECTED] | friends, but quickly to their |
| http://www.lobefin.net/~steve | misfortunes. -- Chilo |
--
pgpUKJYnERwsx.pgp
Description: PGP signature
___
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-devel
Re: [Clamav-devel] libtool in acinclude.m4
On Tue, Feb 15, 2005 at 05:00:49PM +0300, -=MikeP=- said: > Hello Tomasz, > > Tuesday, February 15, 2005, 4:10:03 PM, you wrote: > > TK> On Tue, 15 Feb 2005 16:13:48 +0300 TK> -=MikeP=- > <[EMAIL PROTECTED]> wrote: > > >> 1) is it possible to remove libtool from acinclude.m4 in future > >> versions so that there is possibility to build environment with > >> system's libtool. > > TK> No, it isn't. > > >> 2) What info (patches in what form) should be sent to support > > TK> Unified patches generated with diff. > > > Well, then each time I download a new version of ClamAV I have to cut > libtool.m4 from acinclude.m4 and then rebuild the full environment, > otherwise configure can not determine linker characteristics and I'm > unable to build the source... > > Is there a way to add QNX specific sections to libtool.m4 that you use > in acinclude.m4? what info then should I send you about QNX linker? There are macros to detect OS version and so forth, and then set variables appropriately. A patch that properly detected QNX6 and then did the right thing (skipped the part you have to cut or something) would probably do it. -- -- | Stephen Gran | Weekends were made for programming. - | | [EMAIL PROTECTED] | Karl Lehenbauer | | http://www.lobefin.net/~steve | | -- pgp5LSNRrIBwW.pgp Description: PGP signature ___ http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-devel
[Clamav-devel] possibility of adding AM_MAINTAINER_MODE
Hello all, Would it be possible to add AM_MAINTAINER_MODE to configure.in? Every time a new upstream comes out, I have to patch acinclude.m4 to link correctly for some odd arches (Debian has a patched libtool), and this requires a rebuilding of all the auto* stuff. The problem I run across is that subsequent rebuilds always try to also rebuild, because of timestamp skew introduced by the patching, and sometimes this can cause failures. AM_MAINTAINER_MODE fixes this for me. It also still allows rebuilding manually by passing --enable-maintainer-mode to ./configure, so it seems nothing is lost. If you like, I can send a patch. Thanks, -- -- | Stephen Gran | "Life, loathe it or ignore it, you | | [EMAIL PROTECTED] | can't like it." -- Marvin,| | http://www.lobefin.net/~steve | "Hitchhiker's Guide to the Galaxy" | -- pgp7xyhK5WSAc.pgp Description: PGP signature ___ http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-devel
[Clamav-devel] freshclam signal bug
Hello all,
It seems that freshclam can be hung if it receives a HUP shortly after
receiving an alrm (that is, when waking up to check for a new version).
The last several lines of an strace reveal:
rt_sigaction(SIGALRM, {0x804ac70, [],
SA_RESTORER|SA_STACK|SA_RESTART|SA_INTERRUPT|SA_ONESHOT|0x3fff608, 0x8050036},
{SIG_DFL}, 8) = 0
rt_sigaction(SIGUSR1, {0x804ac70, [],
SA_RESTORER|SA_STACK|SA_RESTART|SA_INTERRUPT|SA_ONESHOT|0x3fff608, 0x8050036},
{SIG_DFL}, 8) = 0
time([1107999334]) = 1107999334
alarm(7200) = 0
pause() = ? ERESTARTNOHAND (To be restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---
write(3, "Received signal 14, wake up\n", 28) = 28
--- SIGHUP (Hangup) @ 0 (0) ---
futex(0x8051a6c, FUTEX_WAIT, 2, NULL
And there it hangs. The last thing in the logfile is
--
Received signal 1, re-opening log file
In other words, it never logs the wake up line. To reproduce, run
freshclam as a daemon, let it get to the pause(), and then do:
PID=`cat /var/run/clamav/freshclam.pid`; kill -ALRM $PID ; kill -HUP $PID
Thanks, and let me know of I can be of any assistance,
--
--
| Stephen Gran | Ever get the feeling that the world's |
| [EMAIL PROTECTED] | on tape and one of the reels is |
| http://www.lobefin.net/~steve | missing? -- Rich Little |
--
___
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-devel
[Clamav-devel] libclamav output functions
Hello all, In libclamav/others.c, I see that the output functions (cli_warnmsg, cli_errmsg, and cli_dbgmsg) don't use the mprintf function in shared/output.c, so they bypass things like the --stdout switch. A user noticed that messages on stderr about his functionality level was causing amavis to incorrectly reject messages because of this. Before you ask, I have no idea why he wanted clamscan as a primary scanner instead of clamdscan, but there it is. I have advised him to fix up his configuration in the meantime. It does, however, seem like this is something that could trivially be fixed to be consistent. Thanks, -- -- | Stephen Gran | "Fantasies are free." "NO!! NO!! It's | | [EMAIL PROTECTED] | the thought police" | | http://www.lobefin.net/~steve | | -- pgpWNZDzS6wBS.pgp Description: PGP signature ___ http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-devel
[Clamav-devel] signal handling in milter
Hello all, It appears that signal handling in the milter has gotten significantly worse in 0.81 - it now no longer responds to a kill on linux 2.4 kernels, as far as my tests show. This is true so far with and without --external, as far as I can tell. Also note this strange behavior: [EMAIL PROTECTED]:~$ ps -el | egrep '(PID|clamav-milter)' F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD [EMAIL PROTECTED]:~$ sudo /etc/init.d/clamav-milter start Starting Sendmail milter plugin for ClamAV: clamav-milter [EMAIL PROTECTED]:~$ ps -el | egrep '(PID|clamav-milter)' F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD 040 S 105 19279 1 0 70 0 - 1126 select ?00:00:00 clamav-milter 040 S 105 19280 19279 0 70 0 - 1126 poll ?00:00:00 clamav-milter 040 S 105 19281 19280 0 69 0 - 1126 rt_sig ?00:00:00 clamav-milter (second term) [EMAIL PROTECTED]:~$ sudo /etc/init.d/clamav-milter stop Stopping Sendmail milter plugin for ClamAV: Waiting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Failed.. clamav-milter (sorry about the bad wrap) But back on the first term, while waiting for failure, I see: [EMAIL PROTECTED]:~$ ps -el | egrep '(PID|clamav-milter)' F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD 040 S 105 19279 1 0 69 0 - 1126 select ?00:00:00 clamav-milter 040 S 105 19280 19279 0 69 0 - 1126 poll ?00:00:00 clamav-milter 040 S 105 19281 19280 0 69 0 - 1126 rt_sig ?00:00:00 clamav-milter 100 S 0 19348 1381 0 76 0 - 596 wait4 pts/000:00:00 clamav-milter [EMAIL PROTECTED]:~$ w 23:51:51 up 105 days, 14:02, 2 users, load average: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT stevepts/0gashuffer.lobefi 09:282.00s 0.66s 0.04s mutt stevepts/1gashuffer.lobefi 23:240.00s 0.15s 0.01s w Where did that extra one come from? It's in a wait state, and it's controlling TTY is the TTY of the kill process? This makes no sense to me. It appears that something went wrong here, but I am not sure what. kill -9 still works, but that is the only thing that works. -- ------ | Stephen Gran | Arnold's Addendum: Anything not| | [EMAIL PROTECTED] | fitting into these categories causes| | http://www.lobefin.net/~steve | cancer in rats. | -- pgpA6ch2e4h1S.pgp Description: PGP signature ___ http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-devel
Re: [Clamav-devel] shared/ouput.c
On Sun, Jan 16, 2005 at 02:09:16PM -0500, Stephen Gran said:
> Hello all,
>
> I have asked for this before, I think, but it would be really nice if
> output from the various clam binaries went to different file desriptors,
> depending on whether they are errors, warnings, or informative. This
> would more easily filtering of output in things like cron jobs and the
> like. I believe the attached patch does so.
I think this patch is maybe a little smarter:
--
------
| Stephen Gran | fortune: cpu time/usefulness ratio too |
| [EMAIL PROTECTED] | high -- core dumped.|
| http://www.lobefin.net/~steve | |
--
--- clamav-devel-latest/shared/output.c 2004-10-16 20:48:02.0 -0400
+++ output.c2005-01-16 18:33:13.0 -0500
@@ -240,10 +240,7 @@
return;
}
-if(mprintf_stdout)
- fd = stdout;
-else
- fd = stderr;
+fd = stdout;
/* legend:
* ! - error
@@ -253,11 +250,11 @@
/*
* ERRORWARNINGSTANDARD
- * normal yes yesyes
+ * normal stderr stderr stdout
*
- * verbose yes yesyes
+ * verbose stderr stderr stdout
*
- * quietyes no no
+ * quiet stderr no no
*/
@@ -266,9 +263,13 @@
va_start(argscpy, str);
if(*str == '!') {
+ if(!mprintf_stdout)
+ fd = stderr;
fprintf(fd, "ERROR: ");
vfprintf(fd, ++str, args);
} else if(*str == '@') {
+ if(!mprintf_stdout)
+ fd = stderr;
fprintf(fd, "ERROR: ");
vfprintf(fd, ++str, args);
#ifdef NO_SNPRINTF
@@ -279,6 +280,8 @@
logg("ERROR: %s", logbuf);
} else if(!mprintf_quiet) {
if(*str == '^') {
+ if(!mprintf_stdout)
+ fd = stderr;
fprintf(fd, "WARNING: ");
vfprintf(fd, ++str, args);
} else if(*str == '*') {
pgpYfYCoziN5z.pgp
Description: PGP signature
___
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-devel
[Clamav-devel] shared/ouput.c
Hello all,
I have asked for this before, I think, but it would be really nice if
output from the various clam binaries went to different file desriptors,
depending on whether they are errors, warnings, or informative. This
would more easily filtering of output in things like cron jobs and the
like. I believe the attached patch does so.
--- clamav-devel-latest/shared/output.c 2004-10-16 20:48:02.0 -0400
+++ output.c2005-01-16 14:04:52.0 -0500
@@ -240,11 +240,6 @@
return;
}
-if(mprintf_stdout)
- fd = stdout;
-else
- fd = stderr;
-
/* legend:
* ! - error
* @ - error with logging
@@ -253,11 +248,13 @@
/*
* ERRORWARNINGSTANDARD
- * normal yes yesyes
+ * normal stderr stderr stdout
*
- * verbose yes yesyes
+ * verbose stderr stderr stdout
*
- * quietyes no no
+ * quiet stderr no no
+ *
+ * (unless --stdout is passed)
*/
@@ -266,9 +263,17 @@
va_start(argscpy, str);
if(*str == '!') {
+if(mprintf_stdout)
+fd = stdout;
+else
+fd = stderr;
fprintf(fd, "ERROR: ");
vfprintf(fd, ++str, args);
} else if(*str == '@') {
+if(mprintf_stdout)
+fd = stdout;
+else
+fd = stderr;
fprintf(fd, "ERROR: ");
vfprintf(fd, ++str, args);
#ifdef NO_SNPRINTF
@@ -279,12 +284,20 @@
logg("ERROR: %s", logbuf);
} else if(!mprintf_quiet) {
if(*str == '^') {
+if(mprintf_stdout)
+fd = stdout;
+else
+fd = stderr;
fprintf(fd, "WARNING: ");
vfprintf(fd, ++str, args);
} else if(*str == '*') {
+ fd = stdout;
if(mprintf_verbose)
vfprintf(fd, ++str, args);
- } else vfprintf(fd, str, args);
+ } else {
+fd = stdout;
+vfprintf(fd, str, args);
+ }
}
va_end(args);
Thanks,
--
--
| Stephen Gran | Mr. Cole's Axiom: The sum of the |
| [EMAIL PROTECTED] | intelligence on the planet is a |
| http://www.lobefin.net/~steve | constant; the population is growing. |
--
pgpgMhePOVPzc.pgp
Description: PGP signature
___
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-devel
Re: [Clamav-devel] cl_buildtrie confusion
On Wed, Nov 10, 2004 at 01:35:19AM +0100, Tomasz Kojm said: > README: > + updated API (still backward compatible but please consult > clamdoc.pdf (Section 6) and adapt your software) > > All programs based on libclamav should be updated and recompiled. When updating the API in a significant way, can you bump the soname? It would save us packagers a fair amount of work. -- ---------- | Stephen Gran | Never kick a man, unless he's down. | | [EMAIL PROTECTED] | | | http://www.lobefin.net/~steve | | -- pgpLuST382nss.pgp Description: PGP signature ___ http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-devel
Re: [Clamav-devel] clamscan and symlinks
On Thu, Sep 30, 2004 at 01:09:56AM +0100, Mark Allan said:
> On 30 Sep 2004, at 1:03 am, Stephen Gran wrote:
> >For clamscan, it looks like you can only use --max-recursion to avoid
> >those kind of symlink loops. clamdscan has the
> >Follow{File,Dir}Symlinks
> >options, though.
>
> I looked at that, but I think it only refers to decompressing archives
> doesn't it?
I don't believe so, but I'm sure someone will tell me if I'm wrong :)
--
------
| Stephen Gran | The way to a man's heart is through the |
| [EMAIL PROTECTED] | left ventricle. |
| http://www.lobefin.net/~steve | |
--
pgpBv8INTFLY4.pgp
Description: PGP signature
___
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-devel
Re: [Clamav-devel] clamscan and symlinks
On Thu, Sep 30, 2004 at 12:14:39AM +0100, Mark Allan said:
> Hi,
>
> What are the overheads involved in determining if a file is a
> symlink/hardlink and is there a way to tell clamscan not to follow
> them?
>
> Mac OS X contains a directory called /Volumes at the root level of the
> boot volume which in itself isn't a problem, but for some reason best
> known to Apple they decided to include a symlink to / inside there and
> I'm sure you don't need me to tell you the problems this causes when
> you call clamscan on the root directory!
>
> I've tried calling clamscan with --exclude=^/Volumes however it still
> seems to iterate through the directory (albeit without scanning) and
> still doesn't ever actually come to a halt.
>
> Could we do something along the lines of what's been done in
> "/clamscan/manager.c" where /proc is excluded for LINUX?
For clamscan, it looks like you can only use --max-recursion to avoid
those kind of symlink loops. clamdscan has the Follow{File,Dir}Symlinks
options, though.
--
--
| Stephen Gran | Virginia law forbids bathtubs in the|
| [EMAIL PROTECTED] | house; tubs must be kept in the yard. |
| http://www.lobefin.net/~steve | |
--
pgpgEF0GaJIO3.pgp
Description: PGP signature
Re: [Clamav-devel] clamd STREAM and ZIP, RAR, bzip2
On Thu, Aug 12, 2004 at 07:51:15PM -0400, Brian A. Reiter said: > Unfortunately that doesn't fix it. > > I've tried sending the stream as ASCII, Unicode and BigEndian Unicode text > to the TCP port that is returned by the STREAM command. But all of these > only work with "test" and not "test.zip" et al. Is ScanArchive enabled in clamav.conf? -- ------ | Stephen Gran | Our missions are peaceful -- not for| | [EMAIL PROTECTED] | conquest. When we do battle, it is | | http://www.lobefin.net/~steve | only because we have no choice. --| || Kirk, "The Squire of Gothos", stardate | || 2124.5 | -- pgpfWM13u4eX4.pgp Description: PGP signature
Re: [Clamav-devel] freshclam's --log option does not seem to work
On Sat, Jul 31, 2004 at 07:55:42PM +0200, Robert Allerstorfer said: > Hi, > > while executing > > clamscan -l clamav.log > > worked well, the same option did not work with the freshclam program: > > freshclam -l clamav.log > ERROR: Can't open clamav.log in append mode. > ERROR: Problem with internal logger. > > This happened with freshclam 0.75.1 on Linux. Am I missing something > or is this a bug? freshclam by default runs as user clamv. Does user clamav have write permissions to the directory in which you're running that command? -- ------ | Stephen Gran | Life is like a simile. | | [EMAIL PROTECTED] | | | http://www.lobefin.net/~steve | | -- pgpfA1MdtBvuP.pgp Description: PGP signature
Re: [Clamav-devel] Clamav rules:-)
On Mon, Jul 26, 2004 at 08:47:57PM +, Bennett Todd said: > First annoyance was that it took some pounding with a club to > convince this release to statically link. I ended up having to > hand-link each of the executables. If I ever find the alleged person > who committed "libtool"; I'll beat it to death with a stick in the > interests of eugenics. Can't help you there, it compiles and liks fine here. > When I tried using the example clamav.conf's default LocalSocket > /tmp/clamd, clamdscan didn't, it opened the unix domain socket, > did a getpeername, then wandered off hanging on a TCP connect to a > seemingly random IP. Switching to a 127.0.0.1 TCP socket fixed that. > This may be due to my static linking with uClibc; this is certainly > a somewhat odd env, at least in the sense of "not exactly like what > everybody else does". This is a know issue, it's not just you. > And last, but it seems likely that this is a portable concern, when > I switched on "User clamav" (after creating the user, of course), > clamd could no longer write its pidfile in /var/run; evidently it > was tossing its privs before writing the pidfile. I can think of > two reasonable klugearounds for this. I'm guessing the main reason > for the current setup is so clamd knows it can unlink its pidfile > on exit. One decent kludge would be to either ignore pre-existing > pidfile on startup, or at least confirm, that the pid contained > in it exists and ignore it if not. That way unability to clean up > pidfile on exit would be benign. Alternatively, let the invoking > process fork a child that drops privs and does all the work, create > the pid file with the child's pid in it, and then wait for the child > to exit and do the cleanup (having retained root privs) then. Hmm. I > could do that from my init script if I cared enough:-). Or create a subdirectory, /var/run/clamav, owned by clamav. -- -- | Stephen Gran | Stability itself is nothing else than a | | [EMAIL PROTECTED] | more sluggish motion. | | http://www.lobefin.net/~steve | | -- pgpu8RlgmKziq.pgp Description: PGP signature
Re: [Clamav-devel] Feature Request: clamd stderr logging support
On Tue, Jun 08, 2004 at 02:13:16PM +0300, Mihai Rusu said: > Hi > > Any chance of getting this small patch merged ? > http://www.qscanq.org/clamav-0.70-stderr.patch.gz > > Or some other solution to obtain stderr logging for clamd. > > Thanks! Doesn't LogFile /dev/stderr LogFileUnlock Work for you? -- ------ | Stephen Gran | "I'd love to go out with you, but I did | | [EMAIL PROTECTED] | my own thing and now I've got to undo | | http://www.lobefin.net/~steve | it."| -- pgpwsWWkPbqb9.pgp Description: PGP signature
[Clamav-devel] shared/output.c comments and patch
Hello all,
I received a bug via the debian BTS
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=247180 for details)
that essentially said the the quiet switch suppresses too much
information. I tend to agree - warnings shouldn't be supressed. While
digging around, I also found that some things which I would have thought
should go to stdout go to stderr, so I tried to patch output.c. My C
skills are extremely rusty - the patch below is kind of rough.
It applies cleanly to 0.72, and appears to work, but you may want to go
over it before thinking about applying it. Basically, it redirects all
ERROR and WARNING messages to stderr unless --stdout is specified, and
everything else goes to stdout, unless --quiet is specified. --verbose
is left as it was.
Thanks for all your work.
--
--
| Stephen Gran | Avoid reality at all costs. |
| [EMAIL PROTECTED] | |
| http://www.lobefin.net/~steve | |
--
--- shared/output.c.old 2004-06-06 13:20:45.0 -0400
+++ shared/output.c 2004-06-06 13:48:48.0 -0400
@@ -239,8 +239,6 @@
if(mprintf_stdout)
fd = stdout;
-else
- fd = stderr;
/* legend:
* ! - error
@@ -254,16 +252,22 @@
*
* verbose yes yesyes
*
- * quietyes no no
+ * quietyes yesno
*/
va_start(args, str);
if(*str == '!') {
+ if (fd != stdout) {
+fd = stderr;
+ }
fprintf(fd, "ERROR: ");
vfprintf(fd, ++str, args);
} else if(*str == '@') {
+ if (fd != stdout) {
+fd = stderr;
+ }
fprintf(fd, "ERROR: ");
vfprintf(fd, ++str, args);
#ifdef NO_SNPRINTF
@@ -272,11 +276,17 @@
vsnprintf(logbuf, sizeof(logbuf), str, args);
#endif
logg("ERROR: %s", logbuf);
+} else if(*str == '^') {
+ if (fd != stdout) {
+fd = stderr;
+ }
+fprintf(fd, "WARNING: ");
+vfprintf(fd, ++str, args);
} else if(!mprintf_quiet) {
- if(*str == '^') {
- fprintf(fd, "WARNING: ");
- vfprintf(fd, ++str, args);
- } else if(*str == '*') {
+ if (fd != stdout) {
+fd = stdout;
+ }
+ if(*str == '*') {
if(mprintf_verbose)
vfprintf(fd, ++str, args);
} else vfprintf(fd, str, args);
pgp4LsRUl4XqH.pgp
Description: PGP signature
Re: [Clamav-devel] 0.70-rc and packaging
On Thu, Mar 18, 2004 at 05:42:59PM +0100, Tomasz Kojm said: > On Thu, 18 Mar 2004 11:05:18 -0500 > Stephen Gran <[EMAIL PROTECTED]> wrote: > > > Hello all, > > > > I am preparing packages of 0.70-rc for Debian, and I wanted to see > > what your upcoming naming schema is likely to be, as this will affect > > the ease of upgrades from this version. > > > > Is it likely that the next version is going to be something like > > 0.70-rc1, or 0.70-rc-1. or how do you envision it? dpkg gets a little > > The next version will be 0.70 Well, that makes it easy :) Thanks, -- ------ | Stephen Gran | Once a word has been allowed to escape, | | [EMAIL PROTECTED] | it cannot be recalled. -- Quintus | | http://www.lobefin.net/~steve | Horatius Flaccus (Horace) | -- pgp0.pgp Description: PGP signature
[Clamav-devel] 0.70-rc and packaging
Hello all, I am preparing packages of 0.70-rc for Debian, and I wanted to see what your upcoming naming schema is likely to be, as this will affect the ease of upgrades from this version. Is it likely that the next version is going to be something like 0.70-rc1, or 0.70-rc-1. or how do you envision it? dpkg gets a little finicky about what is higher and lower version numbers (I believe it does absolute lexical sorting). The two ideas I tossed out above work, but I wanted to check to make sure before I backed myself into a corner of messy version numbering. Thanks, -- -- | Stephen Gran | The only time a dog gets complimented | | [EMAIL PROTECTED] | is when he doesn't do anything. -- C. | | http://www.lobefin.net/~steve | Schulz | -- pgp0.pgp Description: PGP signature
[Clamav-devel] Not quite 64-bit clean, it seems
Hello all, Just FYI, I see this on Debian linux builds on the ia64: source='ole2_extract.c' object='ole2_extract.lo' libtool=yes \ depfile='.deps/ole2_extract.Plo' tmpdepfile='.deps/ole2_extract.TPlo' \ depmode=gcc3 /bin/sh ../depcomp \ /bin/sh ../libtool --mode=compile ia64-linux-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I./zziplib-g -O2 -c -o ole2_extract.lo `test -f 'ole2_extract.c' || echo './'`ole2_extract.c ia64-linux-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I./zziplib -g -O2 -c ole2_extract.c -MT ole2_extract.lo -MD -MP -MF .deps/ole2_extract.TPlo -fPIC -DPIC -o .libs/ole2_extract.o ole2_extract.c: In function `handler_writefile': ole2_extract.c:524: warning: cast from pointer to integer of different size ia64-linux-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I./zziplib -g -O2 -c ole2_extract.c -MT ole2_extract.lo -MD -MP -MF .deps/ole2_extract.TPlo -o ole2_extract.o >/dev/null 2>&1 source='vba_extract.c' object='vba_extract.lo' libtool=yes \ depfile='.deps/vba_extract.Plo' tmpdepfile='.deps/vba_extract.TPlo' \ depmode=gcc3 /bin/sh ../depcomp \ /bin/sh ../libtool --mode=compile ia64-linux-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I./zziplib-g -O2 -c -o vba_extract.lo `test -f 'vba_extract.c' || echo './'`vba_extract.c ia64-linux-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I./zziplib -g -O2 -c vba_extract.c -MT vba_extract.lo -MD -MP -MF .deps/vba_extract.TPlo -fPIC -DPIC -o .libs/vba_extract.o vba_extract.c: In function `get_unicode_name': vba_extract.c:154: warning: cast to pointer from integer of different size vba_extract.c: In function `vba56_dir_read': vba_extract.c:242: warning: cast to pointer from integer of different size vba_extract.c:378: warning: cast to pointer from integer of different size vba_extract.c:398: warning: cast to pointer from integer of different size vba_extract.c:409: warning: cast to pointer from integer of different size vba_extract.c:451: warning: cast to pointer from integer of different size vba_extract.c:504: warning: cast to pointer from integer of different size vba_extract.c:505: warning: cast to pointer from integer of different size vba_extract.c:508: warning: cast to pointer from integer of different size vba_extract.c:515: warning: cast to pointer from integer of different size vba_extract.c: In function `byte_array_append': vba_extract.c:604: warning: cast to pointer from integer of different size Build seems to otherwise complete fine, though. -- -- | Stephen Gran | It may be better to be a live jackal| | [EMAIL PROTECTED] | than a dead lion, but it is better | | http://www.lobefin.net/~steve | still to be a live lion. And usually | || easier. -- Lazarus Long | -- pgp0.pgp Description: PGP signature
Re: [Clamav-devel] Acouple of quick questions
On Sat, Feb 21, 2004 at 03:47:40PM +0100, Tomasz Kojm said: > On Fri, 20 Feb 2004 16:54:39 -0500 > Stephen Gran <[EMAIL PROTECTED]> wrote: > > Disabling > > Clamuko is no problem - just pass that to configure. I see nothing > > Please keep it disabled in your packages. OK - that was my plan, anyway. > > similar for OLE/VBA stuff - is it considerd stable enough now to > > include? > > There's no big sense to include it now because our signatures don't use > VBA extension yet. Your packages should be directly based on stable > versions - please don't backport new features (at least that big ones), > only bugfixes. Sounds like a good plan. Is there any rough timetable for 0.68 that you know of? Release goals or that sort of thing? Right now the main things I'm interested in pulling form CVS are the better bounce recognition, and the improved daemon behavior for freshclam - the rest I have no plans to backport. Thanks, -- ------ | Stephen Gran | Marriage causes dating problems.| | [EMAIL PROTECTED] | | | http://www.lobefin.net/~steve | | -- pgp0.pgp Description: PGP signature
[Clamav-devel] Acouple of quick questions
Hello all,
I am spending the day cleaning up the debian parts of my life, and I
ran across some things I wanted clarification about.
First:
Contributed scripts sent to the BTS - should I submit them on this list,
or to [EMAIL PROTECTED], or elsewere? I am thinking in particular of a
script to integrate clam{,d}scan into a procmail/maildrop setup.
Second:
I would like to incorporate several of the changes I see in CVS
(specifically, freshclam writing a pidfile and responding to HUP by
reopening it's logfile, and the new bounce delimiters), but I'm a little
leery of both the Clamuko code and the OLE2/VBA code, as I was under the
impression that it's not very mature just yet. Disabling Clamuko is no
problem - just pass that to configure. I see nothing similar for
OLE/VBA stuff - is it considerd stable enough now to include?
Thanks for any advice,
--
----------
| Stephen Gran | "Pay no attention to the man behind the |
| [EMAIL PROTECTED] | curtain." -- Karl, as he stepped behind |
| http://www.lobefin.net/~steve | the computer to reboot it, during a FAT |
--
pgp0.pgp
Description: PGP signature
[Clamav-devel] Forwarding bugs upstream?
Hello all, When I get debian bug reports that I think should be forwarded upstream, where would you like me to send them? I was thinking that this list was a reasonable place, so that they got a decent level of exposure, and people could send patches if they want, but I don't want to send a bunch of stuff if no one is hugely interested - might it be better to send them to you privately? Just let me know which you prefer. Thanks, -- -- | Stephen Gran | Are we running light with overbyte? | | [EMAIL PROTECTED] | | | http://www.lobefin.net/~steve | | -- pgp0.pgp Description: PGP signature
