Re: [Clamav-devel] enabling DMG and XAR support
Dale, Unless you are willing to get me a copy of your gcc, I am going to be unable to reproduce this. As it stands, this PPC has gcc 4.0 completely unpatched and I am not able to even get close to compilation as configure simply won't continue with the bugs I have in this compiler. I also do not have the time to guess as to what version of gcc corresponds to what you have based on the way you have maintained it. I also doubt any of the real developers would go to this kind of trouble as well to attempt to reproduce the problem. This is an open source project, I am sure any patches you come up with to resolve the issue will be considered for inclusion upstream. On Thu, Mar 27, 2014 at 9:39 AM, Brandon Perry bperry.volat...@gmail.comwrote: I have found a friend with an old G5 PPC that he is willing to lend for a couple days. When I get it probably this weekend I will be able to attempt to repro the issues you are having. Let me know if the --enable-llvm=no flag does/doesnt work for you. However, if I can repro and I can fix the code up to compile correctly, I do no expect that patch to be merged into mainline codebase. I dont expect sourcefire to officially support your system in its current state since the current codebase works fine for 99.9% of people. Sent from a computer On Mar 26, 2014, at 2:22 PM, Brandon Perry bperry.volat...@gmail.com wrote: This also might be worth trying. Dale, could you try appending this to your configure line and see if it resolves the issue with your 4.x compiler? Sent from a computer On Mar 26, 2014, at 2:19 PM, Steven Morgan smor...@sourcefire.com wrote: FYI, This just in (from clamdoc.pdf): quote The following packages are optional, but required for bytecode JIT support: GCC C and C++ compilers (minimum 4.1.3, recommended 4.3.4 or newer) the package for these compilers are usually called: gcc, g++, or gcc-c++. /quote Mileage may be better in those cases by using ./configure --enable-llvm=no On Wed, Mar 26, 2014 at 3:06 PM, Brandon Perry bperry.volat...@gmail.comwrote: FWIW i am currently asking friends if they have a PPC that i can try this one. Sent from a computer On Mar 26, 2014, at 1:37 PM, Brandon Perry bperry.volat...@gmail.com wrote: You must not have read my email. I was not saying it is your build tool. I said it was your architecture causing the LLVM type to not be implicitly casted to a long int, likely due to register sizes on the PPC platform. You will need to modify the code to explicitly cast the LLVM type to a long int so that it compiles on your architecture. Sent from a computer On Mar 26, 2014, at 12:58 PM, Dale Walsh d...@daleenterprise.com wrote: Why do people have to be so stupid and immediately implicate the build tools or environment? Because updates and bug-fixes were applied, your assuming that these are not done correctly or in compliance with the OS and build environment or that they are faulty. First, you need to stop this bull-crap about non-standard and heavily modified and listen to the details regarding the issue you are told and stop focusing on the build tools which you have no clue about. It is best that you accept my word that it is standard and in compliance with the OS, build environment and ADE. I have confirmed the issue still exists under gcc-4.4 so it's not a build tool issue. I now have generated a fully working ClamAV 0.98.1 under gcc-3.3, gcc-4.0.0 and gcc 4.0.1 by cleanly autoreconf-ing the source tree. Here's my configure for the working builds under the mentioned compilers: CFLAGS=-arch ppc -arch i386 -g -Os -pipe -DFD_SETSIZE=2048 -arch ppc -arch i386 CCFLAGS=-arch ppc -arch i386 -g -Os -pipe CXXFLAGS=-arch ppc -arch i386 -g -Os -pipe LDFLAGS=-arch ppc -arch i386 ./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc --enable-bigstack --with-user=clamav --with-group=clamav --with-dbdir=/var/clamav --disable-clamav Is using ltmain.sh from Debian-Ubuntu called portability amongst different environments?? -- Dale On Mar 26, 2014, at 09:06 AM, Brandon Perry wrote: I don't use MacPorts or any other non-standard build environment... Your entire build system is non-standard if you maintain in the way you say you do. This is very likely an architecture issue and will require explicit casts in order to work for you (which would cause performance decreases for every other ClamAV user). Would you expect the ClamAV project to maintain this? You say you have submitted code in the past, you will likely need to make this work yourself by adding the explicit casts to the codebase. This really isn't an issue with ClamAV or LLVM/Clang. You have a system that is relatively unsupportable because of A) age and B) you have *heavily* modified it at this point to attempt to
Re: [Clamav-devel] enabling DMG and XAR support
I have found a friend with an old G5 PPC that he is willing to lend for a couple days. When I get it probably this weekend I will be able to attempt to repro the issues you are having. Let me know if the --enable-llvm=no flag does/doesnt work for you. However, if I can repro and I can fix the code up to compile correctly, I do no expect that patch to be merged into mainline codebase. I dont expect sourcefire to officially support your system in its current state since the current codebase works fine for 99.9% of people. Sent from a computer On Mar 26, 2014, at 2:22 PM, Brandon Perry bperry.volat...@gmail.com wrote: This also might be worth trying. Dale, could you try appending this to your configure line and see if it resolves the issue with your 4.x compiler? Sent from a computer On Mar 26, 2014, at 2:19 PM, Steven Morgan smor...@sourcefire.com wrote: FYI, This just in (from clamdoc.pdf): quote The following packages are optional, but required for bytecode JIT support: GCC C and C++ compilers (minimum 4.1.3, recommended 4.3.4 or newer) the package for these compilers are usually called: gcc, g++, or gcc-c++. /quote Mileage may be better in those cases by using ./configure --enable-llvm=no On Wed, Mar 26, 2014 at 3:06 PM, Brandon Perry bperry.volat...@gmail.comwrote: FWIW i am currently asking friends if they have a PPC that i can try this one. Sent from a computer On Mar 26, 2014, at 1:37 PM, Brandon Perry bperry.volat...@gmail.com wrote: You must not have read my email. I was not saying it is your build tool. I said it was your architecture causing the LLVM type to not be implicitly casted to a long int, likely due to register sizes on the PPC platform. You will need to modify the code to explicitly cast the LLVM type to a long int so that it compiles on your architecture. Sent from a computer On Mar 26, 2014, at 12:58 PM, Dale Walsh d...@daleenterprise.com wrote: Why do people have to be so stupid and immediately implicate the build tools or environment? Because updates and bug-fixes were applied, your assuming that these are not done correctly or in compliance with the OS and build environment or that they are faulty. First, you need to stop this bull-crap about non-standard and heavily modified and listen to the details regarding the issue you are told and stop focusing on the build tools which you have no clue about. It is best that you accept my word that it is standard and in compliance with the OS, build environment and ADE. I have confirmed the issue still exists under gcc-4.4 so it's not a build tool issue. I now have generated a fully working ClamAV 0.98.1 under gcc-3.3, gcc-4.0.0 and gcc 4.0.1 by cleanly autoreconf-ing the source tree. Here's my configure for the working builds under the mentioned compilers: CFLAGS=-arch ppc -arch i386 -g -Os -pipe -DFD_SETSIZE=2048 -arch ppc -arch i386 CCFLAGS=-arch ppc -arch i386 -g -Os -pipe CXXFLAGS=-arch ppc -arch i386 -g -Os -pipe LDFLAGS=-arch ppc -arch i386 ./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc --enable-bigstack --with-user=clamav --with-group=clamav --with-dbdir=/var/clamav --disable-clamav Is using ltmain.sh from Debian-Ubuntu called portability amongst different environments?? -- Dale On Mar 26, 2014, at 09:06 AM, Brandon Perry wrote: I don't use MacPorts or any other non-standard build environment... Your entire build system is non-standard if you maintain in the way you say you do. This is very likely an architecture issue and will require explicit casts in order to work for you (which would cause performance decreases for every other ClamAV user). Would you expect the ClamAV project to maintain this? You say you have submitted code in the past, you will likely need to make this work yourself by adding the explicit casts to the codebase. This really isn't an issue with ClamAV or LLVM/Clang. You have a system that is relatively unsupportable because of A) age and B) you have *heavily* modified it at this point to attempt to maintain it. Even if one of us had an old PPC with gcc 4.0 (which compiles ClamAV just fine on FC4 which makes me think your patching has not been as successful as you think), we would still not have the same environment you do since you claim to maintain your binaries by hand. Unless you are willing to add the explicit casts yourself, I think you are probably SOL. On Wed, Mar 26, 2014 at 3:02 AM, Dale Walsh d...@daleenterprise.com wrote: You ask for details so here they are. I don't use MacPorts or any other non-standard build environment, I don't suffer compiler bugs so I don't need 'CCFLAGS=-O0 to correct a buggy compiler and I have applied every patch and bug-fix released and experience no build issues with any other software source. Here's what I start with: Using gcc-3.3 (it's old but it
Re: [Clamav-devel] enabling DMG and XAR support
You ask for details so here they are. I don't use MacPorts or any other non-standard build environment, I don't suffer compiler bugs so I don't need 'CCFLAGS=-O0 to correct a buggy compiler and I have applied every patch and bug-fix released and experience no build issues with any other software source. Here's what I start with: Using gcc-3.3 (it's old but it compiles for ppc) cd /private/var/tmp/clamav/clamav-1.obj CFLAGS=-arch ppc -g -Os - pipe -pipe -no-cpp-precomp -arch ppc CCFLAGS=-arch ppc -g -Os -pipe CXXFLAGS=-arch ppc -g -Os -pipe LDFLAGS=-arch ppc TEXI2HTML=/usr/bin/texi2html -subdir . rm -rf /tmp/clamav/Release mkdir -p /tmp/clamav/Debug ln -sf /CLAMAV_BUILD/Release /tmp/ clamav/Release CFLAGS=-DFD_SETSIZE=2048 ./configure --prefix=/ usr --mandir=/usr/share/man --sysconfdir=/etc --enable-bigstack -- with-user=clamav --with-group=clamav --with-dbdir=/var/clamav -- disable-clamav make make install # no issues with the build or install but nothing seems to works and segfaults (expected behavior) Using gcc-3.3 cd /private/var/tmp/clamav/clamav-1.obj CFLAGS=-arch ppc -arch i386 -g -Os -pipe -pipe -no-cpp-precomp -arch ppc -arch i386 CCFLAGS=-arch ppc -arch i386 -g -Os -pipe CXXFLAGS=-arch ppc - arch i386 -g -Os -pipe LDFLAGS=-arch ppc -arch i386 TEXI2HTML=/usr/bin/texi2html -subdir . rm -rf /tmp/clamav/Release mkdir -p /tmp/clamav/Debug ln -sf /CLAMAV_BUILD/Release /tmp/ clamav/Release CFLAGS=-DFD_SETSIZE=2048 ./configure --prefix=/ usr --mandir=/usr/share/man --sysconfdir=/etc --enable-bigstack -- with-user=clamav --with-group=clamav --with-dbdir=/var/clamav -- disable-clamav make fails with: ld: Undefined symbols: _lt_libltdlc_LTX_preloaded_symbols /usr/bin/libtool: internal link edit command failed Using gcc-3.5 (it's old but it compiles for ppc) cd /private/var/tmp/clamav/clamav-1.obj CFLAGS=-arch ppc -g -Os - pipe -pipe -no-cpp-precomp -arch ppc CCFLAGS=-arch ppc -g -Os -pipe CXXFLAGS=-arch ppc -g -Os -pipe LDFLAGS=-arch ppc TEXI2HTML=/usr/bin/texi2html -subdir . rm -rf /tmp/clamav/Release mkdir -p /tmp/clamav/Debug ln -sf /CLAMAV_BUILD/Release /tmp/ clamav/Release CFLAGS=-DFD_SETSIZE=2048 ./configure --prefix=/ usr --mandir=/usr/share/man --sysconfdir=/etc --enable-bigstack -- with-user=clamav --with-group=clamav --with-dbdir=/var/clamav -- disable-clamav make make install # no issues with the build or install but nothing seems to works and segfaults (expected behavior) Using gcc-3.5 cd /private/var/tmp/clamav/clamav-1.obj CFLAGS=-arch ppc -arch i386 -g -Os -pipe -pipe -no-cpp-precomp -arch ppc -arch i386 CCFLAGS=-arch ppc -arch i386 -g -Os -pipe CXXFLAGS=-arch ppc - arch i386 -g -Os -pipe LDFLAGS=-arch ppc -arch i386 TEXI2HTML=/usr/bin/texi2html -subdir . rm -rf /tmp/clamav/Release mkdir -p /tmp/clamav/Debug ln -sf /CLAMAV_BUILD/Release /tmp/ clamav/Release CFLAGS=-DFD_SETSIZE=2048 ./configure --prefix=/ usr --mandir=/usr/share/man --sysconfdir=/etc --enable-bigstack -- with-user=clamav --with-group=clamav --with-dbdir=/var/clamav -- disable-clamav make fails with: ld: Undefined symbols: _lt_libltdlc_LTX_preloaded_symbols /usr/bin/libtool: internal link edit command failed Using gcc-4.0.0 cd /private/var/tmp/clamav/clamav-1.obj CFLAGS=-arch ppc -g -Os - pipe -pipe -no-cpp-precomp -arch ppc CCFLAGS=-arch ppc -g -Os -pipe CXXFLAGS=-arch ppc -g -Os -pipe LDFLAGS=-arch ppc TEXI2HTML=/usr/bin/texi2html -subdir . rm -rf /tmp/clamav/Release mkdir -p /tmp/clamav/Debug ln -sf /CLAMAV_BUILD/Release /tmp/ clamav/Release CFLAGS=-DFD_SETSIZE=2048 ./configure --prefix=/ usr --mandir=/usr/share/man --sysconfdir=/etc --enable-bigstack -- with-user=clamav --with-group=clamav --with-dbdir=/var/clamav -- disable-clamav make fails with ./llvm/lib/VMCore/TypesContext.h:311: error: invalid conversion from 'const llvm::Type*' to 'long int' Using gcc-4.0.1 cd /private/var/tmp/clamav/clamav-1.obj CFLAGS=-arch ppc -g -Os - pipe -pipe -no-cpp-precomp -arch ppc CCFLAGS=-arch ppc -g -Os -pipe CXXFLAGS=-arch ppc -g -Os -pipe LDFLAGS=-arch ppc TEXI2HTML=/usr/bin/texi2html -subdir . rm -rf /tmp/clamav/Release mkdir -p /tmp/clamav/Debug ln -sf /CLAMAV_BUILD/Release /tmp/ clamav/Release CFLAGS=-DFD_SETSIZE=2048 ./configure --prefix=/ usr --mandir=/usr/share/man --sysconfdir=/etc --enable-bigstack -- with-user=clamav --with-group=clamav --with-dbdir=/var/clamav -- disable-clamav make fails with ./llvm/lib/VMCore/TypesContext.h:311: error: invalid conversion from 'const llvm::Type*' to 'long int' Using gcc-4.1.0 cd /private/var/tmp/clamav/clamav-1.obj CFLAGS=-arch ppc -g -Os - pipe -pipe -no-cpp-precomp -arch ppc CCFLAGS=-arch ppc -g -Os -pipe CXXFLAGS=-arch ppc -g -Os -pipe LDFLAGS=-arch ppc TEXI2HTML=/usr/bin/texi2html -subdir . rm -rf /tmp/clamav/Release mkdir -p
Re: [Clamav-devel] enabling DMG and XAR support
I don't use MacPorts or any other non-standard build environment... Your entire build system is non-standard if you maintain in the way you say you do. This is very likely an architecture issue and will require explicit casts in order to work for you (which would cause performance decreases for every other ClamAV user). Would you expect the ClamAV project to maintain this? You say you have submitted code in the past, you will likely need to make this work yourself by adding the explicit casts to the codebase. This really isn't an issue with ClamAV or LLVM/Clang. You have a system that is relatively unsupportable because of A) age and B) you have *heavily* modified it at this point to attempt to maintain it. Even if one of us had an old PPC with gcc 4.0 (which compiles ClamAV just fine on FC4 which makes me think your patching has not been as successful as you think), we would still not have the same environment you do since you claim to maintain your binaries by hand. Unless you are willing to add the explicit casts yourself, I think you are probably SOL. On Wed, Mar 26, 2014 at 3:02 AM, Dale Walsh d...@daleenterprise.com wrote: You ask for details so here they are. I don't use MacPorts or any other non-standard build environment, I don't suffer compiler bugs so I don't need 'CCFLAGS=-O0 to correct a buggy compiler and I have applied every patch and bug-fix released and experience no build issues with any other software source. Here's what I start with: Using gcc-3.3 (it's old but it compiles for ppc) cd /private/var/tmp/clamav/clamav-1.obj CFLAGS=-arch ppc -g -Os -pipe -pipe -no-cpp-precomp -arch ppc CCFLAGS=-arch ppc -g -Os -pipe CXXFLAGS=-arch ppc -g -Os -pipe LDFLAGS=-arch ppc TEXI2HTML=/usr/bin/texi2html -subdir . rm -rf /tmp/clamav/Release mkdir -p /tmp/clamav/Debug ln -sf /CLAMAV_BUILD/Release /tmp/clamav/Release CFLAGS=-DFD_SETSIZE=2048 ./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc --enable-bigstack --with-user=clamav --with-group=clamav --with-dbdir=/var/clamav --disable-clamav make make install # no issues with the build or install but nothing seems to works and segfaults (expected behavior) Using gcc-3.3 cd /private/var/tmp/clamav/clamav-1.obj CFLAGS=-arch ppc -arch i386 -g -Os -pipe -pipe -no-cpp-precomp -arch ppc -arch i386 CCFLAGS=-arch ppc -arch i386 -g -Os -pipe CXXFLAGS=-arch ppc -arch i386 -g -Os -pipe LDFLAGS=-arch ppc -arch i386 TEXI2HTML=/usr/bin/texi2html -subdir . rm -rf /tmp/clamav/Release mkdir -p /tmp/clamav/Debug ln -sf /CLAMAV_BUILD/Release /tmp/clamav/Release CFLAGS=-DFD_SETSIZE=2048 ./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc --enable-bigstack --with-user=clamav --with-group=clamav --with-dbdir=/var/clamav --disable-clamav make fails with: ld: Undefined symbols: _lt_libltdlc_LTX_preloaded_symbols /usr/bin/libtool: internal link edit command failed Using gcc-3.5 (it's old but it compiles for ppc) cd /private/var/tmp/clamav/clamav-1.obj CFLAGS=-arch ppc -g -Os -pipe -pipe -no-cpp-precomp -arch ppc CCFLAGS=-arch ppc -g -Os -pipe CXXFLAGS=-arch ppc -g -Os -pipe LDFLAGS=-arch ppc TEXI2HTML=/usr/bin/texi2html -subdir . rm -rf /tmp/clamav/Release mkdir -p /tmp/clamav/Debug ln -sf /CLAMAV_BUILD/Release /tmp/clamav/Release CFLAGS=-DFD_SETSIZE=2048 ./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc --enable-bigstack --with-user=clamav --with-group=clamav --with-dbdir=/var/clamav --disable-clamav make make install # no issues with the build or install but nothing seems to works and segfaults (expected behavior) Using gcc-3.5 cd /private/var/tmp/clamav/clamav-1.obj CFLAGS=-arch ppc -arch i386 -g -Os -pipe -pipe -no-cpp-precomp -arch ppc -arch i386 CCFLAGS=-arch ppc -arch i386 -g -Os -pipe CXXFLAGS=-arch ppc -arch i386 -g -Os -pipe LDFLAGS=-arch ppc -arch i386 TEXI2HTML=/usr/bin/texi2html -subdir . rm -rf /tmp/clamav/Release mkdir -p /tmp/clamav/Debug ln -sf /CLAMAV_BUILD/Release /tmp/clamav/Release CFLAGS=-DFD_SETSIZE=2048 ./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc --enable-bigstack --with-user=clamav --with-group=clamav --with-dbdir=/var/clamav --disable-clamav make fails with: ld: Undefined symbols: _lt_libltdlc_LTX_preloaded_symbols /usr/bin/libtool: internal link edit command failed Using gcc-4.0.0 cd /private/var/tmp/clamav/clamav-1.obj CFLAGS=-arch ppc -g -Os -pipe -pipe -no-cpp-precomp -arch ppc CCFLAGS=-arch ppc -g -Os -pipe CXXFLAGS=-arch ppc -g -Os -pipe LDFLAGS=-arch ppc TEXI2HTML=/usr/bin/texi2html -subdir . rm -rf /tmp/clamav/Release mkdir -p /tmp/clamav/Debug ln -sf /CLAMAV_BUILD/Release /tmp/clamav/Release CFLAGS=-DFD_SETSIZE=2048 ./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc --enable-bigstack --with-user=clamav --with-group=clamav --with-dbdir=/var/clamav --disable-clamav
Re: [Clamav-devel] enabling DMG and XAR support
Why do people have to be so stupid and immediately implicate the build tools or environment? Because updates and bug-fixes were applied, your assuming that these are not done correctly or in compliance with the OS and build environment or that they are faulty. First, you need to stop this bull-crap about non-standard and heavily modified and listen to the details regarding the issue you are told and stop focusing on the build tools which you have no clue about. It is best that you accept my word that it is standard and in compliance with the OS, build environment and ADE. I have confirmed the issue still exists under gcc-4.4 so it's not a build tool issue. I now have generated a fully working ClamAV 0.98.1 under gcc-3.3, gcc-4.0.0 and gcc 4.0.1 by cleanly autoreconf-ing the source tree. Here's my configure for the working builds under the mentioned compilers: CFLAGS=-arch ppc -arch i386 -g -Os -pipe -DFD_SETSIZE=2048 -arch ppc -arch i386 CCFLAGS=-arch ppc -arch i386 -g -Os -pipe CXXFLAGS=- arch ppc -arch i386 -g -Os -pipe LDFLAGS=-arch ppc -arch i386 ./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/ etc --enable-bigstack --with-user=clamav --with-group=clamav --with- dbdir=/var/clamav --disable-clamav Is using ltmain.sh from Debian-Ubuntu called portability amongst different environments?? -- Dale On Mar 26, 2014, at 09:06 AM, Brandon Perry wrote: I don't use MacPorts or any other non-standard build environment... Your entire build system is non-standard if you maintain in the way you say you do. This is very likely an architecture issue and will require explicit casts in order to work for you (which would cause performance decreases for every other ClamAV user). Would you expect the ClamAV project to maintain this? You say you have submitted code in the past, you will likely need to make this work yourself by adding the explicit casts to the codebase. This really isn't an issue with ClamAV or LLVM/Clang. You have a system that is relatively unsupportable because of A) age and B) you have *heavily* modified it at this point to attempt to maintain it. Even if one of us had an old PPC with gcc 4.0 (which compiles ClamAV just fine on FC4 which makes me think your patching has not been as successful as you think), we would still not have the same environment you do since you claim to maintain your binaries by hand. Unless you are willing to add the explicit casts yourself, I think you are probably SOL. On Wed, Mar 26, 2014 at 3:02 AM, Dale Walsh d...@daleenterprise.com wrote: You ask for details so here they are. I don't use MacPorts or any other non-standard build environment, I don't suffer compiler bugs so I don't need 'CCFLAGS=-O0 to correct a buggy compiler and I have applied every patch and bug-fix released and experience no build issues with any other software source. Here's what I start with: Using gcc-3.3 (it's old but it compiles for ppc) cd /private/var/tmp/clamav/clamav-1.obj CFLAGS=-arch ppc -g - Os -pipe -pipe -no-cpp-precomp -arch ppc CCFLAGS=-arch ppc -g -Os -pipe CXXFLAGS=-arch ppc -g -Os -pipe LDFLAGS=-arch ppc TEXI2HTML=/usr/bin/texi2html -subdir . rm -rf /tmp/clamav/ Release mkdir -p /tmp/clamav/Debug ln -sf /CLAMAV_BUILD/Release /tmp/clamav/Release CFLAGS=-DFD_SETSIZE=2048 ./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc --enable- bigstack --with-user=clamav --with-group=clamav --with-dbdir=/var/clamav --disable-clamav make make install # no issues with the build or install but nothing seems to works and segfaults (expected behavior) Using gcc-3.3 cd /private/var/tmp/clamav/clamav-1.obj CFLAGS=-arch ppc -arch i386 -g -Os -pipe -pipe -no-cpp-precomp -arch ppc -arch i386 CCFLAGS=- arch ppc -arch i386 -g -Os -pipe CXXFLAGS=-arch ppc -arch i386 -g -Os - pipe LDFLAGS=-arch ppc -arch i386 TEXI2HTML=/usr/bin/ texi2html -subdir . rm -rf /tmp/clamav/Release mkdir -p /tmp/clamav/ Debug ln -sf /CLAMAV_BUILD/Release /tmp/clamav/Release CFLAGS=- DFD_SETSIZE=2048 ./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc --enable-bigstack --with-user=clamav --with-group=clamav --with-dbdir=/var/clamav --disable-clamav make fails with: ld: Undefined symbols: _lt_libltdlc_LTX_preloaded_symbols /usr/bin/libtool: internal link edit command failed Using gcc-3.5 (it's old but it compiles for ppc) cd /private/var/tmp/clamav/clamav-1.obj CFLAGS=-arch ppc -g - Os -pipe -pipe -no-cpp-precomp -arch ppc CCFLAGS=-arch ppc -g -Os -pipe CXXFLAGS=-arch ppc -g -Os -pipe LDFLAGS=-arch ppc TEXI2HTML=/usr/bin/texi2html -subdir . rm -rf /tmp/clamav/ Release mkdir -p /tmp/clamav/Debug ln -sf /CLAMAV_BUILD/Release /tmp/clamav/Release CFLAGS=-DFD_SETSIZE=2048 ./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc --enable- bigstack --with-user=clamav --with-group=clamav
Re: [Clamav-devel] enabling DMG and XAR support
You must not have read my email. I was not saying it is your build tool. I said it was your architecture causing the LLVM type to not be implicitly casted to a long int, likely due to register sizes on the PPC platform. You will need to modify the code to explicitly cast the LLVM type to a long int so that it compiles on your architecture. Sent from a computer On Mar 26, 2014, at 12:58 PM, Dale Walsh d...@daleenterprise.com wrote: Why do people have to be so stupid and immediately implicate the build tools or environment? Because updates and bug-fixes were applied, your assuming that these are not done correctly or in compliance with the OS and build environment or that they are faulty. First, you need to stop this bull-crap about non-standard and heavily modified and listen to the details regarding the issue you are told and stop focusing on the build tools which you have no clue about. It is best that you accept my word that it is standard and in compliance with the OS, build environment and ADE. I have confirmed the issue still exists under gcc-4.4 so it's not a build tool issue. I now have generated a fully working ClamAV 0.98.1 under gcc-3.3, gcc-4.0.0 and gcc 4.0.1 by cleanly autoreconf-ing the source tree. Here's my configure for the working builds under the mentioned compilers: CFLAGS=-arch ppc -arch i386 -g -Os -pipe -DFD_SETSIZE=2048 -arch ppc -arch i386 CCFLAGS=-arch ppc -arch i386 -g -Os -pipe CXXFLAGS=-arch ppc -arch i386 -g -Os -pipe LDFLAGS=-arch ppc -arch i386 ./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc --enable-bigstack --with-user=clamav --with-group=clamav --with-dbdir=/var/clamav --disable-clamav Is using ltmain.sh from Debian-Ubuntu called portability amongst different environments?? -- Dale On Mar 26, 2014, at 09:06 AM, Brandon Perry wrote: I don't use MacPorts or any other non-standard build environment... Your entire build system is non-standard if you maintain in the way you say you do. This is very likely an architecture issue and will require explicit casts in order to work for you (which would cause performance decreases for every other ClamAV user). Would you expect the ClamAV project to maintain this? You say you have submitted code in the past, you will likely need to make this work yourself by adding the explicit casts to the codebase. This really isn't an issue with ClamAV or LLVM/Clang. You have a system that is relatively unsupportable because of A) age and B) you have *heavily* modified it at this point to attempt to maintain it. Even if one of us had an old PPC with gcc 4.0 (which compiles ClamAV just fine on FC4 which makes me think your patching has not been as successful as you think), we would still not have the same environment you do since you claim to maintain your binaries by hand. Unless you are willing to add the explicit casts yourself, I think you are probably SOL. On Wed, Mar 26, 2014 at 3:02 AM, Dale Walsh d...@daleenterprise.com wrote: You ask for details so here they are. I don't use MacPorts or any other non-standard build environment, I don't suffer compiler bugs so I don't need 'CCFLAGS=-O0 to correct a buggy compiler and I have applied every patch and bug-fix released and experience no build issues with any other software source. Here's what I start with: Using gcc-3.3 (it's old but it compiles for ppc) cd /private/var/tmp/clamav/clamav-1.obj CFLAGS=-arch ppc -g -Os -pipe -pipe -no-cpp-precomp -arch ppc CCFLAGS=-arch ppc -g -Os -pipe CXXFLAGS=-arch ppc -g -Os -pipe LDFLAGS=-arch ppc TEXI2HTML=/usr/bin/texi2html -subdir . rm -rf /tmp/clamav/Release mkdir -p /tmp/clamav/Debug ln -sf /CLAMAV_BUILD/Release /tmp/clamav/Release CFLAGS=-DFD_SETSIZE=2048 ./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc --enable-bigstack --with-user=clamav --with-group=clamav --with-dbdir=/var/clamav --disable-clamav make make install # no issues with the build or install but nothing seems to works and segfaults (expected behavior) Using gcc-3.3 cd /private/var/tmp/clamav/clamav-1.obj CFLAGS=-arch ppc -arch i386 -g -Os -pipe -pipe -no-cpp-precomp -arch ppc -arch i386 CCFLAGS=-arch ppc -arch i386 -g -Os -pipe CXXFLAGS=-arch ppc -arch i386 -g -Os -pipe LDFLAGS=-arch ppc -arch i386 TEXI2HTML=/usr/bin/texi2html -subdir . rm -rf /tmp/clamav/Release mkdir -p /tmp/clamav/Debug ln -sf /CLAMAV_BUILD/Release /tmp/clamav/Release CFLAGS=-DFD_SETSIZE=2048 ./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc --enable-bigstack --with-user=clamav --with-group=clamav --with-dbdir=/var/clamav --disable-clamav make fails with: ld: Undefined symbols: _lt_libltdlc_LTX_preloaded_symbols /usr/bin/libtool: internal link edit command failed Using gcc-3.5 (it's old but it compiles for ppc) cd /private/var/tmp/clamav/clamav-1.obj
Re: [Clamav-devel] enabling DMG and XAR support
FWIW i am currently asking friends if they have a PPC that i can try this one. Sent from a computer On Mar 26, 2014, at 1:37 PM, Brandon Perry bperry.volat...@gmail.com wrote: You must not have read my email. I was not saying it is your build tool. I said it was your architecture causing the LLVM type to not be implicitly casted to a long int, likely due to register sizes on the PPC platform. You will need to modify the code to explicitly cast the LLVM type to a long int so that it compiles on your architecture. Sent from a computer On Mar 26, 2014, at 12:58 PM, Dale Walsh d...@daleenterprise.com wrote: Why do people have to be so stupid and immediately implicate the build tools or environment? Because updates and bug-fixes were applied, your assuming that these are not done correctly or in compliance with the OS and build environment or that they are faulty. First, you need to stop this bull-crap about non-standard and heavily modified and listen to the details regarding the issue you are told and stop focusing on the build tools which you have no clue about. It is best that you accept my word that it is standard and in compliance with the OS, build environment and ADE. I have confirmed the issue still exists under gcc-4.4 so it's not a build tool issue. I now have generated a fully working ClamAV 0.98.1 under gcc-3.3, gcc-4.0.0 and gcc 4.0.1 by cleanly autoreconf-ing the source tree. Here's my configure for the working builds under the mentioned compilers: CFLAGS=-arch ppc -arch i386 -g -Os -pipe -DFD_SETSIZE=2048 -arch ppc -arch i386 CCFLAGS=-arch ppc -arch i386 -g -Os -pipe CXXFLAGS=-arch ppc -arch i386 -g -Os -pipe LDFLAGS=-arch ppc -arch i386 ./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc --enable-bigstack --with-user=clamav --with-group=clamav --with-dbdir=/var/clamav --disable-clamav Is using ltmain.sh from Debian-Ubuntu called portability amongst different environments?? -- Dale On Mar 26, 2014, at 09:06 AM, Brandon Perry wrote: I don't use MacPorts or any other non-standard build environment... Your entire build system is non-standard if you maintain in the way you say you do. This is very likely an architecture issue and will require explicit casts in order to work for you (which would cause performance decreases for every other ClamAV user). Would you expect the ClamAV project to maintain this? You say you have submitted code in the past, you will likely need to make this work yourself by adding the explicit casts to the codebase. This really isn't an issue with ClamAV or LLVM/Clang. You have a system that is relatively unsupportable because of A) age and B) you have *heavily* modified it at this point to attempt to maintain it. Even if one of us had an old PPC with gcc 4.0 (which compiles ClamAV just fine on FC4 which makes me think your patching has not been as successful as you think), we would still not have the same environment you do since you claim to maintain your binaries by hand. Unless you are willing to add the explicit casts yourself, I think you are probably SOL. On Wed, Mar 26, 2014 at 3:02 AM, Dale Walsh d...@daleenterprise.com wrote: You ask for details so here they are. I don't use MacPorts or any other non-standard build environment, I don't suffer compiler bugs so I don't need 'CCFLAGS=-O0 to correct a buggy compiler and I have applied every patch and bug-fix released and experience no build issues with any other software source. Here's what I start with: Using gcc-3.3 (it's old but it compiles for ppc) cd /private/var/tmp/clamav/clamav-1.obj CFLAGS=-arch ppc -g -Os -pipe -pipe -no-cpp-precomp -arch ppc CCFLAGS=-arch ppc -g -Os -pipe CXXFLAGS=-arch ppc -g -Os -pipe LDFLAGS=-arch ppc TEXI2HTML=/usr/bin/texi2html -subdir . rm -rf /tmp/clamav/Release mkdir -p /tmp/clamav/Debug ln -sf /CLAMAV_BUILD/Release /tmp/clamav/Release CFLAGS=-DFD_SETSIZE=2048 ./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc --enable-bigstack --with-user=clamav --with-group=clamav --with-dbdir=/var/clamav --disable-clamav make make install # no issues with the build or install but nothing seems to works and segfaults (expected behavior) Using gcc-3.3 cd /private/var/tmp/clamav/clamav-1.obj CFLAGS=-arch ppc -arch i386 -g -Os -pipe -pipe -no-cpp-precomp -arch ppc -arch i386 CCFLAGS=-arch ppc -arch i386 -g -Os -pipe CXXFLAGS=-arch ppc -arch i386 -g -Os -pipe LDFLAGS=-arch ppc -arch i386 TEXI2HTML=/usr/bin/texi2html -subdir . rm -rf /tmp/clamav/Release mkdir -p /tmp/clamav/Debug ln -sf /CLAMAV_BUILD/Release /tmp/clamav/Release CFLAGS=-DFD_SETSIZE=2048 ./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc --enable-bigstack --with-user=clamav --with-group=clamav --with-dbdir=/var/clamav --disable-clamav make fails with: ld: Undefined
Re: [Clamav-devel] enabling DMG and XAR support
FYI, This just in (from clamdoc.pdf): quote The following packages are optional, but required for bytecode JIT support: GCC C and C++ compilers (minimum 4.1.3, recommended 4.3.4 or newer) the package for these compilers are usually called: gcc, g++, or gcc-c++. /quote Mileage may be better in those cases by using ./configure --enable-llvm=no On Wed, Mar 26, 2014 at 3:06 PM, Brandon Perry bperry.volat...@gmail.comwrote: FWIW i am currently asking friends if they have a PPC that i can try this one. Sent from a computer On Mar 26, 2014, at 1:37 PM, Brandon Perry bperry.volat...@gmail.com wrote: You must not have read my email. I was not saying it is your build tool. I said it was your architecture causing the LLVM type to not be implicitly casted to a long int, likely due to register sizes on the PPC platform. You will need to modify the code to explicitly cast the LLVM type to a long int so that it compiles on your architecture. Sent from a computer On Mar 26, 2014, at 12:58 PM, Dale Walsh d...@daleenterprise.com wrote: Why do people have to be so stupid and immediately implicate the build tools or environment? Because updates and bug-fixes were applied, your assuming that these are not done correctly or in compliance with the OS and build environment or that they are faulty. First, you need to stop this bull-crap about non-standard and heavily modified and listen to the details regarding the issue you are told and stop focusing on the build tools which you have no clue about. It is best that you accept my word that it is standard and in compliance with the OS, build environment and ADE. I have confirmed the issue still exists under gcc-4.4 so it's not a build tool issue. I now have generated a fully working ClamAV 0.98.1 under gcc-3.3, gcc-4.0.0 and gcc 4.0.1 by cleanly autoreconf-ing the source tree. Here's my configure for the working builds under the mentioned compilers: CFLAGS=-arch ppc -arch i386 -g -Os -pipe -DFD_SETSIZE=2048 -arch ppc -arch i386 CCFLAGS=-arch ppc -arch i386 -g -Os -pipe CXXFLAGS=-arch ppc -arch i386 -g -Os -pipe LDFLAGS=-arch ppc -arch i386 ./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc --enable-bigstack --with-user=clamav --with-group=clamav --with-dbdir=/var/clamav --disable-clamav Is using ltmain.sh from Debian-Ubuntu called portability amongst different environments?? -- Dale On Mar 26, 2014, at 09:06 AM, Brandon Perry wrote: I don't use MacPorts or any other non-standard build environment... Your entire build system is non-standard if you maintain in the way you say you do. This is very likely an architecture issue and will require explicit casts in order to work for you (which would cause performance decreases for every other ClamAV user). Would you expect the ClamAV project to maintain this? You say you have submitted code in the past, you will likely need to make this work yourself by adding the explicit casts to the codebase. This really isn't an issue with ClamAV or LLVM/Clang. You have a system that is relatively unsupportable because of A) age and B) you have *heavily* modified it at this point to attempt to maintain it. Even if one of us had an old PPC with gcc 4.0 (which compiles ClamAV just fine on FC4 which makes me think your patching has not been as successful as you think), we would still not have the same environment you do since you claim to maintain your binaries by hand. Unless you are willing to add the explicit casts yourself, I think you are probably SOL. On Wed, Mar 26, 2014 at 3:02 AM, Dale Walsh d...@daleenterprise.com wrote: You ask for details so here they are. I don't use MacPorts or any other non-standard build environment, I don't suffer compiler bugs so I don't need 'CCFLAGS=-O0 to correct a buggy compiler and I have applied every patch and bug-fix released and experience no build issues with any other software source. Here's what I start with: Using gcc-3.3 (it's old but it compiles for ppc) cd /private/var/tmp/clamav/clamav-1.obj CFLAGS=-arch ppc -g -Os -pipe -pipe -no-cpp-precomp -arch ppc CCFLAGS=-arch ppc -g -Os -pipe CXXFLAGS=-arch ppc -g -Os -pipe LDFLAGS=-arch ppc TEXI2HTML=/usr/bin/texi2html -subdir . rm -rf /tmp/clamav/Release mkdir -p /tmp/clamav/Debug ln -sf /CLAMAV_BUILD/Release /tmp/clamav/Release CFLAGS=-DFD_SETSIZE=2048 ./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc --enable-bigstack --with-user=clamav --with-group=clamav --with-dbdir=/var/clamav --disable-clamav make make install # no issues with the build or install but nothing seems to works and segfaults (expected behavior) Using gcc-3.3 cd /private/var/tmp/clamav/clamav-1.obj CFLAGS=-arch ppc -arch i386 -g -Os -pipe -pipe -no-cpp-precomp -arch ppc -arch i386 CCFLAGS=-arch ppc
Re: [Clamav-devel] enabling DMG and XAR support
This also might be worth trying. Dale, could you try appending this to your configure line and see if it resolves the issue with your 4.x compiler? Sent from a computer On Mar 26, 2014, at 2:19 PM, Steven Morgan smor...@sourcefire.com wrote: FYI, This just in (from clamdoc.pdf): quote The following packages are optional, but required for bytecode JIT support: GCC C and C++ compilers (minimum 4.1.3, recommended 4.3.4 or newer) the package for these compilers are usually called: gcc, g++, or gcc-c++. /quote Mileage may be better in those cases by using ./configure --enable-llvm=no On Wed, Mar 26, 2014 at 3:06 PM, Brandon Perry bperry.volat...@gmail.comwrote: FWIW i am currently asking friends if they have a PPC that i can try this one. Sent from a computer On Mar 26, 2014, at 1:37 PM, Brandon Perry bperry.volat...@gmail.com wrote: You must not have read my email. I was not saying it is your build tool. I said it was your architecture causing the LLVM type to not be implicitly casted to a long int, likely due to register sizes on the PPC platform. You will need to modify the code to explicitly cast the LLVM type to a long int so that it compiles on your architecture. Sent from a computer On Mar 26, 2014, at 12:58 PM, Dale Walsh d...@daleenterprise.com wrote: Why do people have to be so stupid and immediately implicate the build tools or environment? Because updates and bug-fixes were applied, your assuming that these are not done correctly or in compliance with the OS and build environment or that they are faulty. First, you need to stop this bull-crap about non-standard and heavily modified and listen to the details regarding the issue you are told and stop focusing on the build tools which you have no clue about. It is best that you accept my word that it is standard and in compliance with the OS, build environment and ADE. I have confirmed the issue still exists under gcc-4.4 so it's not a build tool issue. I now have generated a fully working ClamAV 0.98.1 under gcc-3.3, gcc-4.0.0 and gcc 4.0.1 by cleanly autoreconf-ing the source tree. Here's my configure for the working builds under the mentioned compilers: CFLAGS=-arch ppc -arch i386 -g -Os -pipe -DFD_SETSIZE=2048 -arch ppc -arch i386 CCFLAGS=-arch ppc -arch i386 -g -Os -pipe CXXFLAGS=-arch ppc -arch i386 -g -Os -pipe LDFLAGS=-arch ppc -arch i386 ./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc --enable-bigstack --with-user=clamav --with-group=clamav --with-dbdir=/var/clamav --disable-clamav Is using ltmain.sh from Debian-Ubuntu called portability amongst different environments?? -- Dale On Mar 26, 2014, at 09:06 AM, Brandon Perry wrote: I don't use MacPorts or any other non-standard build environment... Your entire build system is non-standard if you maintain in the way you say you do. This is very likely an architecture issue and will require explicit casts in order to work for you (which would cause performance decreases for every other ClamAV user). Would you expect the ClamAV project to maintain this? You say you have submitted code in the past, you will likely need to make this work yourself by adding the explicit casts to the codebase. This really isn't an issue with ClamAV or LLVM/Clang. You have a system that is relatively unsupportable because of A) age and B) you have *heavily* modified it at this point to attempt to maintain it. Even if one of us had an old PPC with gcc 4.0 (which compiles ClamAV just fine on FC4 which makes me think your patching has not been as successful as you think), we would still not have the same environment you do since you claim to maintain your binaries by hand. Unless you are willing to add the explicit casts yourself, I think you are probably SOL. On Wed, Mar 26, 2014 at 3:02 AM, Dale Walsh d...@daleenterprise.com wrote: You ask for details so here they are. I don't use MacPorts or any other non-standard build environment, I don't suffer compiler bugs so I don't need 'CCFLAGS=-O0 to correct a buggy compiler and I have applied every patch and bug-fix released and experience no build issues with any other software source. Here's what I start with: Using gcc-3.3 (it's old but it compiles for ppc) cd /private/var/tmp/clamav/clamav-1.obj CFLAGS=-arch ppc -g -Os -pipe -pipe -no-cpp-precomp -arch ppc CCFLAGS=-arch ppc -g -Os -pipe CXXFLAGS=-arch ppc -g -Os -pipe LDFLAGS=-arch ppc TEXI2HTML=/usr/bin/texi2html -subdir . rm -rf /tmp/clamav/Release mkdir -p /tmp/clamav/Debug ln -sf /CLAMAV_BUILD/Release /tmp/clamav/Release CFLAGS=-DFD_SETSIZE=2048 ./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc --enable-bigstack --with-user=clamav --with-group=clamav --with-dbdir=/var/clamav --disable-clamav make make install # no issues with the build or install but nothing seems
Re: [Clamav-devel] enabling DMG and XAR support
You're right, it shouldn't matter, PowerPC The next question coming will be OS related so I'll answer ahead of time, OS is Mac OS X 10.4.x. The reason is simple, I must support the OS the customer uses so there is no upgrading the OS, no changing OS and no changing the hardware. Since it stopped building correctly/completely under GCC 4.x we were left with no choice but to abandon it. -- Dale On Mar 24, 2014, at 18:57 PM, Brandon Perry wrote: Dale, Not that it *should* matter, but what is your architecture? On 03/24/2014 05:33 PM, Shawn Webb wrote: On what up-to-date OSs can I find gcc 4.0 in active use? I'll briefly try to recreate the problem in my spare time for you. On Mon, Mar 24, 2014 at 6:22 PM, Dale Walsh d...@daleenterprise.com wrote: When it builds completely under GCC 4.0, I would be more than happy to offer detailed debugging information and dumps that would be beneficial to the project but as it stands, a bug report at bugzilla.clamav.net isn't anything I would consider wasting my time on but you are more than welcome to file the report yourself. It makes no sense for me to file a report as I may use the source files but nothing else, I repackage it so I can build it and rather than listen to stupidity about my method of building being the root of the problem, informing you like other have should be sufficient to warrant an in-depth investigation into the matter. -- Dale On Mar 24, 2014, at 17:32 PM, Steven Morgan wrote: Yes, a dmg issue and an xar issue were mentioned. If the issue (s) remain, please open a bug at bugzilla.clamav.net or send some files or -- debug output. On Sun, Mar 23, 2014 at 5:17 PM, Joel Esler (jesler) jes...@cisco.com wrote: Then I am sure the developers would be glad to help figure out the problem and fix it. -- Joel Esler Sent from my iPhone On Mar 22, 2014, at 13:32, Dale Walsh d...@daleenterprise.com wrote: 0.98.1 DMG does not work. -- Dale On Mar 21, 2014, at 09:16 AM, Joel Esler (jesler) wrote: DMG support was just added in the last version of ClamAV. How long ago did you do this testing? On Mar 20, 2014, at 8:22 PM, Dale Walsh d...@daleenterprise.com wrote: You did miss it but it's a two headed nail. PDF, DMG, XAR and RAR have had issues not recognizing the test viruses to name just a couple that spring to mind that we've had trouble with and this all started happening when the clang and crap entered the picture. I've worked with the developers in the past, once the build environment dependancies changed and I was told I had to upgrade my OS and build tools is when it was no longer possible to resolve these issues as the update solely for the purpose of building ClamAV is not an option and I shouldn't be forced to use someone else's built tool preferences just because they have the luxury of updating on a whim or purely for bragging rights. It does not matter if my OS is dated, security patches are applied to the build tools as they become available and this seems to satisfy all other software that build from source except ClamAV. Having everything build with GCC 4.0 would allow me/us to re- deploy ClamAV and contribute to the code base again (I have in the past) but the chances of this are slim to non from what I recall because my OS and build tools are dated and listening to rants about ancient and deprecated is nothing more than someone spewing stupidity. The fact that I ensure all bugs and updates to the build tools are fixed/added allows me to keep everything in harmony and there is no reason to update anything to build a single software package when all other software sources seem to be content with the existing build environment. If you wish to go off-list to continue the discussion I have no objections. -- Dale On Mar 20, 2014, at 16:35 PM, Joel Esler (jesler) wrote: Dale, Thanks for your email. I'm not sure exactly what you are referring to. Maybe I am missing a connection here or something, but the discussion was around scanning DMG and XAR, which I think, if there's a issue with, we'd be more than happy to work with anyone to try and square away. You seem to be discussing a build issue, and you say that it's a waste of time. When did you get the impression that working with the developers was a waste of time? If we're not communicating well enough, we can fix that. But I think the team is doing a good job of that judging by the amount of complaints I have received since we took over the project from the old ClamAV team. Please let me know if we need to take this offline and discuss or anything I can do to help. -- Joel Esler Open Source Manager Threat Intelligence Team Lead Vulnerability Research Team On Mar 20, 2014, at 3:55 PM, Dale Walsh d...@daleenterprise.com mailto:d...@daleenterprise.com wrote: Mark, this has been an issue for many versions
Re: [Clamav-devel] enabling DMG and XAR support
Thanks, I don't have a PPC here, but I am going to install fedora core 4 x86 and x86_64 inside of virtual machines and will see if I run into any issues. Legacy systems are unfortunate. However, I think you would be hard pressed to find any open source project today supporting that, so I don't think it is that ridiculous to not expend the effort to actively support it. I wouldn't be surprised if the code required to make it compile on your system *and* modern systems caused performance decreases (or even not compile on modern gcc!). There might be a small chance that you would need to maintain a separate patchset to maintain this compatibility since having it compile on both your legacy and modern systems would be detrimental to other ClamAV users. On 03/25/2014 05:18 PM, Dale Walsh wrote: You're right, it shouldn't matter, PowerPC The next question coming will be OS related so I'll answer ahead of time, OS is Mac OS X 10.4.x. The reason is simple, I must support the OS the customer uses so there is no upgrading the OS, no changing OS and no changing the hardware. Since it stopped building correctly/completely under GCC 4.x we were left with no choice but to abandon it. -- Dale On Mar 24, 2014, at 18:57 PM, Brandon Perry wrote: Dale, Not that it *should* matter, but what is your architecture? On 03/24/2014 05:33 PM, Shawn Webb wrote: On what up-to-date OSs can I find gcc 4.0 in active use? I'll briefly try to recreate the problem in my spare time for you. On Mon, Mar 24, 2014 at 6:22 PM, Dale Walsh d...@daleenterprise.com wrote: When it builds completely under GCC 4.0, I would be more than happy to offer detailed debugging information and dumps that would be beneficial to the project but as it stands, a bug report at bugzilla.clamav.net isn't anything I would consider wasting my time on but you are more than welcome to file the report yourself. It makes no sense for me to file a report as I may use the source files but nothing else, I repackage it so I can build it and rather than listen to stupidity about my method of building being the root of the problem, informing you like other have should be sufficient to warrant an in-depth investigation into the matter. -- Dale On Mar 24, 2014, at 17:32 PM, Steven Morgan wrote: Yes, a dmg issue and an xar issue were mentioned. If the issue(s) remain, please open a bug at bugzilla.clamav.net or send some files or --debug output. On Sun, Mar 23, 2014 at 5:17 PM, Joel Esler (jesler) jes...@cisco.com wrote: Then I am sure the developers would be glad to help figure out the problem and fix it. -- Joel Esler Sent from my iPhone On Mar 22, 2014, at 13:32, Dale Walsh d...@daleenterprise.com wrote: 0.98.1 DMG does not work. -- Dale On Mar 21, 2014, at 09:16 AM, Joel Esler (jesler) wrote: DMG support was just added in the last version of ClamAV. How long ago did you do this testing? On Mar 20, 2014, at 8:22 PM, Dale Walsh d...@daleenterprise.com wrote: You did miss it but it's a two headed nail. PDF, DMG, XAR and RAR have had issues not recognizing the test viruses to name just a couple that spring to mind that we've had trouble with and this all started happening when the clang and crap entered the picture. I've worked with the developers in the past, once the build environment dependancies changed and I was told I had to upgrade my OS and build tools is when it was no longer possible to resolve these issues as the update solely for the purpose of building ClamAV is not an option and I shouldn't be forced to use someone else's built tool preferences just because they have the luxury of updating on a whim or purely for bragging rights. It does not matter if my OS is dated, security patches are applied to the build tools as they become available and this seems to satisfy all other software that build from source except ClamAV. Having everything build with GCC 4.0 would allow me/us to re-deploy ClamAV and contribute to the code base again (I have in the past) but the chances of this are slim to non from what I recall because my OS and build tools are dated and listening to rants about ancient and deprecated is nothing more than someone spewing stupidity. The fact that I ensure all bugs and updates to the build tools are fixed/added allows me to keep everything in harmony and there is no reason to update anything to build a single software package when all other software sources seem to be content with the existing build environment. If you wish to go off-list to continue the discussion I have no objections. -- Dale On Mar 20, 2014, at 16:35 PM, Joel Esler (jesler) wrote: Dale, Thanks for your email. I'm not sure exactly what you are referring to. Maybe I am missing a connection here or something, but the discussion was around scanning DMG and XAR, which I think, if there's a issue with, we'd be more
Re: [Clamav-devel] enabling DMG and XAR support
'CCFLAGS=-O0 ./configure make' [root@localhost clamav-0.98.1]# clamscan/clamscan --version ClamAV 0.98.1 [root@localhost clamav-0.98.1]# uname -a Linux localhost.localdomain 2.6.11-1.1369_FC4 #1 Thu Jun 2 22:55:56 EDT 2005 i686 athlon i386 GNU/Linux [root@localhost clamav-0.98.1]# If you don't set CCFLAGS configure fails because of an optimization bug in the compiler, which is what I am assuming you are talking about by doesn't compile. Being nice gets you more friends on the internet, and everyone knows internet friends are the best kind of friends. :) On 03/25/2014 05:29 PM, Brandon Perry wrote: Thanks, I don't have a PPC here, but I am going to install fedora core 4 x86 and x86_64 inside of virtual machines and will see if I run into any issues. Legacy systems are unfortunate. However, I think you would be hard pressed to find any open source project today supporting that, so I don't think it is that ridiculous to not expend the effort to actively support it. I wouldn't be surprised if the code required to make it compile on your system *and* modern systems caused performance decreases (or even not compile on modern gcc!). There might be a small chance that you would need to maintain a separate patchset to maintain this compatibility since having it compile on both your legacy and modern systems would be detrimental to other ClamAV users. On 03/25/2014 05:18 PM, Dale Walsh wrote: You're right, it shouldn't matter, PowerPC The next question coming will be OS related so I'll answer ahead of time, OS is Mac OS X 10.4.x. The reason is simple, I must support the OS the customer uses so there is no upgrading the OS, no changing OS and no changing the hardware. Since it stopped building correctly/completely under GCC 4.x we were left with no choice but to abandon it. -- Dale On Mar 24, 2014, at 18:57 PM, Brandon Perry wrote: Dale, Not that it *should* matter, but what is your architecture? On 03/24/2014 05:33 PM, Shawn Webb wrote: On what up-to-date OSs can I find gcc 4.0 in active use? I'll briefly try to recreate the problem in my spare time for you. On Mon, Mar 24, 2014 at 6:22 PM, Dale Walsh d...@daleenterprise.com wrote: When it builds completely under GCC 4.0, I would be more than happy to offer detailed debugging information and dumps that would be beneficial to the project but as it stands, a bug report at bugzilla.clamav.net isn't anything I would consider wasting my time on but you are more than welcome to file the report yourself. It makes no sense for me to file a report as I may use the source files but nothing else, I repackage it so I can build it and rather than listen to stupidity about my method of building being the root of the problem, informing you like other have should be sufficient to warrant an in-depth investigation into the matter. -- Dale On Mar 24, 2014, at 17:32 PM, Steven Morgan wrote: Yes, a dmg issue and an xar issue were mentioned. If the issue(s) remain, please open a bug at bugzilla.clamav.net or send some files or --debug output. On Sun, Mar 23, 2014 at 5:17 PM, Joel Esler (jesler) jes...@cisco.com wrote: Then I am sure the developers would be glad to help figure out the problem and fix it. -- Joel Esler Sent from my iPhone On Mar 22, 2014, at 13:32, Dale Walsh d...@daleenterprise.com wrote: 0.98.1 DMG does not work. -- Dale On Mar 21, 2014, at 09:16 AM, Joel Esler (jesler) wrote: DMG support was just added in the last version of ClamAV. How long ago did you do this testing? On Mar 20, 2014, at 8:22 PM, Dale Walsh d...@daleenterprise.com wrote: You did miss it but it's a two headed nail. PDF, DMG, XAR and RAR have had issues not recognizing the test viruses to name just a couple that spring to mind that we've had trouble with and this all started happening when the clang and crap entered the picture. I've worked with the developers in the past, once the build environment dependancies changed and I was told I had to upgrade my OS and build tools is when it was no longer possible to resolve these issues as the update solely for the purpose of building ClamAV is not an option and I shouldn't be forced to use someone else's built tool preferences just because they have the luxury of updating on a whim or purely for bragging rights. It does not matter if my OS is dated, security patches are applied to the build tools as they become available and this seems to satisfy all other software that build from source except ClamAV. Having everything build with GCC 4.0 would allow me/us to re-deploy ClamAV and contribute to the code base again (I have in the past) but the chances of this are slim to non from what I recall because my OS and build tools are dated and listening to rants about ancient and deprecated is nothing more than someone spewing stupidity. The fact that I ensure all bugs and updates to the build tools
Re: [Clamav-devel] enabling DMG and XAR support
Sorry, gcc version: [root@localhost clamav-0.98.1]# gcc --version gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [root@localhost clamav-0.98.1]# On 03/25/2014 05:54 PM, Brandon Perry wrote: 'CCFLAGS=-O0 ./configure make' [root@localhost clamav-0.98.1]# clamscan/clamscan --version ClamAV 0.98.1 [root@localhost clamav-0.98.1]# uname -a Linux localhost.localdomain 2.6.11-1.1369_FC4 #1 Thu Jun 2 22:55:56 EDT 2005 i686 athlon i386 GNU/Linux [root@localhost clamav-0.98.1]# If you don't set CCFLAGS configure fails because of an optimization bug in the compiler, which is what I am assuming you are talking about by doesn't compile. Being nice gets you more friends on the internet, and everyone knows internet friends are the best kind of friends. :) On 03/25/2014 05:29 PM, Brandon Perry wrote: Thanks, I don't have a PPC here, but I am going to install fedora core 4 x86 and x86_64 inside of virtual machines and will see if I run into any issues. Legacy systems are unfortunate. However, I think you would be hard pressed to find any open source project today supporting that, so I don't think it is that ridiculous to not expend the effort to actively support it. I wouldn't be surprised if the code required to make it compile on your system *and* modern systems caused performance decreases (or even not compile on modern gcc!). There might be a small chance that you would need to maintain a separate patchset to maintain this compatibility since having it compile on both your legacy and modern systems would be detrimental to other ClamAV users. On 03/25/2014 05:18 PM, Dale Walsh wrote: You're right, it shouldn't matter, PowerPC The next question coming will be OS related so I'll answer ahead of time, OS is Mac OS X 10.4.x. The reason is simple, I must support the OS the customer uses so there is no upgrading the OS, no changing OS and no changing the hardware. Since it stopped building correctly/completely under GCC 4.x we were left with no choice but to abandon it. -- Dale On Mar 24, 2014, at 18:57 PM, Brandon Perry wrote: Dale, Not that it *should* matter, but what is your architecture? On 03/24/2014 05:33 PM, Shawn Webb wrote: On what up-to-date OSs can I find gcc 4.0 in active use? I'll briefly try to recreate the problem in my spare time for you. On Mon, Mar 24, 2014 at 6:22 PM, Dale Walsh d...@daleenterprise.com wrote: When it builds completely under GCC 4.0, I would be more than happy to offer detailed debugging information and dumps that would be beneficial to the project but as it stands, a bug report at bugzilla.clamav.net isn't anything I would consider wasting my time on but you are more than welcome to file the report yourself. It makes no sense for me to file a report as I may use the source files but nothing else, I repackage it so I can build it and rather than listen to stupidity about my method of building being the root of the problem, informing you like other have should be sufficient to warrant an in-depth investigation into the matter. -- Dale On Mar 24, 2014, at 17:32 PM, Steven Morgan wrote: Yes, a dmg issue and an xar issue were mentioned. If the issue(s) remain, please open a bug at bugzilla.clamav.net or send some files or --debug output. On Sun, Mar 23, 2014 at 5:17 PM, Joel Esler (jesler) jes...@cisco.com wrote: Then I am sure the developers would be glad to help figure out the problem and fix it. -- Joel Esler Sent from my iPhone On Mar 22, 2014, at 13:32, Dale Walsh d...@daleenterprise.com wrote: 0.98.1 DMG does not work. -- Dale On Mar 21, 2014, at 09:16 AM, Joel Esler (jesler) wrote: DMG support was just added in the last version of ClamAV. How long ago did you do this testing? On Mar 20, 2014, at 8:22 PM, Dale Walsh d...@daleenterprise.com wrote: You did miss it but it's a two headed nail. PDF, DMG, XAR and RAR have had issues not recognizing the test viruses to name just a couple that spring to mind that we've had trouble with and this all started happening when the clang and crap entered the picture. I've worked with the developers in the past, once the build environment dependancies changed and I was told I had to upgrade my OS and build tools is when it was no longer possible to resolve these issues as the update solely for the purpose of building ClamAV is not an option and I shouldn't be forced to use someone else's built tool preferences just because they have the luxury of updating on a whim or purely for bragging rights. It does not matter if my OS is dated, security patches are applied to the build tools as they become available and this seems to satisfy all other software that build from source except ClamAV.
Re: [Clamav-devel] enabling DMG and XAR support
Yes, a dmg issue and an xar issue were mentioned. If the issue(s) remain, please open a bug at bugzilla.clamav.net or send some files or --debug output. On Sun, Mar 23, 2014 at 5:17 PM, Joel Esler (jesler) jes...@cisco.comwrote: Then I am sure the developers would be glad to help figure out the problem and fix it. -- Joel Esler Sent from my iPhone On Mar 22, 2014, at 13:32, Dale Walsh d...@daleenterprise.com wrote: 0.98.1 DMG does not work. -- Dale On Mar 21, 2014, at 09:16 AM, Joel Esler (jesler) wrote: DMG support was just added in the last version of ClamAV. How long ago did you do this testing? On Mar 20, 2014, at 8:22 PM, Dale Walsh d...@daleenterprise.com wrote: You did miss it but it's a two headed nail. PDF, DMG, XAR and RAR have had issues not recognizing the test viruses to name just a couple that spring to mind that we've had trouble with and this all started happening when the clang and crap entered the picture. I've worked with the developers in the past, once the build environment dependancies changed and I was told I had to upgrade my OS and build tools is when it was no longer possible to resolve these issues as the update solely for the purpose of building ClamAV is not an option and I shouldn't be forced to use someone else's built tool preferences just because they have the luxury of updating on a whim or purely for bragging rights. It does not matter if my OS is dated, security patches are applied to the build tools as they become available and this seems to satisfy all other software that build from source except ClamAV. Having everything build with GCC 4.0 would allow me/us to re-deploy ClamAV and contribute to the code base again (I have in the past) but the chances of this are slim to non from what I recall because my OS and build tools are dated and listening to rants about ancient and deprecated is nothing more than someone spewing stupidity. The fact that I ensure all bugs and updates to the build tools are fixed/added allows me to keep everything in harmony and there is no reason to update anything to build a single software package when all other software sources seem to be content with the existing build environment. If you wish to go off-list to continue the discussion I have no objections. -- Dale On Mar 20, 2014, at 16:35 PM, Joel Esler (jesler) wrote: Dale, Thanks for your email. I'm not sure exactly what you are referring to. Maybe I am missing a connection here or something, but the discussion was around scanning DMG and XAR, which I think, if there's a issue with, we'd be more than happy to work with anyone to try and square away. You seem to be discussing a build issue, and you say that it's a waste of time. When did you get the impression that working with the developers was a waste of time? If we're not communicating well enough, we can fix that. But I think the team is doing a good job of that judging by the amount of complaints I have received since we took over the project from the old ClamAV team. Please let me know if we need to take this offline and discuss or anything I can do to help. -- Joel Esler Open Source Manager Threat Intelligence Team Lead Vulnerability Research Team On Mar 20, 2014, at 3:55 PM, Dale Walsh d...@daleenterprise.com mailto:d...@daleenterprise.com wrote: Mark, this has been an issue for many versions along with a slew of others things not working as expected. As much as I liked ClamAV, we've abandoned it as a mail solution shortly after things stopped working correctly and they changed the required build tools so you can no longer build it with GCC 3.3/4.0/4.1/4.2 and have a fully functional app. Yes there are flags to get it to build but certain modules and features don't build and making an incomplete and partially functional binary isn't appealing. Advice on updating build tools is a waste of time as there is no reason to update the build tools just to build ClamAV as it's the only one that has this ridiculous built-tool requirement and only an idiot would tell me to update. My thoughts on this is simple, if it doesn't build with the basic GNU GCC compiler tools then it's seriously flawed and needs these other tools to overcome the short-comings of poorly written/implemented code. When I say build, I mean build with full functionality so don't go off the deep-end stating it builds, partial functionality may be acceptable to you bhut it isn't to me. At this time, for personal use, I use the source code but repackage the build environment to work with what I have and I'm comfortable with submitting corrections and patches, too much focus and complaints on my build tools so why waste my time. -- Dale On Mar 19, 2014, at 11:34 AM, Rafael Ferreira wrote: Interesting... let me run some tests and get back to you. On Mar 19, 2014, at 8:33
Re: [Clamav-devel] enabling DMG and XAR support
When it builds completely under GCC 4.0, I would be more than happy to offer detailed debugging information and dumps that would be beneficial to the project but as it stands, a bug report at bugzilla.clamav.net isn't anything I would consider wasting my time on but you are more than welcome to file the report yourself. It makes no sense for me to file a report as I may use the source files but nothing else, I repackage it so I can build it and rather than listen to stupidity about my method of building being the root of the problem, informing you like other have should be sufficient to warrant an in-depth investigation into the matter. -- Dale On Mar 24, 2014, at 17:32 PM, Steven Morgan wrote: Yes, a dmg issue and an xar issue were mentioned. If the issue(s) remain, please open a bug at bugzilla.clamav.net or send some files or --debug output. On Sun, Mar 23, 2014 at 5:17 PM, Joel Esler (jesler) jes...@cisco.comwrote: Then I am sure the developers would be glad to help figure out the problem and fix it. -- Joel Esler Sent from my iPhone On Mar 22, 2014, at 13:32, Dale Walsh d...@daleenterprise.com wrote: 0.98.1 DMG does not work. -- Dale On Mar 21, 2014, at 09:16 AM, Joel Esler (jesler) wrote: DMG support was just added in the last version of ClamAV. How long ago did you do this testing? On Mar 20, 2014, at 8:22 PM, Dale Walsh d...@daleenterprise.com wrote: You did miss it but it's a two headed nail. PDF, DMG, XAR and RAR have had issues not recognizing the test viruses to name just a couple that spring to mind that we've had trouble with and this all started happening when the clang and crap entered the picture. I've worked with the developers in the past, once the build environment dependancies changed and I was told I had to upgrade my OS and build tools is when it was no longer possible to resolve these issues as the update solely for the purpose of building ClamAV is not an option and I shouldn't be forced to use someone else's built tool preferences just because they have the luxury of updating on a whim or purely for bragging rights. It does not matter if my OS is dated, security patches are applied to the build tools as they become available and this seems to satisfy all other software that build from source except ClamAV. Having everything build with GCC 4.0 would allow me/us to re- deploy ClamAV and contribute to the code base again (I have in the past) but the chances of this are slim to non from what I recall because my OS and build tools are dated and listening to rants about ancient and deprecated is nothing more than someone spewing stupidity. The fact that I ensure all bugs and updates to the build tools are fixed/added allows me to keep everything in harmony and there is no reason to update anything to build a single software package when all other software sources seem to be content with the existing build environment. If you wish to go off-list to continue the discussion I have no objections. -- Dale On Mar 20, 2014, at 16:35 PM, Joel Esler (jesler) wrote: Dale, Thanks for your email. I'm not sure exactly what you are referring to. Maybe I am missing a connection here or something, but the discussion was around scanning DMG and XAR, which I think, if there's a issue with, we'd be more than happy to work with anyone to try and square away. You seem to be discussing a build issue, and you say that it's a waste of time. When did you get the impression that working with the developers was a waste of time? If we're not communicating well enough, we can fix that. But I think the team is doing a good job of that judging by the amount of complaints I have received since we took over the project from the old ClamAV team. Please let me know if we need to take this offline and discuss or anything I can do to help. -- Joel Esler Open Source Manager Threat Intelligence Team Lead Vulnerability Research Team On Mar 20, 2014, at 3:55 PM, Dale Walsh d...@daleenterprise.com mailto:d...@daleenterprise.com wrote: Mark, this has been an issue for many versions along with a slew of others things not working as expected. As much as I liked ClamAV, we've abandoned it as a mail solution shortly after things stopped working correctly and they changed the required build tools so you can no longer build it with GCC 3.3/4.0/4.1/4.2 and have a fully functional app. Yes there are flags to get it to build but certain modules and features don't build and making an incomplete and partially functional binary isn't appealing. Advice on updating build tools is a waste of time as there is no reason to update the build tools just to build ClamAV as it's the only one that has this ridiculous built-tool requirement and only an idiot would tell me to update. My thoughts on this is simple, if it doesn't build with the basic GNU GCC compiler tools then it's
Re: [Clamav-devel] enabling DMG and XAR support
On what up-to-date OSs can I find gcc 4.0 in active use? I'll briefly try to recreate the problem in my spare time for you. On Mon, Mar 24, 2014 at 6:22 PM, Dale Walsh d...@daleenterprise.com wrote: When it builds completely under GCC 4.0, I would be more than happy to offer detailed debugging information and dumps that would be beneficial to the project but as it stands, a bug report at bugzilla.clamav.net isn't anything I would consider wasting my time on but you are more than welcome to file the report yourself. It makes no sense for me to file a report as I may use the source files but nothing else, I repackage it so I can build it and rather than listen to stupidity about my method of building being the root of the problem, informing you like other have should be sufficient to warrant an in-depth investigation into the matter. -- Dale On Mar 24, 2014, at 17:32 PM, Steven Morgan wrote: Yes, a dmg issue and an xar issue were mentioned. If the issue(s) remain, please open a bug at bugzilla.clamav.net or send some files or --debug output. On Sun, Mar 23, 2014 at 5:17 PM, Joel Esler (jesler) jes...@cisco.com wrote: Then I am sure the developers would be glad to help figure out the problem and fix it. -- Joel Esler Sent from my iPhone On Mar 22, 2014, at 13:32, Dale Walsh d...@daleenterprise.com wrote: 0.98.1 DMG does not work. -- Dale On Mar 21, 2014, at 09:16 AM, Joel Esler (jesler) wrote: DMG support was just added in the last version of ClamAV. How long ago did you do this testing? On Mar 20, 2014, at 8:22 PM, Dale Walsh d...@daleenterprise.com wrote: You did miss it but it's a two headed nail. PDF, DMG, XAR and RAR have had issues not recognizing the test viruses to name just a couple that spring to mind that we've had trouble with and this all started happening when the clang and crap entered the picture. I've worked with the developers in the past, once the build environment dependancies changed and I was told I had to upgrade my OS and build tools is when it was no longer possible to resolve these issues as the update solely for the purpose of building ClamAV is not an option and I shouldn't be forced to use someone else's built tool preferences just because they have the luxury of updating on a whim or purely for bragging rights. It does not matter if my OS is dated, security patches are applied to the build tools as they become available and this seems to satisfy all other software that build from source except ClamAV. Having everything build with GCC 4.0 would allow me/us to re-deploy ClamAV and contribute to the code base again (I have in the past) but the chances of this are slim to non from what I recall because my OS and build tools are dated and listening to rants about ancient and deprecated is nothing more than someone spewing stupidity. The fact that I ensure all bugs and updates to the build tools are fixed/added allows me to keep everything in harmony and there is no reason to update anything to build a single software package when all other software sources seem to be content with the existing build environment. If you wish to go off-list to continue the discussion I have no objections. -- Dale On Mar 20, 2014, at 16:35 PM, Joel Esler (jesler) wrote: Dale, Thanks for your email. I'm not sure exactly what you are referring to. Maybe I am missing a connection here or something, but the discussion was around scanning DMG and XAR, which I think, if there's a issue with, we'd be more than happy to work with anyone to try and square away. You seem to be discussing a build issue, and you say that it's a waste of time. When did you get the impression that working with the developers was a waste of time? If we're not communicating well enough, we can fix that. But I think the team is doing a good job of that judging by the amount of complaints I have received since we took over the project from the old ClamAV team. Please let me know if we need to take this offline and discuss or anything I can do to help. -- Joel Esler Open Source Manager Threat Intelligence Team Lead Vulnerability Research Team On Mar 20, 2014, at 3:55 PM, Dale Walsh d...@daleenterprise.com mailto:d...@daleenterprise.com wrote: Mark, this has been an issue for many versions along with a slew of others things not working as expected. As much as I liked ClamAV, we've abandoned it as a mail solution shortly after things stopped working correctly and they changed the required build tools so you can no longer build it with GCC 3.3/4.0/4.1/4.2 and have a fully functional app. Yes there are flags to get it to build but certain modules and features don't build and making an incomplete and partially functional binary isn't appealing. Advice on updating build tools is a waste of time as there is no reason to update the build tools just to build
Re: [Clamav-devel] enabling DMG and XAR support
Looks like fedora 3 and 4 shipped with 4.0. On 03/24/2014 05:33 PM, Shawn Webb wrote: On what up-to-date OSs can I find gcc 4.0 in active use? I'll briefly try to recreate the problem in my spare time for you. On Mon, Mar 24, 2014 at 6:22 PM, Dale Walsh d...@daleenterprise.com wrote: When it builds completely under GCC 4.0, I would be more than happy to offer detailed debugging information and dumps that would be beneficial to the project but as it stands, a bug report at bugzilla.clamav.net isn't anything I would consider wasting my time on but you are more than welcome to file the report yourself. It makes no sense for me to file a report as I may use the source files but nothing else, I repackage it so I can build it and rather than listen to stupidity about my method of building being the root of the problem, informing you like other have should be sufficient to warrant an in-depth investigation into the matter. -- Dale On Mar 24, 2014, at 17:32 PM, Steven Morgan wrote: Yes, a dmg issue and an xar issue were mentioned. If the issue(s) remain, please open a bug at bugzilla.clamav.net or send some files or --debug output. On Sun, Mar 23, 2014 at 5:17 PM, Joel Esler (jesler) jes...@cisco.com wrote: Then I am sure the developers would be glad to help figure out the problem and fix it. -- Joel Esler Sent from my iPhone On Mar 22, 2014, at 13:32, Dale Walsh d...@daleenterprise.com wrote: 0.98.1 DMG does not work. -- Dale On Mar 21, 2014, at 09:16 AM, Joel Esler (jesler) wrote: DMG support was just added in the last version of ClamAV. How long ago did you do this testing? On Mar 20, 2014, at 8:22 PM, Dale Walsh d...@daleenterprise.com wrote: You did miss it but it's a two headed nail. PDF, DMG, XAR and RAR have had issues not recognizing the test viruses to name just a couple that spring to mind that we've had trouble with and this all started happening when the clang and crap entered the picture. I've worked with the developers in the past, once the build environment dependancies changed and I was told I had to upgrade my OS and build tools is when it was no longer possible to resolve these issues as the update solely for the purpose of building ClamAV is not an option and I shouldn't be forced to use someone else's built tool preferences just because they have the luxury of updating on a whim or purely for bragging rights. It does not matter if my OS is dated, security patches are applied to the build tools as they become available and this seems to satisfy all other software that build from source except ClamAV. Having everything build with GCC 4.0 would allow me/us to re-deploy ClamAV and contribute to the code base again (I have in the past) but the chances of this are slim to non from what I recall because my OS and build tools are dated and listening to rants about ancient and deprecated is nothing more than someone spewing stupidity. The fact that I ensure all bugs and updates to the build tools are fixed/added allows me to keep everything in harmony and there is no reason to update anything to build a single software package when all other software sources seem to be content with the existing build environment. If you wish to go off-list to continue the discussion I have no objections. -- Dale On Mar 20, 2014, at 16:35 PM, Joel Esler (jesler) wrote: Dale, Thanks for your email. I'm not sure exactly what you are referring to. Maybe I am missing a connection here or something, but the discussion was around scanning DMG and XAR, which I think, if there's a issue with, we'd be more than happy to work with anyone to try and square away. You seem to be discussing a build issue, and you say that it's a waste of time. When did you get the impression that working with the developers was a waste of time? If we're not communicating well enough, we can fix that. But I think the team is doing a good job of that judging by the amount of complaints I have received since we took over the project from the old ClamAV team. Please let me know if we need to take this offline and discuss or anything I can do to help. -- Joel Esler Open Source Manager Threat Intelligence Team Lead Vulnerability Research Team On Mar 20, 2014, at 3:55 PM, Dale Walsh d...@daleenterprise.com mailto:d...@daleenterprise.com wrote: Mark, this has been an issue for many versions along with a slew of others things not working as expected. As much as I liked ClamAV, we've abandoned it as a mail solution shortly after things stopped working correctly and they changed the required build tools so you can no longer build it with GCC 3.3/4.0/4.1/4.2 and have a fully functional app. Yes there are flags to get it to build but certain modules and features don't build and making an incomplete and partially functional binary isn't appealing. Advice on updating build tools is a waste of time as
Re: [Clamav-devel] enabling DMG and XAR support
Dale, Not that it *should* matter, but what is your architecture? On 03/24/2014 05:33 PM, Shawn Webb wrote: On what up-to-date OSs can I find gcc 4.0 in active use? I'll briefly try to recreate the problem in my spare time for you. On Mon, Mar 24, 2014 at 6:22 PM, Dale Walsh d...@daleenterprise.com wrote: When it builds completely under GCC 4.0, I would be more than happy to offer detailed debugging information and dumps that would be beneficial to the project but as it stands, a bug report at bugzilla.clamav.net isn't anything I would consider wasting my time on but you are more than welcome to file the report yourself. It makes no sense for me to file a report as I may use the source files but nothing else, I repackage it so I can build it and rather than listen to stupidity about my method of building being the root of the problem, informing you like other have should be sufficient to warrant an in-depth investigation into the matter. -- Dale On Mar 24, 2014, at 17:32 PM, Steven Morgan wrote: Yes, a dmg issue and an xar issue were mentioned. If the issue(s) remain, please open a bug at bugzilla.clamav.net or send some files or --debug output. On Sun, Mar 23, 2014 at 5:17 PM, Joel Esler (jesler) jes...@cisco.com wrote: Then I am sure the developers would be glad to help figure out the problem and fix it. -- Joel Esler Sent from my iPhone On Mar 22, 2014, at 13:32, Dale Walsh d...@daleenterprise.com wrote: 0.98.1 DMG does not work. -- Dale On Mar 21, 2014, at 09:16 AM, Joel Esler (jesler) wrote: DMG support was just added in the last version of ClamAV. How long ago did you do this testing? On Mar 20, 2014, at 8:22 PM, Dale Walsh d...@daleenterprise.com wrote: You did miss it but it's a two headed nail. PDF, DMG, XAR and RAR have had issues not recognizing the test viruses to name just a couple that spring to mind that we've had trouble with and this all started happening when the clang and crap entered the picture. I've worked with the developers in the past, once the build environment dependancies changed and I was told I had to upgrade my OS and build tools is when it was no longer possible to resolve these issues as the update solely for the purpose of building ClamAV is not an option and I shouldn't be forced to use someone else's built tool preferences just because they have the luxury of updating on a whim or purely for bragging rights. It does not matter if my OS is dated, security patches are applied to the build tools as they become available and this seems to satisfy all other software that build from source except ClamAV. Having everything build with GCC 4.0 would allow me/us to re-deploy ClamAV and contribute to the code base again (I have in the past) but the chances of this are slim to non from what I recall because my OS and build tools are dated and listening to rants about ancient and deprecated is nothing more than someone spewing stupidity. The fact that I ensure all bugs and updates to the build tools are fixed/added allows me to keep everything in harmony and there is no reason to update anything to build a single software package when all other software sources seem to be content with the existing build environment. If you wish to go off-list to continue the discussion I have no objections. -- Dale On Mar 20, 2014, at 16:35 PM, Joel Esler (jesler) wrote: Dale, Thanks for your email. I'm not sure exactly what you are referring to. Maybe I am missing a connection here or something, but the discussion was around scanning DMG and XAR, which I think, if there's a issue with, we'd be more than happy to work with anyone to try and square away. You seem to be discussing a build issue, and you say that it's a waste of time. When did you get the impression that working with the developers was a waste of time? If we're not communicating well enough, we can fix that. But I think the team is doing a good job of that judging by the amount of complaints I have received since we took over the project from the old ClamAV team. Please let me know if we need to take this offline and discuss or anything I can do to help. -- Joel Esler Open Source Manager Threat Intelligence Team Lead Vulnerability Research Team On Mar 20, 2014, at 3:55 PM, Dale Walsh d...@daleenterprise.com mailto:d...@daleenterprise.com wrote: Mark, this has been an issue for many versions along with a slew of others things not working as expected. As much as I liked ClamAV, we've abandoned it as a mail solution shortly after things stopped working correctly and they changed the required build tools so you can no longer build it with GCC 3.3/4.0/4.1/4.2 and have a fully functional app. Yes there are flags to get it to build but certain modules and features don't build and making an incomplete and partially functional binary isn't appealing. Advice on updating build tools is
Re: [Clamav-devel] enabling DMG and XAR support
Then I am sure the developers would be glad to help figure out the problem and fix it. -- Joel Esler Sent from my iPhone On Mar 22, 2014, at 13:32, Dale Walsh d...@daleenterprise.com wrote: 0.98.1 DMG does not work. -- Dale On Mar 21, 2014, at 09:16 AM, Joel Esler (jesler) wrote: DMG support was just added in the last version of ClamAV. How long ago did you do this testing? On Mar 20, 2014, at 8:22 PM, Dale Walsh d...@daleenterprise.com wrote: You did miss it but it's a two headed nail. PDF, DMG, XAR and RAR have had issues not recognizing the test viruses to name just a couple that spring to mind that we've had trouble with and this all started happening when the clang and crap entered the picture. I've worked with the developers in the past, once the build environment dependancies changed and I was told I had to upgrade my OS and build tools is when it was no longer possible to resolve these issues as the update solely for the purpose of building ClamAV is not an option and I shouldn't be forced to use someone else's built tool preferences just because they have the luxury of updating on a whim or purely for bragging rights. It does not matter if my OS is dated, security patches are applied to the build tools as they become available and this seems to satisfy all other software that build from source except ClamAV. Having everything build with GCC 4.0 would allow me/us to re-deploy ClamAV and contribute to the code base again (I have in the past) but the chances of this are slim to non from what I recall because my OS and build tools are dated and listening to rants about ancient and deprecated is nothing more than someone spewing stupidity. The fact that I ensure all bugs and updates to the build tools are fixed/added allows me to keep everything in harmony and there is no reason to update anything to build a single software package when all other software sources seem to be content with the existing build environment. If you wish to go off-list to continue the discussion I have no objections. -- Dale On Mar 20, 2014, at 16:35 PM, Joel Esler (jesler) wrote: Dale, Thanks for your email. I’m not sure exactly what you are referring to. Maybe I am missing a connection here or something, but the discussion was around scanning DMG and XAR, which I think, if there’s a issue with, we’d be more than happy to work with anyone to try and square away. You seem to be discussing a build issue, and you say that it’s a waste of time. When did you get the impression that working with the developers was a waste of time? If we’re not communicating well enough, we can fix that. But I think the team is doing a good job of that judging by the amount of complaints I have received since we took over the project from the old ClamAV team. Please let me know if we need to take this offline and discuss or anything I can do to help. -- Joel Esler Open Source Manager Threat Intelligence Team Lead Vulnerability Research Team On Mar 20, 2014, at 3:55 PM, Dale Walsh d...@daleenterprise.commailto:d...@daleenterprise.com wrote: Mark, this has been an issue for many versions along with a slew of others things not working as expected. As much as I liked ClamAV, we've abandoned it as a mail solution shortly after things stopped working correctly and they changed the required build tools so you can no longer build it with GCC 3.3/4.0/4.1/4.2 and have a fully functional app. Yes there are flags to get it to build but certain modules and features don't build and making an incomplete and partially functional binary isn't appealing. Advice on updating build tools is a waste of time as there is no reason to update the build tools just to build ClamAV as it's the only one that has this ridiculous built-tool requirement and only an idiot would tell me to update. My thoughts on this is simple, if it doesn't build with the basic GNU GCC compiler tools then it's seriously flawed and needs these other tools to overcome the short-comings of poorly written/implemented code. When I say build, I mean build with full functionality so don't go off the deep-end stating it builds, partial functionality may be acceptable to you bhut it isn't to me. At this time, for personal use, I use the source code but repackage the build environment to work with what I have and I'm comfortable with submitting corrections and patches, too much focus and complaints on my build tools so why waste my time. -- Dale On Mar 19, 2014, at 11:34 AM, Rafael Ferreira wrote: Interesting... let me run some tests and get back to you. On Mar 19, 2014, at 8:33 AM, Mark Allan markjal...@gmail.commailto:markjal...@gmail.com wrote: Just out of interest, did you test to see if it *actually* worked? My configure output shows that dmg and xar are supported, but it doesn't actually
Re: [Clamav-devel] enabling DMG and XAR support
0.98.1 DMG does not work. -- Dale On Mar 21, 2014, at 09:16 AM, Joel Esler (jesler) wrote: DMG support was just added in the last version of ClamAV. How long ago did you do this testing? On Mar 20, 2014, at 8:22 PM, Dale Walsh d...@daleenterprise.com wrote: You did miss it but it's a two headed nail. PDF, DMG, XAR and RAR have had issues not recognizing the test viruses to name just a couple that spring to mind that we've had trouble with and this all started happening when the clang and crap entered the picture. I've worked with the developers in the past, once the build environment dependancies changed and I was told I had to upgrade my OS and build tools is when it was no longer possible to resolve these issues as the update solely for the purpose of building ClamAV is not an option and I shouldn't be forced to use someone else's built tool preferences just because they have the luxury of updating on a whim or purely for bragging rights. It does not matter if my OS is dated, security patches are applied to the build tools as they become available and this seems to satisfy all other software that build from source except ClamAV. Having everything build with GCC 4.0 would allow me/us to re- deploy ClamAV and contribute to the code base again (I have in the past) but the chances of this are slim to non from what I recall because my OS and build tools are dated and listening to rants about ancient and deprecated is nothing more than someone spewing stupidity. The fact that I ensure all bugs and updates to the build tools are fixed/added allows me to keep everything in harmony and there is no reason to update anything to build a single software package when all other software sources seem to be content with the existing build environment. If you wish to go off-list to continue the discussion I have no objections. -- Dale On Mar 20, 2014, at 16:35 PM, Joel Esler (jesler) wrote: Dale, Thanks for your email. I’m not sure exactly what you are referring to. Maybe I am missing a connection here or something, but the discussion was around scanning DMG and XAR, which I think, if there’s a issue with, we’d be more than happy to work with anyone to try and square away. You seem to be discussing a build issue, and you say that it’s a waste of time. When did you get the impression that working with the developers was a waste of time? If we’re not communicating well enough, we can fix that. But I think the team is doing a good job of that judging by the amount of complaints I have received since we took over the project from the old ClamAV team. Please let me know if we need to take this offline and discuss or anything I can do to help. -- Joel Esler Open Source Manager Threat Intelligence Team Lead Vulnerability Research Team On Mar 20, 2014, at 3:55 PM, Dale Walsh d...@daleenterprise.commailto:d...@daleenterprise.com wrote: Mark, this has been an issue for many versions along with a slew of others things not working as expected. As much as I liked ClamAV, we've abandoned it as a mail solution shortly after things stopped working correctly and they changed the required build tools so you can no longer build it with GCC 3.3/4.0/4.1/4.2 and have a fully functional app. Yes there are flags to get it to build but certain modules and features don't build and making an incomplete and partially functional binary isn't appealing. Advice on updating build tools is a waste of time as there is no reason to update the build tools just to build ClamAV as it's the only one that has this ridiculous built-tool requirement and only an idiot would tell me to update. My thoughts on this is simple, if it doesn't build with the basic GNU GCC compiler tools then it's seriously flawed and needs these other tools to overcome the short-comings of poorly written/ implemented code. When I say build, I mean build with full functionality so don't go off the deep-end stating it builds, partial functionality may be acceptable to you bhut it isn't to me. At this time, for personal use, I use the source code but repackage the build environment to work with what I have and I'm comfortable with submitting corrections and patches, too much focus and complaints on my build tools so why waste my time. -- Dale On Mar 19, 2014, at 11:34 AM, Rafael Ferreira wrote: Interesting... let me run some tests and get back to you. On Mar 19, 2014, at 8:33 AM, Mark Allan markjal...@gmail.commailto:markjal...@gmail.com wrote: Just out of interest, did you test to see if it *actually* worked? My configure output shows that dmg and xar are supported, but it doesn't actually detect the Eicar test file within a disk image. configure: Summary of engine detection features autoit_ea06 : yes bzip2 : ok zlib: /usr unrar : yes dmg and
Re: [Clamav-devel] enabling DMG and XAR support
DMG support was just added in the last version of ClamAV. How long ago did you do this testing? On Mar 20, 2014, at 8:22 PM, Dale Walsh d...@daleenterprise.com wrote: You did miss it but it's a two headed nail. PDF, DMG, XAR and RAR have had issues not recognizing the test viruses to name just a couple that spring to mind that we've had trouble with and this all started happening when the clang and crap entered the picture. I've worked with the developers in the past, once the build environment dependancies changed and I was told I had to upgrade my OS and build tools is when it was no longer possible to resolve these issues as the update solely for the purpose of building ClamAV is not an option and I shouldn't be forced to use someone else's built tool preferences just because they have the luxury of updating on a whim or purely for bragging rights. It does not matter if my OS is dated, security patches are applied to the build tools as they become available and this seems to satisfy all other software that build from source except ClamAV. Having everything build with GCC 4.0 would allow me/us to re-deploy ClamAV and contribute to the code base again (I have in the past) but the chances of this are slim to non from what I recall because my OS and build tools are dated and listening to rants about ancient and deprecated is nothing more than someone spewing stupidity. The fact that I ensure all bugs and updates to the build tools are fixed/added allows me to keep everything in harmony and there is no reason to update anything to build a single software package when all other software sources seem to be content with the existing build environment. If you wish to go off-list to continue the discussion I have no objections. -- Dale On Mar 20, 2014, at 16:35 PM, Joel Esler (jesler) wrote: Dale, Thanks for your email. I’m not sure exactly what you are referring to. Maybe I am missing a connection here or something, but the discussion was around scanning DMG and XAR, which I think, if there’s a issue with, we’d be more than happy to work with anyone to try and square away. You seem to be discussing a build issue, and you say that it’s a waste of time. When did you get the impression that working with the developers was a waste of time? If we’re not communicating well enough, we can fix that. But I think the team is doing a good job of that judging by the amount of complaints I have received since we took over the project from the old ClamAV team. Please let me know if we need to take this offline and discuss or anything I can do to help. -- Joel Esler Open Source Manager Threat Intelligence Team Lead Vulnerability Research Team On Mar 20, 2014, at 3:55 PM, Dale Walsh d...@daleenterprise.commailto:d...@daleenterprise.com wrote: Mark, this has been an issue for many versions along with a slew of others things not working as expected. As much as I liked ClamAV, we've abandoned it as a mail solution shortly after things stopped working correctly and they changed the required build tools so you can no longer build it with GCC 3.3/4.0/4.1/4.2 and have a fully functional app. Yes there are flags to get it to build but certain modules and features don't build and making an incomplete and partially functional binary isn't appealing. Advice on updating build tools is a waste of time as there is no reason to update the build tools just to build ClamAV as it's the only one that has this ridiculous built-tool requirement and only an idiot would tell me to update. My thoughts on this is simple, if it doesn't build with the basic GNU GCC compiler tools then it's seriously flawed and needs these other tools to overcome the short-comings of poorly written/implemented code. When I say build, I mean build with full functionality so don't go off the deep-end stating it builds, partial functionality may be acceptable to you bhut it isn't to me. At this time, for personal use, I use the source code but repackage the build environment to work with what I have and I'm comfortable with submitting corrections and patches, too much focus and complaints on my build tools so why waste my time. -- Dale On Mar 19, 2014, at 11:34 AM, Rafael Ferreira wrote: Interesting... let me run some tests and get back to you. On Mar 19, 2014, at 8:33 AM, Mark Allan markjal...@gmail.commailto:markjal...@gmail.com wrote: Just out of interest, did you test to see if it *actually* worked? My configure output shows that dmg and xar are supported, but it doesn't actually detect the Eicar test file within a disk image. configure: Summary of engine detection features autoit_ea06 : yes bzip2 : ok zlib: /usr unrar : yes dmg and xar : yes, from /usr When I create a new disk image, copy the Eicar
Re: [Clamav-devel] enabling DMG and XAR support
Sorry, I'm not sure if you're talking to me or Dale. If you're talking to me, my testing was done two days ago using ClamAV 0.98.1 Mark On 21 Mar 2014, at 13:16, Joel Esler (jesler) jes...@cisco.com wrote: DMG support was just added in the last version of ClamAV. How long ago did you do this testing? On Mar 20, 2014, at 8:22 PM, Dale Walsh d...@daleenterprise.com wrote: You did miss it but it's a two headed nail. PDF, DMG, XAR and RAR have had issues not recognizing the test viruses to name just a couple that spring to mind that we've had trouble with and this all started happening when the clang and crap entered the picture. I've worked with the developers in the past, once the build environment dependancies changed and I was told I had to upgrade my OS and build tools is when it was no longer possible to resolve these issues as the update solely for the purpose of building ClamAV is not an option and I shouldn't be forced to use someone else's built tool preferences just because they have the luxury of updating on a whim or purely for bragging rights. It does not matter if my OS is dated, security patches are applied to the build tools as they become available and this seems to satisfy all other software that build from source except ClamAV. Having everything build with GCC 4.0 would allow me/us to re-deploy ClamAV and contribute to the code base again (I have in the past) but the chances of this are slim to non from what I recall because my OS and build tools are dated and listening to rants about ancient and deprecated is nothing more than someone spewing stupidity. The fact that I ensure all bugs and updates to the build tools are fixed/added allows me to keep everything in harmony and there is no reason to update anything to build a single software package when all other software sources seem to be content with the existing build environment. If you wish to go off-list to continue the discussion I have no objections. -- Dale On Mar 20, 2014, at 16:35 PM, Joel Esler (jesler) wrote: Dale, Thanks for your email. I’m not sure exactly what you are referring to. Maybe I am missing a connection here or something, but the discussion was around scanning DMG and XAR, which I think, if there’s a issue with, we’d be more than happy to work with anyone to try and square away. You seem to be discussing a build issue, and you say that it’s a waste of time. When did you get the impression that working with the developers was a waste of time? If we’re not communicating well enough, we can fix that. But I think the team is doing a good job of that judging by the amount of complaints I have received since we took over the project from the old ClamAV team. Please let me know if we need to take this offline and discuss or anything I can do to help. -- Joel Esler Open Source Manager Threat Intelligence Team Lead Vulnerability Research Team On Mar 20, 2014, at 3:55 PM, Dale Walsh d...@daleenterprise.commailto:d...@daleenterprise.com wrote: Mark, this has been an issue for many versions along with a slew of others things not working as expected. As much as I liked ClamAV, we've abandoned it as a mail solution shortly after things stopped working correctly and they changed the required build tools so you can no longer build it with GCC 3.3/4.0/4.1/4.2 and have a fully functional app. Yes there are flags to get it to build but certain modules and features don't build and making an incomplete and partially functional binary isn't appealing. Advice on updating build tools is a waste of time as there is no reason to update the build tools just to build ClamAV as it's the only one that has this ridiculous built-tool requirement and only an idiot would tell me to update. My thoughts on this is simple, if it doesn't build with the basic GNU GCC compiler tools then it's seriously flawed and needs these other tools to overcome the short-comings of poorly written/implemented code. When I say build, I mean build with full functionality so don't go off the deep-end stating it builds, partial functionality may be acceptable to you bhut it isn't to me. At this time, for personal use, I use the source code but repackage the build environment to work with what I have and I'm comfortable with submitting corrections and patches, too much focus and complaints on my build tools so why waste my time. -- Dale On Mar 19, 2014, at 11:34 AM, Rafael Ferreira wrote: Interesting... let me run some tests and get back to you. On Mar 19, 2014, at 8:33 AM, Mark Allan markjal...@gmail.commailto:markjal...@gmail.com wrote: Just out of interest, did you test to see if it *actually* worked? My configure output shows that dmg and xar are supported, but it doesn't actually detect the Eicar test file within a disk image. configure: Summary of engine detection
Re: [Clamav-devel] enabling DMG and XAR support
Sorry Mark, I’ll actually take my discussion with Dale offline so we don’t pollute the thread. I think Steve Morgan is working with you on the issue you started this thread with. Sounds like my discussion with Dale is a separate issue. On Mar 21, 2014, at 10:00 AM, Mark Allan markjal...@gmail.com wrote: Sorry, I'm not sure if you're talking to me or Dale. If you're talking to me, my testing was done two days ago using ClamAV 0.98.1 Mark On 21 Mar 2014, at 13:16, Joel Esler (jesler) jes...@cisco.com wrote: DMG support was just added in the last version of ClamAV. How long ago did you do this testing? On Mar 20, 2014, at 8:22 PM, Dale Walsh d...@daleenterprise.com wrote: You did miss it but it's a two headed nail. PDF, DMG, XAR and RAR have had issues not recognizing the test viruses to name just a couple that spring to mind that we've had trouble with and this all started happening when the clang and crap entered the picture. I've worked with the developers in the past, once the build environment dependancies changed and I was told I had to upgrade my OS and build tools is when it was no longer possible to resolve these issues as the update solely for the purpose of building ClamAV is not an option and I shouldn't be forced to use someone else's built tool preferences just because they have the luxury of updating on a whim or purely for bragging rights. It does not matter if my OS is dated, security patches are applied to the build tools as they become available and this seems to satisfy all other software that build from source except ClamAV. Having everything build with GCC 4.0 would allow me/us to re-deploy ClamAV and contribute to the code base again (I have in the past) but the chances of this are slim to non from what I recall because my OS and build tools are dated and listening to rants about ancient and deprecated is nothing more than someone spewing stupidity. The fact that I ensure all bugs and updates to the build tools are fixed/added allows me to keep everything in harmony and there is no reason to update anything to build a single software package when all other software sources seem to be content with the existing build environment. If you wish to go off-list to continue the discussion I have no objections. -- Dale On Mar 20, 2014, at 16:35 PM, Joel Esler (jesler) wrote: Dale, Thanks for your email. I’m not sure exactly what you are referring to. Maybe I am missing a connection here or something, but the discussion was around scanning DMG and XAR, which I think, if there’s a issue with, we’d be more than happy to work with anyone to try and square away. You seem to be discussing a build issue, and you say that it’s a waste of time. When did you get the impression that working with the developers was a waste of time? If we’re not communicating well enough, we can fix that. But I think the team is doing a good job of that judging by the amount of complaints I have received since we took over the project from the old ClamAV team. Please let me know if we need to take this offline and discuss or anything I can do to help. -- Joel Esler Open Source Manager Threat Intelligence Team Lead Vulnerability Research Team On Mar 20, 2014, at 3:55 PM, Dale Walsh d...@daleenterprise.commailto:d...@daleenterprise.com wrote: Mark, this has been an issue for many versions along with a slew of others things not working as expected. As much as I liked ClamAV, we've abandoned it as a mail solution shortly after things stopped working correctly and they changed the required build tools so you can no longer build it with GCC 3.3/4.0/4.1/4.2 and have a fully functional app. Yes there are flags to get it to build but certain modules and features don't build and making an incomplete and partially functional binary isn't appealing. Advice on updating build tools is a waste of time as there is no reason to update the build tools just to build ClamAV as it's the only one that has this ridiculous built-tool requirement and only an idiot would tell me to update. My thoughts on this is simple, if it doesn't build with the basic GNU GCC compiler tools then it's seriously flawed and needs these other tools to overcome the short-comings of poorly written/implemented code. When I say build, I mean build with full functionality so don't go off the deep-end stating it builds, partial functionality may be acceptable to you bhut it isn't to me. At this time, for personal use, I use the source code but repackage the build environment to work with what I have and I'm comfortable with submitting corrections and patches, too much focus and complaints on my build tools so why waste my time. -- Dale On Mar 19, 2014, at 11:34 AM, Rafael Ferreira wrote: Interesting... let me run some tests and get back to you. On Mar 19, 2014, at
Re: [Clamav-devel] enabling DMG and XAR support
Mark, this has been an issue for many versions along with a slew of others things not working as expected. As much as I liked ClamAV, we've abandoned it as a mail solution shortly after things stopped working correctly and they changed the required build tools so you can no longer build it with GCC 3.3/4.0/4.1/4.2 and have a fully functional app. Yes there are flags to get it to build but certain modules and features don't build and making an incomplete and partially functional binary isn't appealing. Advice on updating build tools is a waste of time as there is no reason to update the build tools just to build ClamAV as it's the only one that has this ridiculous built-tool requirement and only an idiot would tell me to update. My thoughts on this is simple, if it doesn't build with the basic GNU GCC compiler tools then it's seriously flawed and needs these other tools to overcome the short-comings of poorly written/implemented code. When I say build, I mean build with full functionality so don't go off the deep-end stating it builds, partial functionality may be acceptable to you bhut it isn't to me. At this time, for personal use, I use the source code but repackage the build environment to work with what I have and I'm comfortable with submitting corrections and patches, too much focus and complaints on my build tools so why waste my time. -- Dale On Mar 19, 2014, at 11:34 AM, Rafael Ferreira wrote: Interesting... let me run some tests and get back to you. On Mar 19, 2014, at 8:33 AM, Mark Allan markjal...@gmail.com wrote: Just out of interest, did you test to see if it *actually* worked? My configure output shows that dmg and xar are supported, but it doesn't actually detect the Eicar test file within a disk image. configure: Summary of engine detection features autoit_ea06 : yes bzip2 : ok zlib: /usr unrar : yes dmg and xar : yes, from /usr When I create a new disk image, copy the Eicar test file in, and scan the dmg, it shows up as being clean. clamscan test.dmg test.dmg: OK --- SCAN SUMMARY --- Known viruses: 3259558 Engine version: 0.98.1 Scanned directories: 0 Scanned files: 1 Infected files: 0 Data scanned: 10.07 MB Data read: 10.02 MB (ratio 1.01:1) Time: 4.845 sec (0 m 4 s) Does this work as expected for anyone else? Mark On 10 Feb 2014, at 23:38, Rafael Ferreira r...@uvasoftware.com wrote: That worked, thanks! On February 10, 2014 at 4:29:41 PM, Steven Morgan (smor...@sourcefire.com) wrote: Rafael, Probably all you need to do install libxmllibxml2-dev, which is used by dmg and xar, then do your configure/make. Steve On Mon, Feb 10, 2014 at 6:05 PM, Rafael Ferreira r...@uvasoftware.comwrote: Folks, I'm compiling clamav 0.98.1 on Linux (Ubuntu 12.04 LTS) and I'm not getting the new super awesome DMG and XAR file support: configure: Summary of detected features follows OS : linux-gnu pthreads : yes (-lpthread) configure: Summary of miscellaneous features check : no (auto) fanotify : yes fdpassing : 1 IPv6 : yes configure: Summary of optional tools clamdtop : (auto) milter : yes (disabled) configure: Summary of engine performance features) release mode: yes jit : yes (auto) mempool : yes configure: Summary of engine detection features autoit_ea06 : yes bzip2 : ok zlib : /usr unrar : yes dmg and xar : no Am I missing a configure flag or third party library? Thanks in advance, - Rafael scanii.com - the web friendly malware scanner! ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: [Clamav-devel] enabling DMG and XAR support
Dale, Thanks for your email. I’m not sure exactly what you are referring to. Maybe I am missing a connection here or something, but the discussion was around scanning DMG and XAR, which I think, if there’s a issue with, we’d be more than happy to work with anyone to try and square away. You seem to be discussing a build issue, and you say that it’s a waste of time. When did you get the impression that working with the developers was a waste of time? If we’re not communicating well enough, we can fix that. But I think the team is doing a good job of that judging by the amount of complaints I have received since we took over the project from the old ClamAV team. Please let me know if we need to take this offline and discuss or anything I can do to help. -- Joel Esler Open Source Manager Threat Intelligence Team Lead Vulnerability Research Team On Mar 20, 2014, at 3:55 PM, Dale Walsh d...@daleenterprise.commailto:d...@daleenterprise.com wrote: Mark, this has been an issue for many versions along with a slew of others things not working as expected. As much as I liked ClamAV, we've abandoned it as a mail solution shortly after things stopped working correctly and they changed the required build tools so you can no longer build it with GCC 3.3/4.0/4.1/4.2 and have a fully functional app. Yes there are flags to get it to build but certain modules and features don't build and making an incomplete and partially functional binary isn't appealing. Advice on updating build tools is a waste of time as there is no reason to update the build tools just to build ClamAV as it's the only one that has this ridiculous built-tool requirement and only an idiot would tell me to update. My thoughts on this is simple, if it doesn't build with the basic GNU GCC compiler tools then it's seriously flawed and needs these other tools to overcome the short-comings of poorly written/implemented code. When I say build, I mean build with full functionality so don't go off the deep-end stating it builds, partial functionality may be acceptable to you bhut it isn't to me. At this time, for personal use, I use the source code but repackage the build environment to work with what I have and I'm comfortable with submitting corrections and patches, too much focus and complaints on my build tools so why waste my time. -- Dale On Mar 19, 2014, at 11:34 AM, Rafael Ferreira wrote: Interesting... let me run some tests and get back to you. On Mar 19, 2014, at 8:33 AM, Mark Allan markjal...@gmail.commailto:markjal...@gmail.com wrote: Just out of interest, did you test to see if it *actually* worked? My configure output shows that dmg and xar are supported, but it doesn't actually detect the Eicar test file within a disk image. configure: Summary of engine detection features autoit_ea06 : yes bzip2 : ok zlib: /usr unrar : yes dmg and xar : yes, from /usr When I create a new disk image, copy the Eicar test file in, and scan the dmg, it shows up as being clean. clamscan test.dmg test.dmg: OK --- SCAN SUMMARY --- Known viruses: 3259558 Engine version: 0.98.1 Scanned directories: 0 Scanned files: 1 Infected files: 0 Data scanned: 10.07 MB Data read: 10.02 MB (ratio 1.01:1) Time: 4.845 sec (0 m 4 s) Does this work as expected for anyone else? Mark On 10 Feb 2014, at 23:38, Rafael Ferreira r...@uvasoftware.commailto:r...@uvasoftware.com wrote: That worked, thanks! On February 10, 2014 at 4:29:41 PM, Steven Morgan (smor...@sourcefire.commailto:smor...@sourcefire.com) wrote: Rafael, Probably all you need to do install libxmllibxml2-dev, which is used by dmg and xar, then do your configure/make. Steve On Mon, Feb 10, 2014 at 6:05 PM, Rafael Ferreira r...@uvasoftware.commailto:r...@uvasoftware.comwrote: Folks, I'm compiling clamav 0.98.1 on Linux (Ubuntu 12.04 LTS) and I'm not getting the new super awesome DMG and XAR file support: configure: Summary of detected features follows OS : linux-gnu pthreads : yes (-lpthread) configure: Summary of miscellaneous features check : no (auto) fanotify : yes fdpassing : 1 IPv6 : yes configure: Summary of optional tools clamdtop : (auto) milter : yes (disabled) configure: Summary of engine performance features) release mode: yes jit : yes (auto) mempool : yes configure: Summary of engine detection features autoit_ea06 : yes bzip2 : ok zlib : /usr unrar : yes dmg and xar : no Am I missing a configure flag or third party library? Thanks in advance, - Rafael scanii.comhttp://scanii.com - the web friendly malware scanner! ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: [Clamav-devel] enabling DMG and XAR support
You did miss it but it's a two headed nail. PDF, DMG, XAR and RAR have had issues not recognizing the test viruses to name just a couple that spring to mind that we've had trouble with and this all started happening when the clang and crap entered the picture. I've worked with the developers in the past, once the build environment dependancies changed and I was told I had to upgrade my OS and build tools is when it was no longer possible to resolve these issues as the update solely for the purpose of building ClamAV is not an option and I shouldn't be forced to use someone else's built tool preferences just because they have the luxury of updating on a whim or purely for bragging rights. It does not matter if my OS is dated, security patches are applied to the build tools as they become available and this seems to satisfy all other software that build from source except ClamAV. Having everything build with GCC 4.0 would allow me/us to re-deploy ClamAV and contribute to the code base again (I have in the past) but the chances of this are slim to non from what I recall because my OS and build tools are dated and listening to rants about ancient and deprecated is nothing more than someone spewing stupidity. The fact that I ensure all bugs and updates to the build tools are fixed/added allows me to keep everything in harmony and there is no reason to update anything to build a single software package when all other software sources seem to be content with the existing build environment. If you wish to go off-list to continue the discussion I have no objections. -- Dale On Mar 20, 2014, at 16:35 PM, Joel Esler (jesler) wrote: Dale, Thanks for your email. I’m not sure exactly what you are referring to. Maybe I am missing a connection here or something, but the discussion was around scanning DMG and XAR, which I think, if there’s a issue with, we’d be more than happy to work with anyone to try and square away. You seem to be discussing a build issue, and you say that it’s a waste of time. When did you get the impression that working with the developers was a waste of time? If we’re not communicating well enough, we can fix that. But I think the team is doing a good job of that judging by the amount of complaints I have received since we took over the project from the old ClamAV team. Please let me know if we need to take this offline and discuss or anything I can do to help. -- Joel Esler Open Source Manager Threat Intelligence Team Lead Vulnerability Research Team On Mar 20, 2014, at 3:55 PM, Dale Walsh d...@daleenterprise.commailto:d...@daleenterprise.com wrote: Mark, this has been an issue for many versions along with a slew of others things not working as expected. As much as I liked ClamAV, we've abandoned it as a mail solution shortly after things stopped working correctly and they changed the required build tools so you can no longer build it with GCC 3.3/4.0/4.1/4.2 and have a fully functional app. Yes there are flags to get it to build but certain modules and features don't build and making an incomplete and partially functional binary isn't appealing. Advice on updating build tools is a waste of time as there is no reason to update the build tools just to build ClamAV as it's the only one that has this ridiculous built-tool requirement and only an idiot would tell me to update. My thoughts on this is simple, if it doesn't build with the basic GNU GCC compiler tools then it's seriously flawed and needs these other tools to overcome the short-comings of poorly written/ implemented code. When I say build, I mean build with full functionality so don't go off the deep-end stating it builds, partial functionality may be acceptable to you bhut it isn't to me. At this time, for personal use, I use the source code but repackage the build environment to work with what I have and I'm comfortable with submitting corrections and patches, too much focus and complaints on my build tools so why waste my time. -- Dale On Mar 19, 2014, at 11:34 AM, Rafael Ferreira wrote: Interesting... let me run some tests and get back to you. On Mar 19, 2014, at 8:33 AM, Mark Allan markjal...@gmail.commailto:markjal...@gmail.com wrote: Just out of interest, did you test to see if it *actually* worked? My configure output shows that dmg and xar are supported, but it doesn't actually detect the Eicar test file within a disk image. configure: Summary of engine detection features autoit_ea06 : yes bzip2 : ok zlib: /usr unrar : yes dmg and xar : yes, from /usr When I create a new disk image, copy the Eicar test file in, and scan the dmg, it shows up as being clean. clamscan test.dmg test.dmg: OK --- SCAN SUMMARY --- Known viruses: 3259558 Engine version: 0.98.1 Scanned directories: 0
Re: [Clamav-devel] enabling DMG and XAR support
Just out of interest, did you test to see if it *actually* worked? My configure output shows that dmg and xar are supported, but it doesn't actually detect the Eicar test file within a disk image. configure: Summary of engine detection features autoit_ea06 : yes bzip2 : ok zlib: /usr unrar : yes dmg and xar : yes, from /usr When I create a new disk image, copy the Eicar test file in, and scan the dmg, it shows up as being clean. clamscan test.dmg test.dmg: OK --- SCAN SUMMARY --- Known viruses: 3259558 Engine version: 0.98.1 Scanned directories: 0 Scanned files: 1 Infected files: 0 Data scanned: 10.07 MB Data read: 10.02 MB (ratio 1.01:1) Time: 4.845 sec (0 m 4 s) Does this work as expected for anyone else? Mark On 10 Feb 2014, at 23:38, Rafael Ferreira r...@uvasoftware.com wrote: That worked, thanks! On February 10, 2014 at 4:29:41 PM, Steven Morgan (smor...@sourcefire.com) wrote: Rafael, Probably all you need to do install libxmllibxml2-dev, which is used by dmg and xar, then do your configure/make. Steve On Mon, Feb 10, 2014 at 6:05 PM, Rafael Ferreira r...@uvasoftware.comwrote: Folks, I'm compiling clamav 0.98.1 on Linux (Ubuntu 12.04 LTS) and I'm not getting the new super awesome DMG and XAR file support: configure: Summary of detected features follows OS : linux-gnu pthreads : yes (-lpthread) configure: Summary of miscellaneous features check : no (auto) fanotify : yes fdpassing : 1 IPv6 : yes configure: Summary of optional tools clamdtop : (auto) milter : yes (disabled) configure: Summary of engine performance features) release mode: yes jit : yes (auto) mempool : yes configure: Summary of engine detection features autoit_ea06 : yes bzip2 : ok zlib : /usr unrar : yes dmg and xar : no Am I missing a configure flag or third party library? Thanks in advance, - Rafael scanii.com - the web friendly malware scanner! ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: [Clamav-devel] enabling DMG and XAR support
My test disk is indeed a raw image. I've also tried read only as well as compressed, and nothing gets detected in any of those. As you say, Disk Utility creates raw images by default, and while some software packagers do create UDIF formatted images, I suspect Disk Utility is the most common way of making disk images on OS X. What would be required to provide full DMG support? Also, is there a similar caveat for xar archives? I've done a similar test for those and they slip by undetected as well. xar -c -f new.xar DirWithManyKnownDetectedMalwareSamples clamscan new.xar new.xar: OK --- SCAN SUMMARY --- Known viruses: 3259558 Engine version: 0.98.1 Scanned directories: 0 Scanned files: 1 Infected files: 0 Data scanned: 0.00 MB Data read: 31.34 MB (ratio 0.00:1) Time: 4.612 sec (0 m 4 s) Mark On 19 Mar 2014, at 15:43, David Raynor dray...@sourcefire.com wrote: DMG is an odd filetype, since there are really 2 or 3 different filetypes lumped into that category. What we have included in ClamAV 0.98.1 is scanning of UDIF format DMG files, which have a definitive trailer block and may have compressed sections. We have not yet included support for scanning raw disk format DMG files, which are nearly indistinguishable from disk dumps. No separate compression is allowed. So let me ask you this question. How did you create your DMG? Most software packagers create UDIF format to reduce the file size for downloads. Disk Utility and the hdiutil command can create a raw disk unless another format is checked. To find out what format your testfile is really in, you can use the imageinfo sub-command of hdiutil (e.g. hdiutil imageinfo yourfile.dmg). Then you can use the convert sub-command of hdiutil to switch the format. Hope this helps, Dave R. -- --- Dave Raynor Vulnerability Research Team ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net On Wed, Mar 19, 2014 at 11:34 AM, Rafael Ferreira r...@uvasoftware.comwrote: Interesting... let me run some tests and get back to you. On Mar 19, 2014, at 8:33 AM, Mark Allan markjal...@gmail.com wrote: Just out of interest, did you test to see if it *actually* worked? My configure output shows that dmg and xar are supported, but it doesn't actually detect the Eicar test file within a disk image. configure: Summary of engine detection features autoit_ea06 : yes bzip2 : ok zlib: /usr unrar : yes dmg and xar : yes, from /usr When I create a new disk image, copy the Eicar test file in, and scan the dmg, it shows up as being clean. clamscan test.dmg test.dmg: OK --- SCAN SUMMARY --- Known viruses: 3259558 Engine version: 0.98.1 Scanned directories: 0 Scanned files: 1 Infected files: 0 Data scanned: 10.07 MB Data read: 10.02 MB (ratio 1.01:1) Time: 4.845 sec (0 m 4 s) Does this work as expected for anyone else? Mark On 10 Feb 2014, at 23:38, Rafael Ferreira r...@uvasoftware.com wrote: That worked, thanks! On February 10, 2014 at 4:29:41 PM, Steven Morgan ( smor...@sourcefire.com) wrote: Rafael, Probably all you need to do install libxmllibxml2-dev, which is used by dmg and xar, then do your configure/make. Steve On Mon, Feb 10, 2014 at 6:05 PM, Rafael Ferreira r...@uvasoftware.com wrote: Folks, I'm compiling clamav 0.98.1 on Linux (Ubuntu 12.04 LTS) and I'm not getting the new super awesome DMG and XAR file support: configure: Summary of detected features follows OS : linux-gnu pthreads : yes (-lpthread) configure: Summary of miscellaneous features check : no (auto) fanotify : yes fdpassing : 1 IPv6 : yes configure: Summary of optional tools clamdtop : (auto) milter : yes (disabled) configure: Summary of engine performance features) release mode: yes jit : yes (auto) mempool : yes configure: Summary of engine detection features autoit_ea06 : yes bzip2 : ok zlib : /usr unrar : yes dmg and xar : no Am I missing a configure flag or third party library? Thanks in advance, - Rafael scanii.com - the web friendly malware scanner! ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: [Clamav-devel] enabling DMG and XAR support
Interesting... let me run some tests and get back to you. On Mar 19, 2014, at 8:33 AM, Mark Allan markjal...@gmail.com wrote: Just out of interest, did you test to see if it *actually* worked? My configure output shows that dmg and xar are supported, but it doesn't actually detect the Eicar test file within a disk image. configure: Summary of engine detection features autoit_ea06 : yes bzip2 : ok zlib: /usr unrar : yes dmg and xar : yes, from /usr When I create a new disk image, copy the Eicar test file in, and scan the dmg, it shows up as being clean. clamscan test.dmg test.dmg: OK --- SCAN SUMMARY --- Known viruses: 3259558 Engine version: 0.98.1 Scanned directories: 0 Scanned files: 1 Infected files: 0 Data scanned: 10.07 MB Data read: 10.02 MB (ratio 1.01:1) Time: 4.845 sec (0 m 4 s) Does this work as expected for anyone else? Mark On 10 Feb 2014, at 23:38, Rafael Ferreira r...@uvasoftware.com wrote: That worked, thanks! On February 10, 2014 at 4:29:41 PM, Steven Morgan (smor...@sourcefire.com) wrote: Rafael, Probably all you need to do install libxmllibxml2-dev, which is used by dmg and xar, then do your configure/make. Steve On Mon, Feb 10, 2014 at 6:05 PM, Rafael Ferreira r...@uvasoftware.comwrote: Folks, I'm compiling clamav 0.98.1 on Linux (Ubuntu 12.04 LTS) and I'm not getting the new super awesome DMG and XAR file support: configure: Summary of detected features follows OS : linux-gnu pthreads : yes (-lpthread) configure: Summary of miscellaneous features check : no (auto) fanotify : yes fdpassing : 1 IPv6 : yes configure: Summary of optional tools clamdtop : (auto) milter : yes (disabled) configure: Summary of engine performance features) release mode: yes jit : yes (auto) mempool : yes configure: Summary of engine detection features autoit_ea06 : yes bzip2 : ok zlib : /usr unrar : yes dmg and xar : no Am I missing a configure flag or third party library? Thanks in advance, - Rafael scanii.com - the web friendly malware scanner! ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: [Clamav-devel] enabling DMG and XAR support
Mark, Your xar scenario should be working. You can get more info with --debug. If you want to forward that output and/or test file, we can investigate further. Steve On Wed, Mar 19, 2014 at 11:59 AM, Mark Allan markjal...@gmail.com wrote: My test disk is indeed a raw image. I've also tried read only as well as compressed, and nothing gets detected in any of those. As you say, Disk Utility creates raw images by default, and while some software packagers do create UDIF formatted images, I suspect Disk Utility is the most common way of making disk images on OS X. What would be required to provide full DMG support? Also, is there a similar caveat for xar archives? I've done a similar test for those and they slip by undetected as well. xar -c -f new.xar DirWithManyKnownDetectedMalwareSamples clamscan new.xar new.xar: OK --- SCAN SUMMARY --- Known viruses: 3259558 Engine version: 0.98.1 Scanned directories: 0 Scanned files: 1 Infected files: 0 Data scanned: 0.00 MB Data read: 31.34 MB (ratio 0.00:1) Time: 4.612 sec (0 m 4 s) Mark On 19 Mar 2014, at 15:43, David Raynor dray...@sourcefire.com wrote: DMG is an odd filetype, since there are really 2 or 3 different filetypes lumped into that category. What we have included in ClamAV 0.98.1 is scanning of UDIF format DMG files, which have a definitive trailer block and may have compressed sections. We have not yet included support for scanning raw disk format DMG files, which are nearly indistinguishable from disk dumps. No separate compression is allowed. So let me ask you this question. How did you create your DMG? Most software packagers create UDIF format to reduce the file size for downloads. Disk Utility and the hdiutil command can create a raw disk unless another format is checked. To find out what format your testfile is really in, you can use the imageinfo sub-command of hdiutil (e.g. hdiutil imageinfo yourfile.dmg). Then you can use the convert sub-command of hdiutil to switch the format. Hope this helps, Dave R. -- --- Dave Raynor Vulnerability Research Team ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net On Wed, Mar 19, 2014 at 11:34 AM, Rafael Ferreira r...@uvasoftware.com wrote: Interesting... let me run some tests and get back to you. On Mar 19, 2014, at 8:33 AM, Mark Allan markjal...@gmail.com wrote: Just out of interest, did you test to see if it *actually* worked? My configure output shows that dmg and xar are supported, but it doesn't actually detect the Eicar test file within a disk image. configure: Summary of engine detection features autoit_ea06 : yes bzip2 : ok zlib: /usr unrar : yes dmg and xar : yes, from /usr When I create a new disk image, copy the Eicar test file in, and scan the dmg, it shows up as being clean. clamscan test.dmg test.dmg: OK --- SCAN SUMMARY --- Known viruses: 3259558 Engine version: 0.98.1 Scanned directories: 0 Scanned files: 1 Infected files: 0 Data scanned: 10.07 MB Data read: 10.02 MB (ratio 1.01:1) Time: 4.845 sec (0 m 4 s) Does this work as expected for anyone else? Mark On 10 Feb 2014, at 23:38, Rafael Ferreira r...@uvasoftware.com wrote: That worked, thanks! On February 10, 2014 at 4:29:41 PM, Steven Morgan ( smor...@sourcefire.com) wrote: Rafael, Probably all you need to do install libxmllibxml2-dev, which is used by dmg and xar, then do your configure/make. Steve On Mon, Feb 10, 2014 at 6:05 PM, Rafael Ferreira r...@uvasoftware.com wrote: Folks, I'm compiling clamav 0.98.1 on Linux (Ubuntu 12.04 LTS) and I'm not getting the new super awesome DMG and XAR file support: configure: Summary of detected features follows OS : linux-gnu pthreads : yes (-lpthread) configure: Summary of miscellaneous features check : no (auto) fanotify : yes fdpassing : 1 IPv6 : yes configure: Summary of optional tools clamdtop : (auto) milter : yes (disabled) configure: Summary of engine performance features) release mode: yes jit : yes (auto) mempool : yes configure: Summary of engine detection features autoit_ea06 : yes bzip2 : ok zlib : /usr unrar : yes dmg and xar : no Am I missing a configure flag or third party library? Thanks in advance, - Rafael scanii.com - the web friendly malware scanner! ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla:
Re: [Clamav-devel] enabling DMG and XAR support
Rafael, Probably all you need to do install libxmllibxml2-dev, which is used by dmg and xar, then do your configure/make. Steve On Mon, Feb 10, 2014 at 6:05 PM, Rafael Ferreira r...@uvasoftware.comwrote: Folks, I'm compiling clamav 0.98.1 on Linux (Ubuntu 12.04 LTS) and I'm not getting the new super awesome DMG and XAR file support: configure: Summary of detected features follows OS : linux-gnu pthreads: yes (-lpthread) configure: Summary of miscellaneous features check : no (auto) fanotify: yes fdpassing : 1 IPv6: yes configure: Summary of optional tools clamdtop: (auto) milter : yes (disabled) configure: Summary of engine performance features) release mode: yes jit : yes (auto) mempool : yes configure: Summary of engine detection features autoit_ea06 : yes bzip2 : ok zlib: /usr unrar : yes dmg and xar : no Am I missing a configure flag or third party library? Thanks in advance, - Rafael scanii.com - the web friendly malware scanner! ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
