Re: [clamav-users] can't cmake 1.0.4rc

[Gene Heskett via clamav-users]

On Thursday 29 July 2021 18:38:52 Rick Cooper wrote:

> Gene Heskett via clamav-users wrote:
> > On Thursday 29 July 2021 12:28:21 Rick Cooper wrote:
> >> Gene Heskett via clamav-users wrote:
> >>> On Thursday 29 July 2021 06:33:02 Rick Cooper wrote:
>  Had the same problem, install the check package. It's a unit test
>  framework.
> >>>
> >>> Did that, and about 5 or 6 other pkgs I've never needed before and
> >>> it finally did install, restarted anything starting with clam
> >>> in /etc/init.d and everything including procmail seems to be
> >>> happy.
> >>>
> >>> except its still running 1.0.2.whatever Did it not update the
> >>> /etc/init.d files? Looks like they weren't touched. WTH?  Hells
> >>> bells, it didn't even make them! Go read the install.md again.
> >>>
> >>> Cheers, Gene Heskett
> >>
> >> Looking through the CMakeOptions.cmake file there only appears to
> >> be an entry for systemd, nothing for systemv.
> >> Just set the following flags to match the locations you currently
> >> use and the init script should work I think:
> >> -D CMAKE_INSTALL_PREFIX="(example /usr)"
> >> -D APP_CONFIG_DIRECTORY="(example /etc)"
> >>
> >> I built on a Centos 7 system and it did see systemd and install the
> >> .system file
> >
> > Should I do a cmake clean first?
> >
> > Thanks Rick.
> >
> >> ___
> >>
> >> clamav-users mailing list
> >> clamav-users@lists.clamav.net
> >> https://lists.clamav.net/mailman/listinfo/clamav-users
> >>
> >>
> >> Help us build a comprehensive ClamAV guide:
> >> https://github.com/vrtadmin/clamav-faq
> >>
> >> http://www.clamav.net/contact.html#ml
> >
> > Cheers, Gene Heskett
>
> Just enter your build (not source) directory and do a rf -f that
> cleans up, hell I doubt that they have a clean target
> Just make sure the prefix and app config dir are what you want, if you
> want /usr/sbin instead of /usr/local/sbin then just /usr.
>
Well, I've screwed around with this for 3 days now, that's long enough.

First gotcha for debian people is cmake is not installed, and when 
installed, it is NOT installed in a directory accessible to the user 
with a default $PATH, so the first thing I have to do is give it the 
full path to where its installed. And apparently there are no man pages, 
strike two.

Second gotcha is cmake needs about 7 or so more bits installed that in 23 
years of exclusively linux in this house I have never needed before just 
to get thru the configure and build something. Strikes 3 thru 9 or 10

Third gotcha is that the default build puts it in /usr/local, a normal 
occurrence for stuff built from tarballs, without building new stuff 
for /etc/init.d that tells it where to find the executables NOW. 
Depending on a 1/4 baked systemd on an older stretch install isn't doing 
one a bit of good unless perchance you are rebooting.

Please let us know when this is actually installable and working when the 
notes in INSTALL.md are followed. It is not ready for prime time now. 

You can start by listing the dependencies AND the packages they are found 
in, in INSTALL.md so we can install them without any excitement.

Thank you.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

___

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Re: [clamav-users] can't cmake 1.0.4rc

[Rick Cooper]

I of course meant RM not RF, sorry.

Gene Heskett via clamav-users wrote:
> On Thursday 29 July 2021 12:28:21 Rick Cooper wrote:
> 
>> Gene Heskett via clamav-users wrote:
>>> On Thursday 29 July 2021 06:33:02 Rick Cooper wrote:
 Had the same problem, install the check package. It's a unit test
 framework.
>>> 
>>> Did that, and about 5 or 6 other pkgs I've never needed before and
>>> it finally did install, restarted anything starting with clam
>>> in /etc/init.d and everything including procmail seems to be happy.
>>> 
>>> except its still running 1.0.2.whatever Did it not update the
>>> /etc/init.d files? Looks like they weren't touched. WTH?  Hells
>>> bells, it didn't even make them! Go read the install.md again.
>>> 
>>> Cheers, Gene Heskett
>> 
>> Looking through the CMakeOptions.cmake file there only appears to be
>> an entry for systemd, nothing for systemv.
>> Just set the following flags to match the locations you currently use
>> and the init script should work I think:
>> -D CMAKE_INSTALL_PREFIX="(example /usr)"
>> -D APP_CONFIG_DIRECTORY="(example /etc)"
>> 
>> I built on a Centos 7 system and it did see systemd and install the
>> .system file 
>> 
> Should I do a cmake clean first?
> 
> Thanks Rick.
>> ___
>> 
>> clamav-users mailing list
>> clamav-users@lists.clamav.net
>> https://lists.clamav.net/mailman/listinfo/clamav-users
>> 
>> 
>> Help us build a comprehensive ClamAV guide:
>> https://github.com/vrtadmin/clamav-faq
>> 
>> http://www.clamav.net/contact.html#ml
> 
> 
> Cheers, Gene Heskett


___

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Re: [clamav-users] can't cmake 1.0.4rc

[Rick Cooper]

Gene Heskett via clamav-users wrote:
> On Thursday 29 July 2021 12:28:21 Rick Cooper wrote:
> 
>> Gene Heskett via clamav-users wrote:
>>> On Thursday 29 July 2021 06:33:02 Rick Cooper wrote:
 Had the same problem, install the check package. It's a unit test
 framework.
>>> 
>>> Did that, and about 5 or 6 other pkgs I've never needed before and
>>> it finally did install, restarted anything starting with clam
>>> in /etc/init.d and everything including procmail seems to be happy.
>>> 
>>> except its still running 1.0.2.whatever Did it not update the
>>> /etc/init.d files? Looks like they weren't touched. WTH?  Hells
>>> bells, it didn't even make them! Go read the install.md again.
>>> 
>>> Cheers, Gene Heskett
>> 
>> Looking through the CMakeOptions.cmake file there only appears to be
>> an entry for systemd, nothing for systemv.
>> Just set the following flags to match the locations you currently use
>> and the init script should work I think:
>> -D CMAKE_INSTALL_PREFIX="(example /usr)"
>> -D APP_CONFIG_DIRECTORY="(example /etc)"
>> 
>> I built on a Centos 7 system and it did see systemd and install the
>> .system file 
>> 
> Should I do a cmake clean first?
> 
> Thanks Rick.
>> ___
>> 
>> clamav-users mailing list
>> clamav-users@lists.clamav.net
>> https://lists.clamav.net/mailman/listinfo/clamav-users
>> 
>> 
>> Help us build a comprehensive ClamAV guide:
>> https://github.com/vrtadmin/clamav-faq
>> 
>> http://www.clamav.net/contact.html#ml
> 
> 
> Cheers, Gene Heskett

Just enter your build (not source) directory and do a rf -f that cleans up,
hell I doubt that they have a clean target
Just make sure the prefix and app config dir are what you want, if you want
/usr/sbin instead of /usr/local/sbin then just /usr.


___

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Re: [clamav-users] [OT] ClamAV® blog: ClamAV 0.104.0 Release Candidate is here!

[G.W. Haywood via clamav-users]

Hi there,

On Thu, 29 Jul 2021, Paul Kosinski via clamav-users wrote:


... do any firewall distros address inter-LAN filtering?


We're well off-topic here so I think we should stop this now, but I
thought most of them do.  What you describe is what I think they
usually call a 'DMZ', very often 'ORANGE', where the LAN is 'GREEN'
and the public Internet 'RED'.

--

73,
Ged.

___

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Re: [clamav-users] [OT] ClamAV® blog: ClamAV 0.104.0 Release Candidate is here!

[Gene Heskett via clamav-users]

On Thursday 29 July 2021 14:45:28 G.W. Haywood via clamav-users wrote:

> Hi there,
>
> On Thu, 29 Jul 2021, Paul Kosinski via clamav-users wrote:
> > My current firewall, which also does inter-LAN routing with iptables
> > filtering, has six (6) gigabit Ethernet ports on it (including one
> > 4-port Intel card in a PCIe-x4 slot). Which model Raspberry Pi
> > should I use?
>
> From my experience I would say avoid the 4B if you value stability.

>From here, and I'm running a linuxcnc buildbot on my 2gig 4b, all it 
needs is adequate cooling, in my case the 4 little bitty heat sinks AND 
a stolen 12 volt video card fan running on 5 volts blowing rather 
leasurely on them.  And it runs from power outage to power outage, which 
I have to create by shutting off the power strip its running on as I 
have a standby that starts in about 4 seconds, and its on a 650 WA UPS 
with a 2 minute shutdown I can't change.

It just works. For months and months.

> You'd probably want to use USB-Ethernet adaptors.  You could have more
> or less as many as you like.  I'm using Ethernet over USB with several
> little Pi Zeros.  No actual physical Ethernet hardware, but a network
> stack etc. in the applications.  The Zero has no Ethernet port at all
> but some of the things we're running on them expect you to have one.
> You can comfortably watch movies on the Pi Zero.  It's amazing such a
> tiny thing can do that, at least it is when you're as old as I am and
> the first CPU youactually handled was a 1MHz (ONE MegaHertz) Motorola
> 6800, and you had to wear ear defenders for programming it via ASR33.
>
> Without knowing more about the performance you'd need I couldn't say
> whether one Pi or another would do the job, but unless you're a very
> heavy user of bandwidth I'd be surprised if you'd stress the quad core
> 1.4 GHz CPU of a Pi 3B+ in a firewall just filtering packets.  To be
> honest, the few times that I've run CPU stats on my firewalls, the CPU
> usage has been so low that it hasn't really made an impression.  I've
> just checked our perimeter firewall, CPU is hovering about 99.6% idle.
> As I said this isn't a Pi, it's an ALIX board which is a single-core,
> 32 bit AMD 'Geode' at 500MHz.  Never seen one crash.
>
> Straying back somewhere near the topic, I think you'd need the Pi4B
> with probably 4G of RAM to run clamd or clamscan.  I run clamd on one
> but that's all it does.  It crashes occasionally, last time was 6.5
> days ago.  My money's on power supply problems.  I don't think it's
> temperature related, it was running at about 65C when it crashed last,
> it redlines at 85C.  It's supposed to throttle itself when it gets up
> there but I haven't any done real stress testing like I have with some
> other devices.  Most of our 4Bs are in at least 50% glazed offices and
> despite being in England it can get very warm in there sometimes.  In
> summer they're often operating in the 70s without any trouble.  We fit
> the CPUs with heat sinks, but no fan.
>
> You might be able to run a local ClamAV mirror with only a Pi 3B+ with
> its roughly 850M available RAM - I'll give that a try someday.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

___

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Re: [clamav-users] can't cmake 1.0.4rc

[Gene Heskett via clamav-users]

On Thursday 29 July 2021 12:28:21 Rick Cooper wrote:

> Gene Heskett via clamav-users wrote:
> > On Thursday 29 July 2021 06:33:02 Rick Cooper wrote:
> >> Had the same problem, install the check package. It's a unit test
> >> framework.
> >
> > Did that, and about 5 or 6 other pkgs I've never needed before and
> > it finally did install, restarted anything starting with clam
> > in /etc/init.d and everything including procmail seems to be happy.
> >
> > except its still running 1.0.2.whatever Did it not update the
> > /etc/init.d files? Looks like they weren't touched. WTH?  Hells
> > bells, it didn't even make them! Go read the install.md again.
> >
> > Cheers, Gene Heskett
>
> Looking through the CMakeOptions.cmake file there only appears to be
> an entry for systemd, nothing for systemv.
> Just set the following flags to match the locations you currently use
> and the init script should work I think:
> -D CMAKE_INSTALL_PREFIX="(example /usr)"
> -D APP_CONFIG_DIRECTORY="(example /etc)"
>
> I built on a Centos 7 system and it did see systemd and install the
> .system file
>
Should I do a cmake clean first?

Thanks Rick.
> ___
>
> clamav-users mailing list
> clamav-users@lists.clamav.net
> https://lists.clamav.net/mailman/listinfo/clamav-users
>
>
> Help us build a comprehensive ClamAV guide:
> https://github.com/vrtadmin/clamav-faq
>
> http://www.clamav.net/contact.html#ml


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

___

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Re: [clamav-users] can't cmake 1.0.4rc

[Paul Kosinski via clamav-users]

On Thu, 29 Jul 2021 08:52:57 +0100 (BST)
"G.W. Haywood via clamav-users"  wrote:

> Maybe there's no need to worry about that.  I've seen cases where the
> build process looks for a shared object, finds a 32 bit version when
> it's building for 64 bit, and then complains that it doesn't exist.
> It does exist, but it's found the one for the wrong architecture and
> doesn't understand what it's found.  If this is the case here, it's a
> little disappointing (after the build-up we've had for cmake) that it
> will get it as badly around its neck as autotools.
> 
> Do you really need the 32-bit stuff?  Do you have mixed 32 bit and 64
> bit binaries on your system?  If so you're going to run into this kind
> of thing more or less randomly when you build anything and you might
> need to dig into it yourself a bit more.  If you don't need the mixed
> architectures you'd be better off without the 32 bit stuff in there.
> 
> You could try using the package manage to try to remove the 32 bit
> version of libpthread.  If it's needed by something it will tell you,
> and you can take a view on what to do abuot it.

=

Are the build tools that deficient? I have both 64 and 32-bit stuff on my 
Debian system, and the 'file' command is able to report what a shared object 
file is (e.g., see below). Maybe CMAKE does it better?

  /usr/lib/x86_64-linux-gnu/libasan.so.5.0.0: ELF 64-bit LSB shared object, 
x86-64, version 1 (SYSV), dynamically linked, 
BuildID[sha1]=3cf2e4b5261216f9a156ed5dc2953d8b6f98987d, stripped

  /usr/libx32/libasan.so.5.0.0: ELF 32-bit LSB shared object, x86-64, version 1 
(SYSV), dynamically linked, 
BuildID[sha1]=1289f4162c3de1fbe87d1f28ee3876ec8467ac2d, stripped

___

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Re: [clamav-users] [OT] ClamAV® blog: ClamAV 0.104.0 Release Candidate is here!

[Paul Kosinski via clamav-users]

On Wed, 28 Jul 2021 12:53:38 +0100 (BST)
"G.W. Haywood via clamav-users"  wrote:

> I'd recommend not using any big distro for your perimiter firewall.
> I use one of the purpose-built stripped-down firewall distributions.

"..our home firewall and gateway -- with iptables, multi-LAN routing (with 
local DNS), a bit of bridging, encrypted tunnels to elsewhere, etc."
I forgot to mention that it also logs to disk all Internet traffic, which is 
handy for occasional historical analysis of events via Wireshark. As far as 
being stripped down goes, the firewall/gatewaay has no X-windows stuff at all 
installed.

I think stripped-down distros are often too focused. And from what I've seen of 
some common firewalls, they're too simple-minded (e.g. firewalld), perhaps 
aimed at people who are terrified of the command line. (I personally found the 
CLI to be a great improvement over punched cards, just as the GUI is a 
wonderful improvement for many -- but not all -- tasks.) Also, Debian, being a 
major distro which is the basis for Ubuntu and others, has long been very 
reliable in providing security and bug fixes. How many smaller distros are as 
future-proof?

Finally, do any firewall distros address inter-LAN filtering? We have two major 
LANs, Black and Red. Black is the trusted LAN, while Red is for Internet TV 
etc. (on physically separate computers, of course). Red can access the Internet 
but is not allowed access to Black. Black has limited access to Red (for SSH, 
VNC and the like). Both are firewalled from the Internet (with Red a bit less 
so).


___

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Re: [clamav-users] [OT] ClamAV® blog: ClamAV 0.104.0 Release Candidate is here!

[G.W. Haywood via clamav-users]

Hi there,

On Thu, 29 Jul 2021, Paul Kosinski via clamav-users wrote:


My current firewall, which also does inter-LAN routing with iptables
filtering, has six (6) gigabit Ethernet ports on it (including one
4-port Intel card in a PCIe-x4 slot). Which model Raspberry Pi
should I use?



From my experience I would say avoid the 4B if you value stability.


You'd probably want to use USB-Ethernet adaptors.  You could have more
or less as many as you like.  I'm using Ethernet over USB with several
little Pi Zeros.  No actual physical Ethernet hardware, but a network
stack etc. in the applications.  The Zero has no Ethernet port at all
but some of the things we're running on them expect you to have one.
You can comfortably watch movies on the Pi Zero.  It's amazing such a
tiny thing can do that, at least it is when you're as old as I am and
the first CPU youactually handled was a 1MHz (ONE MegaHertz) Motorola
6800, and you had to wear ear defenders for programming it via ASR33.

Without knowing more about the performance you'd need I couldn't say
whether one Pi or another would do the job, but unless you're a very
heavy user of bandwidth I'd be surprised if you'd stress the quad core
1.4 GHz CPU of a Pi 3B+ in a firewall just filtering packets.  To be
honest, the few times that I've run CPU stats on my firewalls, the CPU
usage has been so low that it hasn't really made an impression.  I've
just checked our perimeter firewall, CPU is hovering about 99.6% idle.
As I said this isn't a Pi, it's an ALIX board which is a single-core,
32 bit AMD 'Geode' at 500MHz.  Never seen one crash.

Straying back somewhere near the topic, I think you'd need the Pi4B
with probably 4G of RAM to run clamd or clamscan.  I run clamd on one
but that's all it does.  It crashes occasionally, last time was 6.5
days ago.  My money's on power supply problems.  I don't think it's
temperature related, it was running at about 65C when it crashed last,
it redlines at 85C.  It's supposed to throttle itself when it gets up
there but I haven't any done real stress testing like I have with some
other devices.  Most of our 4Bs are in at least 50% glazed offices and
despite being in England it can get very warm in there sometimes.  In
summer they're often operating in the 70s without any trouble.  We fit
the CPUs with heat sinks, but no fan.

You might be able to run a local ClamAV mirror with only a Pi 3B+ with
its roughly 850M available RAM - I'll give that a try someday.

--

73,
Ged.

___

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Re: [clamav-users] Long Term Support (LTS) program proposal

[Mark Fortescue via clamav-users]

Hi All,

In my world, 5 years is short. It use to take me 3 years to get a stable 
enough uBuntu kernel to patch in my changes. The 14.0x LTS 4.4.x kernel 
never became stable enough.


I will be looking to the industrial Linux at 10 to 25 years for kernels 
for the future.


For most of the software I would be looking at no less than 5 years long 
term support where longer term support (10+ years) is not available.


In my experience, most industry considers 5 years far too short. That is 
why Windows XP was such a success. Its longevity.


Where I work they still run AT bus PCs with 2.4 series kernel because 
the upgrade cost is considered prohibitive. It is not just the PC and 
bespoke software. It is all the bespoke hardware that goes with it. When 
the hardware becomes totally unsupportable there will be a long loss of 
service as totally new software and hardware will be needed. There are 
no budgeted funds for obsolescence.


Please reconsider the 3 years you proposing. 5 years should be the norm 
and extra years for those prepared to pay for the privilege.


Release years. Every two years works OK. Beware of 2037. In 2037 
everyone will be updating things and by 2038 it will be a mess (unix 
time). Like last time (Y2K) management will, if possible, leave it to 
the lasts microsecond. I suspect that most 32bit systems will be fine as 
they will just ignore the sign bit. It will be all these new 64bit 
systems that will fail miserably (sign extending their filing system 
time stamps).


Regards
Mark.

On 29/07/2021 00:53, Micah Snyder (micasnyd) via clamav-users wrote:

Hi All,

For the past couple of months I’ve been promoting the idea of having 
Long Term Support (LTS) feature releases for ClamAV within internal 
Talos communications.


For the purposes of this discussion:

  * A “feature release” is a version starting with MAJOR.MINOR.0 to
include all PATCH versions. I.e. ClamAV 0.103.0, 0.103.1, 0.103.2,
and 0.103.3 are all within the same “feature release”.
  * A “patch version” is a specific MAJOR.MINOR.PATCH version. E.g.
0.103.4 would be the next “patch version” in the 0.103 “feature
release”.

My interest in starting an LTS program came about because we have been 
getting (understandable) pressure from management to have shorter 
development times for feature versions with more targeted feature sets.  
What this means is that you would see more frequent feature releases, 
possibly as many as ~5 per year.  Some of the features in a given 
feature release would be things the community cares about, while others 
may be by request of a different team within Talos or Cisco.


But I couldn’t in good conscience start pumping out new feature releases 
every 2-4 months and expect everyone to keep up. And at that rate it 
would not be possible for us to make critical patch versions for every 
feature release within the two years, or even one year.  So in order to 
get features out faster it became clear to me that we will need to 
define /specific feature release/ for which we promise to backport 
security fixes for /some amount of time/.


This raised a few obvious questions:

  * Which feature release do we start with?
  * Do we have to continue serving signature database content to every
patch version in an LTS release?
  * How often should we select a new feature release for LTS?
  * How long is “long term support” anyways?

We’ve been talking about this off and on for the past couple of month. 
  This is what I came up with….


*/Which feature version do we start with?/*

We /had/ initially settled on 0.104 as the first LTS version, for 
basically two reasons:


-Joel really wants to make sure people have the latest freshclam 
features, particularly those found in 0.103.2 and 0.103.3, to reduce 
bandwidth cost.


-I don’t want to keep fixing glitchy autotools package detection issues 
for years to come.


But after seeing the (very much unexpected) reaction to the switch 
CMake… it’s clear to me now that *we need to start the LTS program with 
**0.103*.


*/Do we have to continue serving database content to every patch version 
in an LTS release?/*


No.

LTS means that we will promise to continue providing patch versions for 
a given feature release.


I.e. you will get critical fixes in 0.103.4, 0.103.5, 0.103.6, etc. as 
needed until End of Life (EOL) for the 0.103 feature release.


*I need to stress* *that* it doesn’t mean people should /or will be 
allowed/ to continue using vulnerable or otherwise problematic versions 
such as 0.103.0 and 0.103.1 just because they belong to an LTS feature 
release. /We will reserve the right to at some point begin to block 
older patch versions like 0.103.0 from downloading databases to force 
people to use newer patch versions./**


//

*/How often should we select a new feature release for LTS?/*

Some products, like Ubuntu, do a new LTS ever 2 years with support for 5 
years.  2 years feels like a long time but, as much 

Re: [clamav-users] ClamAVR blog: ClamAV 0.104.0 Release Candidate is here!

[Joel Esler (jesler) via clamav-users]

> On Jul 28, 2021, at 6:09 PM, Rick Cooper  wrote:
> 
>> On Jul 28, 2021, at 7:17 AM, Rick Cooper > > wrote:
>> 
>> total disregard for the user base, not so much as a poll or query on the 
>> lists, enjoy your new cutting edge toys
>>  
>> Corporate BS rears it's ugly head again, First snort, then centos and now 
>> clamav.
> 
> I think this is unfair.  This is the feedback we’re getting.  Sounds like we 
> don’t need a poll or a query.  We’re hearing it now.
>  
> Actually the way it was presented was here is what's going to happen and not 
> what would the community think about going to cmake, here are the advantages 
> to the community if we go this way. It wasn't presented as an option and it 
> took a lot of people off guard. It's like someone on the list said if you are 
> using an old stable enterprise version maybe you just need to switch to 
> something more cutting edge like Fedora, which is not stable and shouldn't be 
> used in an enterprise situation. When I upgrade an OS it's a very big deal 
> because I have to template it, use it in production at one of the sites to 
> make sure everything is stable, keep it out of the other upgrade paths (the 
> older OS's) and image it, go to several (100+es each) cities on a Sunday (to 
> be at console and cannot take it down any other day) and then update the site 
> specific pieces, test everything and drive 100+ back. What might be a small 
> thing for some is a real life's mess for many others.
>  
> I didn't mean to be as offensive as it came out but I was pissed because for 
> my mail servers it's going to be a problem, I've built it on a file server 
> (Centos 7) alright but just to get to correct version of cmake built and all 
> the required dependencies was cumbersome at best. 

I don’t think we took it like that, I certainly didn’t.  I think a productive 
and healthy discussion around on the list is a great thing.  

>  
> 
> I also think it’s unfair to think “big bad Cisco” had anything to do with 
> this at all.  ClamAV is beholden to Cisco in very few ways. In that it’s 
> integrated i 
>  nto a few products, other than that, the ClamAV development team has pretty 
> full autonomy.  No one is coming down to Micah and saying "YOU MUST YOU CMAKE 
> YOU PEON DEVELOPER MUHAHAHAHAHA”.   
>  
> That was , in fact, unfair of me. Perhaps the team isn't part of the culture. 
> I have had issue with Cisco for quite some time, really going back to when 
> they bought Linksys because their hardware was over priced and more and more 
> enterprises was realizing the didn't to pay Cisco for a name... rather than 
> simply build a reasonable priced series of equipment (as they do today) they 
> bought a reasonably prices equipment vendor.

Cisco is a huge company. Security is quite different.


> If you have feedback, this is the perfect use of this list to do so, but 
> we’re also all adults, with jobs, with passions, and we can be professional.
> 
> As far as Snort, I think the same logic applies.  The rewrite of Snort 
> started long before Cisco even entered the picture, it started when we were 
> still Sourcefire back in 2011-2012.  I have the engineering slides! 
>  
> I'd have to think about it, I thought the paid sigs over community sigs began 
> with Cisco but maybe it was Sourcefire.

We transitioned to paid sigs in 2003-2004?  Cisco bought Sourcefire in 2013.  
So, yeah, Cisco had nothing to do with it.  However, I run that program as 
well, so I’m very familiar with why we did it, why we continue to do it, and 
what the pros and cons of it.  

> I am sure you are right it's my bad attitude about Cisco, I am waiting for 
> them to purchase ubiquiti next. and the entire IBM Centos mess just turns up 
> my "big company" hackles.

We purchased Meraki.  :) 




smime.p7s
Description: S/MIME cryptographic signature

___

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Re: [clamav-users] [OT] ClamAV® blog: ClamAV 0.104.0 Release Candidate is here!

[Paul Kosinski via clamav-users]

On Wed, 28 Jul 2021 23:31:05 +1000
"Gary R. Schmidt"  wrote:

> I second what Ged is saying here, for firewalls and so on the Raspberry 
> Pi and its ilk are a much better choice than a full-on system, they use 
> /much/ less power, and keeping a spare or three isn't a board- (or 
> wife-) level budget request.  :-)

My current firewall, which also does inter-LAN routing with iptables filtering, 
has six (6) gigabit Ethernet ports on it (including one 4-port Intel card in a 
PCIe-x4 slot). Which model Raspberry Pi should I use?

P.S. I could make do with 5 ports, as my second WAN (a static IP, but slow, 
DSL) was discontinued in late 2019.


___

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Re: [clamav-users] Long Term Support (LTS) program proposal

[Micah Snyder (micasnyd) via clamav-users]

>   Tuesday, August 18, 2020ClamAV 0.103.0 release candidate
>   Monday, September 14, 2020  ClamAV 0.103.0 released
> 
> So we are going by the (first) release candidate. OK.

Oops.  I was reading off of a spreadsheet.  It should be September then.  I'll 
have to correct the spreadsheet.

Sorry.


___

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Re: [clamav-users] can't cmake 1.0.4rc

[Rick Cooper]

Gene Heskett via clamav-users wrote:
> On Thursday 29 July 2021 06:33:02 Rick Cooper wrote:
> 
>> Had the same problem, install the check package. It's a unit test
>> framework.
> Did that, and about 5 or 6 other pkgs I've never needed before and it
> finally did install, restarted anything starting with clam
> in /etc/init.d and everything including procmail seems to be happy.
> 
> except its still running 1.0.2.whatever Did it not update the
> /etc/init.d files? Looks like they weren't touched. WTH?  Hells
> bells, it didn't even make them! Go read the install.md again.
> 
> Cheers, Gene Heskett

Looking through the CMakeOptions.cmake file there only appears to be an
entry for systemd, nothing for systemv.
Just set the following flags to match the locations you currently use and
the init script should work I think:
-D CMAKE_INSTALL_PREFIX="(example /usr)" 
-D APP_CONFIG_DIRECTORY="(example /etc)"

I built on a Centos 7 system and it did see systemd and install the .system
file


___

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Re: [clamav-users] can't cmake 1.0.4rc

[Gene Heskett via clamav-users]

On Thursday 29 July 2021 06:44:28 G.W. Haywood via clamav-users wrote:

> Hi Gene,
>
> On Thu, 29 Jul 2021, Gene Heskett via clamav-users wrote:
> > On Thursday 29 July 2021 03:52:57 G.W. Haywood via clamav-users
> > wrote:
> >
> > I am getting setup to put a 64 bit bullseye on this box, but getting
> > it all together will be another week at least.
>
> At this stage, waiting a week starts to sound like a good plan. :/
>
Yes, it screwed my install cuz all the PATH's were now wrong, didn't 
build new entries for /etc/init.d to account for the path changes, moved 
it all to /usr/local. So I forcibly reinstalled the 1.02.3 debs.

It definitely is not ready for prime time.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

___

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Re: [clamav-users] Long Term Support (LTS) program proposal

[Joel Esler (jesler) via clamav-users]

To be extremely specific, the LTS version would start with 0.103.3.  So that 
would be the base version we’d support for LTS.



> On Jul 29, 2021, at 10:06 AM, Andrew C Aitchison via clamav-users 
>  wrote:
> 
> 
> Executive Summary:
> An LTS release every two years, supported for three, starting with 0.103
> sound good to me. Thank you.
> 
> 
> On Wed, 28 Jul 2021, Micah Snyder (micasnyd) via clamav-users wrote:
> 
>> For the past couple of months I've been promoting the idea of having
>> Long Term Support (LTS) feature releases for ClamAV within internal
>> Talos communications.
>> For the purposes of this discussion:
>> 
>> * A "feature release" is a version starting with MAJOR.MINOR.0 to
>> include all PATCH versions. I.e. ClamAV 0.103.0, 0.103.1,
>> 0.103.2, and 0.103.3 are all within the same "feature release".
>> * A "patch version" is a specific MAJOR.MINOR.PATCH
>> version. E.g. 0.103.4 would be the next "patch version" in the
>> 0.103 "feature release".
>> My interest in starting an LTS program came about because we have
>> been getting (understandable) pressure from management to have
>> shorter development times for feature versions with more targeted
>> feature sets.  What this means is that you would see more frequent
>> feature releases, possibly as many as ~5 per year.  Some of the
>> features in a given feature release would be things the community
>> cares about, while others may be by request of a different team
>> within Talos or Cisco.
> 
> I don't *think* I want ever more features (though I may say "yes" when
> you suggest X and Y ... and Z ...). What I want is better detection
> (though I don't currently have an SMTP listener, so the number of
> pieces of malware my installation could detect is vanishingly small).
> 
> I can see management wanting you to work on one new feature at a time,
> releasing it and moving on to the next. If that works for your team, fine.
> If you work better by being able to switch between a couple of projects
> and release several at once, that is fine too.
> However, please make a release when it is ready; don't go down the
> Firefox route of a release timetable with features trying to catch the
> release train where they can (not that I think your team is big
> enough to do that).
> 
> 
>> But I couldn't in good conscience start pumping out new feature
>> releases every 2-4 months and expect everyone to keep up. And at
>> that rate it would not be possible for us to make critical patch
>> versions for every feature release within the two years, or even one
>> year.  So in order to get features out faster it became clear to me
>> that we will need to define specific feature release for which we
>> promise to backport security fixes for some amount of time.
>> This raised a few obvious questions:
>> 
>> *   Which feature release do we start with?
>> *   Do we have to continue serving signature database content
>>to every patch version in an LTS release?
>> *   How often should we select a new feature release for LTS?
>> *   How long is "long term support" anyways?
>> We've been talking about this off and on for the past couple of
>> month.  This is what I came up with
>> Which feature version do we start with?
>> We had initially settled on 0.104 as the first LTS version, for
>> basically two reasons:
>> -  Joel really wants to make sure people have the latest
>> -  freshclam features, particularly those found in 0.103.2
>> -  and 0.103.3, to reduce bandwidth cost.
>> -  I don't want to keep fixing glitchy autotools package
>> -  detection issues for years to come.
>> But after seeing the (very much unexpected) reaction to the switch
>> CMake... it's clear to me now that we need to start the LTS program
>> with 0.103.
> 
> Thanks.
> Sorry if that means you have to put up with a build system
> you don't like for another two years.
> 
>> Do we have to continue serving database content to every patch
>> version in an LTS release?
>> No.
>> LTS means that we will promise to continue providing patch versions
>> for a given feature release.  I.e. you will get critical fixes in
>> 0.103.4, 0.103.5, 0.103.6, etc. as needed until End of Life (EOL)
>> for the 0.103 feature release.
>> I need to stress that it doesn't mean people should or will be
>> allowed to continue using vulnerable or otherwise problematic
>> versions such as 0.103.0 and 0.103.1 just because they belong to an
>> LTS feature release. We will reserve the right to at some point
>> begin to block older patch versions like 0.103.0 from downloading
>> databases to force people to use newer patch versions.
>> How often should we select a new feature release for LTS?
>> Some products, like Ubuntu, do a new LTS ever 2 years with support
>> for 5 years.  2 years feels like a long time but, as much as I want
>> to get people using the latest features, our team is pretty small.
>> The more frequently we a release for long term support, 

Re: [clamav-users] can't cmake 1.0.4rc

[Gene Heskett via clamav-users]

On Thursday 29 July 2021 06:33:02 Rick Cooper wrote:

> Had the same problem, install the check package. It's a unit test
> framework.
Did that, and about 5 or 6 other pkgs I've never needed before and it 
finally did install, restarted anything starting with clam 
in /etc/init.d and everything including procmail seems to be happy. 

except its still running 1.0.2.whatever Did it not update the /etc/init.d 
files? Looks like they weren't touched. WTH?  Hells bells, it didn't 
even make them! Go read the install.md again.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

___

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Re: [clamav-users] Long Term Support (LTS) program proposal

[Andrew C Aitchison via clamav-users]

Executive Summary:
An LTS release every two years, supported for three, starting with 0.103
sound good to me. Thank you.


On Wed, 28 Jul 2021, Micah Snyder (micasnyd) via clamav-users wrote:


For the past couple of months I've been promoting the idea of having
Long Term Support (LTS) feature releases for ClamAV within internal
Talos communications.

For the purposes of this discussion:

 * A "feature release" is a version starting with MAJOR.MINOR.0 to
 include all PATCH versions. I.e. ClamAV 0.103.0, 0.103.1,
 0.103.2, and 0.103.3 are all within the same "feature release".
 * A "patch version" is a specific MAJOR.MINOR.PATCH
 version. E.g. 0.103.4 would be the next "patch version" in the
 0.103 "feature release".

My interest in starting an LTS program came about because we have
been getting (understandable) pressure from management to have
shorter development times for feature versions with more targeted
feature sets.  What this means is that you would see more frequent
feature releases, possibly as many as ~5 per year.  Some of the
features in a given feature release would be things the community
cares about, while others may be by request of a different team
within Talos or Cisco.


I don't *think* I want ever more features (though I may say "yes" when
you suggest X and Y ... and Z ...). What I want is better detection
(though I don't currently have an SMTP listener, so the number of
pieces of malware my installation could detect is vanishingly small).

I can see management wanting you to work on one new feature at a time,
releasing it and moving on to the next. If that works for your team, fine.
If you work better by being able to switch between a couple of projects
and release several at once, that is fine too.
However, please make a release when it is ready; don't go down the
Firefox route of a release timetable with features trying to catch the
release train where they can (not that I think your team is big
enough to do that).



But I couldn't in good conscience start pumping out new feature
releases every 2-4 months and expect everyone to keep up. And at
that rate it would not be possible for us to make critical patch
versions for every feature release within the two years, or even one
year.  So in order to get features out faster it became clear to me
that we will need to define specific feature release for which we
promise to backport security fixes for some amount of time.

This raised a few obvious questions:

 *   Which feature release do we start with?
 *   Do we have to continue serving signature database content
to every patch version in an LTS release?
 *   How often should we select a new feature release for LTS?
 *   How long is "long term support" anyways?

We've been talking about this off and on for the past couple of
month.  This is what I came up with

Which feature version do we start with?

We had initially settled on 0.104 as the first LTS version, for
basically two reasons:

-  Joel really wants to make sure people have the latest
-  freshclam features, particularly those found in 0.103.2
-  and 0.103.3, to reduce bandwidth cost.

-  I don't want to keep fixing glitchy autotools package
-  detection issues for years to come.

But after seeing the (very much unexpected) reaction to the switch
CMake... it's clear to me now that we need to start the LTS program
with 0.103.


Thanks.
Sorry if that means you have to put up with a build system
you don't like for another two years.


Do we have to continue serving database content to every patch
version in an LTS release?

No.

LTS means that we will promise to continue providing patch versions
for a given feature release.  I.e. you will get critical fixes in
0.103.4, 0.103.5, 0.103.6, etc. as needed until End of Life (EOL)
for the 0.103 feature release.

I need to stress that it doesn't mean people should or will be
allowed to continue using vulnerable or otherwise problematic
versions such as 0.103.0 and 0.103.1 just because they belong to an
LTS feature release. We will reserve the right to at some point
begin to block older patch versions like 0.103.0 from downloading
databases to force people to use newer patch versions.

How often should we select a new feature release for LTS?

Some products, like Ubuntu, do a new LTS ever 2 years with support
for 5 years.  2 years feels like a long time but, as much as I want
to get people using the latest features, our team is pretty small.
The more frequently we a release for long term support, the more
work each security release will be.  We would be required to create
and test a new patch version for the current stable feature release
plus a collection of LTS releases. If we did an LTS every year, that
would be too much.

I think 2 years is probably a good number.


It will be interesting to see which distros use the LTS and which
keep up with the feature releases.



How long is "long term support" anyways?

As 

Re: [clamav-users] Long Term Support (LTS) program proposal

[Scott Kitterman via clamav-users]

On July 28, 2021 11:53:35 PM UTC, "Micah Snyder (micasnyd) via clamav-users" 
 wrote:
>
>Hi All,
>
>For the past couple of months I've been promoting the idea of having Long Term 
>Support (LTS) feature releases for ClamAV within internal Talos communications.
>
>For the purposes of this discussion:
>
>  *   A "feature release" is a version starting with MAJOR.MINOR.0 to include 
> all PATCH versions. I.e. ClamAV 0.103.0, 0.103.1, 0.103.2, and 0.103.3 are 
> all within the same "feature release".
>  *   A "patch version" is a specific MAJOR.MINOR.PATCH version. E.g. 0.103.4 
> would be the next "patch version" in the 0.103 "feature release".
>
>My interest in starting an LTS program came about because we have been getting 
>(understandable) pressure from management to have shorter development times 
>for feature versions with more targeted feature sets.  What this means is that 
>you would see more frequent feature releases, possibly as many as ~5 per year. 
> Some of the features in a given feature release would be things the community 
>cares about, while others may be by request of a different team within Talos 
>or Cisco.
>
>But I couldn't in good conscience start pumping out new feature releases every 
>2-4 months and expect everyone to keep up. And at that rate it would not be 
>possible for us to make critical patch versions for every feature release 
>within the two years, or even one year.  So in order to get features out 
>faster it became clear to me that we will need to define specific feature 
>release for which we promise to backport security fixes for some amount of 
>time.
>
>This raised a few obvious questions:
>
>  *   Which feature release do we start with?
>  *   Do we have to continue serving signature database content to every patch 
> version in an LTS release?
>  *   How often should we select a new feature release for LTS?
>  *   How long is "long term support" anyways?
>
>We've been talking about this off and on for the past couple of month.  This 
>is what I came up with
>
>Which feature version do we start with?
>
>We had initially settled on 0.104 as the first LTS version, for basically two 
>reasons:
>
>-  Joel really wants to make sure people have the latest freshclam 
>features, particularly those found in 0.103.2 and 0.103.3, to reduce bandwidth 
>cost.
>
>-  I don't want to keep fixing glitchy autotools package detection 
>issues for years to come.
>
>But after seeing the (very much unexpected) reaction to the switch CMake... 
>it's clear to me now that we need to start the LTS program with 0.103.
>
>Do we have to continue serving database content to every patch version in an 
>LTS release?
>
>No.
>
>LTS means that we will promise to continue providing patch versions for a 
>given feature release.
>I.e. you will get critical fixes in 0.103.4, 0.103.5, 0.103.6, etc. as needed 
>until End of Life (EOL) for the 0.103 feature release.
>
>I need to stress that it doesn't mean people should or will be allowed to 
>continue using vulnerable or otherwise problematic versions such as 0.103.0 
>and 0.103.1 just because they belong to an LTS feature release. We will 
>reserve the right to at some point begin to block older patch versions like 
>0.103.0 from downloading databases to force people to use newer patch versions.
>
>How often should we select a new feature release for LTS?
>
>Some products, like Ubuntu, do a new LTS ever 2 years with support for 5 
>years.  2 years feels like a long time but, as much as I want to get people 
>using the latest features, our team is pretty small.  The more frequently we a 
>release for long term support, the more work each security release will be.  
>We would be required to create and test a new patch version for the current 
>stable feature release plus a collection of LTS releases. If we did an LTS 
>every year, that would be too much.
>
>I think 2 years is probably a good number.
>
>How long is "long term support" anyways?
>
>As noted above and elsewhere, Ubuntu and RHEL/CentOS support LTS versions for 
>5 years.  That's a long time, and more than our team could agree to.
>After a bunch of discussion, we think 3 years is a good number.
>
>To summarize, I'm proposing a Long Term Support (LTS) program for ClamAV 
>starting with the 0.103 feature release.  This means:
>
>
>  1.  We will promise to provide critical patch versions (0.103.4, .5., .6, 
> etc.) as needed until the LTS end-of-life.
>This does not mean that the original 0.103.0 or other problematic patch 
>versions within the series will continue to "work".
>Users MUST be willing to upgrade to newer patch versions within a given LTS 
>release.
>
>  2.  Each LTS release would be supported for three (3) years from the first 
> (.0) version.
>
>0.103.0 was published in August 2020.  This means we would continue to provide 
>critical patch versions for 0.103 until August 2023.
>
>  3.  We will aim to select a new LTS feature release every two (2) years.
>
>With 

Re: [clamav-users] Long Term Support (LTS) program proposal

[Rick Cooper]

Sounds fair and gives a lot more time to migrate

  _  

From: clamav-users [mailto:clamav-users-boun...@lists.clamav.net] On Behalf
Of Micah Snyder (micasnyd) via clamav-users
Sent: Wednesday, July 28, 2021 7:54 PM
To: ClamAV users ML
Cc: Micah Snyder (micasnyd); ClamAV Development
Subject: [clamav-users] Long Term Support (LTS) program proposal



 

Hi All,

 

For the past couple of months I've been promoting the idea of having Long
Term Support (LTS) feature releases for ClamAV within internal Talos
communications. 

 

For the purposes of this discussion:

*   A "feature release" is a version starting with MAJOR.MINOR.0 to
include all PATCH versions. I.e. ClamAV 0.103.0, 0.103.1, 0.103.2, and
0.103.3 are all within the same "feature release". 

*   A "patch version" is a specific MAJOR.MINOR.PATCH version. E.g.
0.103.4 would be the next "patch version" in the 0.103 "feature release".

 

My interest in starting an LTS program came about because we have been
getting (understandable) pressure from management to have shorter
development times for feature versions with more targeted feature sets.
What this means is that you would see more frequent feature releases,
possibly as many as ~5 per year.  Some of the features in a given feature
release would be things the community cares about, while others may be by
request of a different team within Talos or Cisco. 

 

But I couldn't in good conscience start pumping out new feature releases
every 2-4 months and expect everyone to keep up. And at that rate it would
not be possible for us to make critical patch versions for every feature
release within the two years, or even one year.  So in order to get features
out faster it became clear to me that we will need to define specific
feature release for which we promise to backport security fixes for some
amount of time.

 

This raised a few obvious questions:

*   Which feature release do we start with? 

*   Do we have to continue serving signature database content to every
patch version in an LTS release? 

*   How often should we select a new feature release for LTS? 

*   How long is "long term support" anyways?

 

We've been talking about this off and on for the past couple of month.  This
is what I came up with..

 

Which feature version do we start with?

 

We had initially settled on 0.104 as the first LTS version, for basically
two reasons:

-  Joel really wants to make sure people have the latest freshclam
features, particularly those found in 0.103.2 and 0.103.3, to reduce
bandwidth cost.

-  I don't want to keep fixing glitchy autotools package detection
issues for years to come.

 

But after seeing the (very much unexpected) reaction to the switch CMake.
it's clear to me now that we need to start the LTS program with 0.103. 

 

Do we have to continue serving database content to every patch version in an
LTS release?

 

No. 

 

LTS means that we will promise to continue providing patch versions for a
given feature release.

I.e. you will get critical fixes in 0.103.4, 0.103.5, 0.103.6, etc. as
needed until End of Life (EOL) for the 0.103 feature release. 

 

I need to stress that it doesn't mean people should or will be allowed to
continue using vulnerable or otherwise problematic versions such as 0.103.0
and 0.103.1 just because they belong to an LTS feature release. We will
reserve the right to at some point begin to block older patch versions like
0.103.0 from downloading databases to force people to use newer patch
versions. 

 

How often should we select a new feature release for LTS?

 

Some products, like Ubuntu, do a new LTS ever 2 years with support for 5
years.  2 years feels like a long time but, as much as I want to get people
using the latest features, our team is pretty small.  The more frequently we
a release for long term support, the more work each security release will
be.  We would be required to create and test a new patch version for the
current stable feature release plus a collection of LTS releases. If we did
an LTS every year, that would be too much.

I think 2 years is probably a good number.

 

How long is "long term support" anyways?

 

As noted above and elsewhere, Ubuntu and RHEL/CentOS support LTS versions
for 5 years.  That's a long time, and more than our team could agree to.  

After a bunch of discussion, we think 3 years is a good number. 

 

To summarize, I'm proposing a Long Term Support (LTS) program for ClamAV
starting with the 0.103 feature release.  This means:

 

1.  We will promise to provide critical patch versions (0.103.4, .5.,
.6, etc.) as needed until the LTS end-of-life. 
This does not mean that the original 0.103.0 or other problematic patch
versions within the series will continue to "work".  
Users MUST be willing to upgrade to newer patch versions within a given LTS
release. 



2.  Each LTS release would be supported for three (3) years from the
first (.0) version. 

0.103.0 was 

Re: [clamav-users] Freshclam - can't apply latest patch 26246

[Lee, Raymond via clamav-users]

Hi Elia,

Regarding your inconsistent freshclam updates, did you by chance
pre-install any virus signatures before running freshclam?  I found that if
I installed the clamav-data RPM package from the CentOS repository, I ran
into the freshclam update errors.   To get past that, you can just delete
/var/lib/clamav/* and run freshclam again or don't install clamav-data to
begin with so that freshclam can download all the latest signatures.

Kind Regards,
Ray

On Thu, Jul 29, 2021 at 6:19 AM Andrew C Aitchison via clamav-users <
clamav-users@lists.clamav.net> wrote:

> On Thu, 29 Jul 2021, Asenova, Elia via clamav-users wrote:
>
> > Thanks for the replies. Yes, deleting daily.cld fixed the
> > problem. My concern is that I'm building a docker image with clamav
> > inside it and I have to delete daily.cld on every new build if I
> > want freshclam to work correctly the first time. About the
> > subsequent runs when I tried to run freshclam on two different pods
> > after image deploy, daily.cld was updated to the latest version only
> > on one of them. These are the logs for both pods:
> >
> > #1st pod (successful update):
> > Connecting via dnat.genesaas.io
> > ClamAV update process started at Thu Jul 29 08:54:30 2021
> > daily database available for update (local version: 26231, remote
> version: 26246)
> > Current database is 15 versions behind.
> > Downloading database patch # 26232...
> > ERROR: cdiff_apply: lseek(desc, -350, SEEK_END) failed
> > ERROR: downloadPatch: Can't apply patch
> > WARNING: Incremental update failed, trying to download daily.cvd
> > Time:   21.8s, ETA:0.0s [>]
>  54.95MiB/54.95MiB
> > Testing database:
> '/var/lib/clamav/tmp.98ba2d17af/clamav-474d295bd3248aa18d6abaf0dc93f952.tmp-daily.cvd'
> ...
> > Database test passed.
> > daily.cvd updated (version: 26246, sigs: 1964581, f-level: 90, builder:
> raynman)
> > main.cvd database is up-to-date (version: 61, sigs: 6607162, f-level:
> 90, builder: sigmgr)
> > bytecode.cvd database is up-to-date (version: 333, sigs: 92, f-level:
> 63, builder: awillia2)
>
> Start with daily 26233 (or better whatever is the latest today) and main
> 61.
> By starting with daily 26231 and main 59 you immediately have to do a major
> (once in maybe six months) update.
>
> As Matus and Ged have suggested, you should not need to install the
> database on each docker instance.
> Unless you have a large anti-virus farm, you don't even need to *run* the
> d clam daemon on every VM. Start up a single remote clamd server and the
> other VMs can pass their scans to your clamd server with clamdscan.
>
>
> > 2nd pod (unsuccessful update):
> > Connecting via dnat.genesaas.io
> > ClamAV update process started at Thu Jul 29 09:14:16 2021
> > daily database available for update (local version: 26231, remote
> version: 26247)
> > Current database is 16 versions behind.
> > Downloading database patch # 26232...
> > ERROR: cdiff_apply: lseek(desc, -350, SEEK_END) failed
> > ERROR: downloadPatch: Can't apply patch
> > WARNING: Incremental update failed, trying to download daily.cvd
> > Time:   26.5s, ETA:0.0s [>]
>  54.95MiB/54.95MiB
> > Received an older daily CVD than was advertised. We'll retry so the
> incremental update will ensure we're up-to-date.
> > daily database available for update (local version: 26231, remote
> version: 26247)
> > Current database is 16 versions behind.
> > Downloading database patch # 26232...
> > ERROR: cdiff_apply: lseek(desc, -350, SEEK_END) failed
> > ERROR: downloadPatch: Can't apply patch
> > WARNING: Incremental update failed, trying to download daily.cvd
> > Time:   28.0s, ETA:0.0s [>]
>  54.95MiB/54.95MiB
> > Received an older daily CVD than was advertised. We'll retry so the
> incremental update will ensure we're up-to-date.
> > daily database available for update (local version: 26231, remote
> version: 26247)
> > Current database is 16 versions behind.
> > Downloading database patch # 26232...
> > ERROR: cdiff_apply: lseek(desc, -350, SEEK_END) failed
> > ERROR: downloadPatch: Can't apply patch
> > WARNING: Incremental update failed, trying to download daily.cvd
> > Time:   25.5s, ETA:0.0s [>]
>  54.95MiB/54.95MiB
> > Received an older daily CVD than was advertised. We'll retry so the
> incremental update will ensure we're up-to-date.
> > main.cvd database is up-to-date (version: 61, sigs: 6607162, f-level:
> 90, builder: sigmgr)
> > bytecode.cvd database is up-to-date (version: 333, sigs: 92, f-level:
> 63, builder: awillia2)
>
> > What might be the reason of this inconsistent behavior?
>
> From those logs it appears that daily 26247 was advertised between the two
> runs,
> but had't reach the mirror that you downloaded from.
>
>
> > And about the ReceiveTimeout this is what I have in freshclam.conf:
> > # Maximum time in seconds for each download operation. 0 means no
> timeout.
> > # Default: 0
> > #ReceiveTimeout 

Re: [clamav-users] can't cmake 1.0.4rc

[G.W. Haywood via clamav-users]

Hi Gene,

On Thu, 29 Jul 2021, Gene Heskett via clamav-users wrote:

On Thursday 29 July 2021 03:52:57 G.W. Haywood via clamav-users wrote:

I am getting setup to put a 64 bit bullseye on this box, but getting it all
together will be another week at least.


At this stage, waiting a week starts to sound like a good plan. :/


Now a rerun gets this:

gene@coyote:~/src/clamav-0.104.0-rc/build$ /usr/local/bin/cmake .. -D 
CMAKE_BUILD_TYPE="Release"
CMake Error at 
/usr/local/share/cmake-3.21/Modules/FindPackageHandleStandardArgs.cmake:230 
(message):
 Could NOT find Libcheck (missing: LIBCHECK_INCLUDE_DIR LIBCHECK_LIBRARY)
Call Stack (most recent call first):
[...]
CMakeError.log ends with this:

Linking C executable cmTC_38c19
/usr/local/bin/cmake -E cmake_link_script CMakeFiles/cmTC_38c19.dir/link.txt 
--verbose=1
/usr/bin/cc  -DCHECK_FUNCTION_EXISTS=pthread_create 
CMakeFiles/cmTC_38c19.dir/CheckFunctionExists.c.o -o cmTC_38c19  -lpthreads
/usr/bin/ld: cannot find -lpthreads
collect2: error: ld returned 1 exit status
CMakeFiles/cmTC_38c19.dir/build.make:98: recipe for target 'cmTC_38c19' failed
make[1]: *** [cmTC_38c19] Error 1
make[1]: Leaving directory 
'/home/gene/src/clamav-0.104.0-rc/build/CMakeFiles/CMakeTmp'
Makefile:127: recipe for target 'cmTC_38c19/fast' failed
make: *** [cmTC_38c19/fast] Error 2


This is exactly the same error message that you posted yesterday, it
looks like we've achieved nothing so far.  Are you sure that you've
removed the 32-bit pthreads library?  If you're sure, and if this is
still the error message, then it looks like my guess about 32 bit and
64 bit libs getting confused was wrong.


If you said its not ready for primetime, I'd have to agree. :o)


I suppose this is why there are release candidates.  Maybe this should
go on the development list before we outstay our welcome here on users.

--

73,
Ged.

___

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Re: [clamav-users] can't cmake 1.0.4rc

[Rick Cooper]

Had the same problem, install the check package. It's a unit test framework. 
-- 
rcoo...@dwford.com
Phone : (260) 414-8566

On July 29, 2021 5:50:26 AM EDT, Gene Heskett via clamav-users 
 wrote:
>On Thursday 29 July 2021 03:52:57 G.W. Haywood via clamav-users wrote:
>
>> Hi Gene,
>>
>> On Wed, 28 Jul 2021, Gene Heskett via clamav-users wrote:
>> > On Wednesday 28 July 2021 14:24:46 G.W. Haywood via clamav-users wrote:
>> >> On Wed, 28 Jul 2021, Gene Heskett via clamav-users wrote:
>> >>> /usr/bin/ld: cannot find -lpthreads
>> >>>
>> >>> But pthread is installed. "sudo ldconfg -v|grep pthread" comes
>> >>> back empty
>> >>>
>> >>> Now what?
>> >>
>> >> I'm guessing you have the stable version of ClamAV already
>> >> installed on the box, and so clamscan is installed?  Assuming so,
>> >> please post the output of ...
>> >
>> > ls -l `locate libpthread.so`
>> > lrwxrwxrwx 1 root root  18 Feb  6  2019 /lib32/libpthread.so.0 ->
>> > libpthread-2.24.so lrwxrwxrwx 1 root root  18 Feb  6  2019
>> > /lib/x86_64-linux-gnu/libpthread.so.0 -> libpthread-2.24.so
>> > -rw-r--r-- 1 root root 252 Feb  6  2019
>> > /usr/lib/x86_64-linux-gnu/libpthread.so
>> >
>> > ldconfig -p | grep pthread
>> >libpthread_workqueue.so.0 (libc6,x86-64) =>
>> > /usr/lib/x86_64-linux-gnu/libpthread_workqueue.so.0
>> > libpthread_workqueue.so (libc6,x86-64) =>
>> > /usr/lib/x86_64-linux-gnu/libpthread_workqueue.so libpthread.so.0
>> > (libc6,x86-64, OS ABI: Linux 2.6.32) =>
>> > /lib/x86_64-linux-gnu/libpthread.so.0 libpthread.so.0 (libc6, OS
>> > ABI: Linux 2.6.32) => /lib32/libpthread.so.0
>> > libevent_pthreads-2.0.so.5 (libc6,x86-64) =>
>> > /usr/lib/x86_64-linux-gnu/libevent_pthreads-2.0.so.5
>>
>> Ah.  You have both 32 bit and 64 bit versions.  That might be the
>> issue.
>>
>> > ldd `which clamscan` | grep pthread
>> >libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
>> > (0x7fc1d4f17000)
>>
>> The old version of clamscan is using the 64 bit version.  Presumably
>> you're building the new version also to be 64 bit executables?
>>
>> >> You may need to upgrade the library if the version of libpthread is
>> >> not accepted by the build, otherwise I guess you'll have to tell
>> >> the ClamAV build process where to find the shared object.
>> >
>> > I may need some help on that. Can I assume its looking in
>> > /usr/local, and not in /usr?
>>
>> Maybe there's no need to worry about that.  I've seen cases where the
>> build process looks for a shared object, finds a 32 bit version when
>> it's building for 64 bit, and then complains that it doesn't exist.
>> It does exist, but it's found the one for the wrong architecture and
>> doesn't understand what it's found.  If this is the case here, it's a
>> little disappointing (after the build-up we've had for cmake) that it
>> will get it as badly around its neck as autotools.
>>
>> Do you really need the 32-bit stuff?
>
>I am involved with linuxcnc, and since IRQ latency is much better 
>with the 32 bit kernels, out of 6 machines here, 5 are running machinery
>and are running older 32 bit kernels with the correspondingly smaller 
>stack frame that makes a context switch quite a bit faster.
>I am getting setup to put a 64 bit bullseye on this box, but getting it all
>together will be another week at least.
> 
>> Do you have mixed 32 bit and 64 
>> bit binaries on your system?  If so you're going to run into this kind
>> of thing more or less randomly when you build anything and you might
>> need to dig into it yourself a bit more.  If you don't need the mixed
>> architectures you'd be better off without the 32 bit stuff in there.
>>
>> You could try using the package manage to try to remove the 32 bit
>> version of libpthread.  If it's needed by something it will tell you,
>> and you can take a view on what to do abuot it.
>
>synaptic isn't really advertising the 32 bit stuff, the only libpthread
>that wasn't x86-64 was python-pthread, and nothing squawked when I removed it.
>Now a rerun gets this:
>
>gene@coyote:~/src/clamav-0.104.0-rc/build$ /usr/local/bin/cmake .. -D 
>CMAKE_BUILD_TYPE="Release"
>CMake Error at 
>/usr/local/share/cmake-3.21/Modules/FindPackageHandleStandardArgs.cmake:230 
>(message):
>  Could NOT find Libcheck (missing: LIBCHECK_INCLUDE_DIR LIBCHECK_LIBRARY)
>Call Stack (most recent call first):
>  /usr/local/share/cmake-3.21/Modules/FindPackageHandleStandardArgs.cmake:594 
> (_FPHSA_FAILURE_MESSAGE)
>  cmake/FindLibcheck.cmake:89 (find_package_handle_standard_args)
>  CMakeLists.txt:192 (find_package)
>
>
>-- Configuring incomplete, errors occurred!
>See also "/home/gene/src/clamav-0.104.0-rc/build/CMakeFiles/CMakeOutput.log".
>See also "/home/gene/src/clamav-0.104.0-rc/build/CMakeFiles/CMakeError.log".
>
>Libcheck, its a perl thing that depends on libexporter which several 
>versions, not all of which are installed
>
>CMakeError.log ends with this:
>
>Linking C executable cmTC_38c19
>/usr/local/bin/cmake -E cmake_link_script 

Re: [clamav-users] ClamAV® blog: ClamAV 0.104.0 Release Candidate is here!

[Mark Allan via clamav-users]

Hi Micah,

Apologies for the nerd-swiping!

I'm currently setting up a VM so I can install Mussels and CMake without 
messing up my current build environment - thanks for the commands.

In terms of the install location (--prefix in autotools parlance), I'd be 
inclined to go for '/usr/local' as that tends to be where 3rd party CLI tools 
live. I think '/opt' is just where MacPorts puts stuff, and most people won't 
have that directory. '/usr/local' is supplied in a standard macOS installation, 
and is deliberately hidden from the Finder to avoid being messed with by idle 
hands!

I'll get back to you once I've got the VM set up.

Mark
PS. Would you rather take this off-list?

> On 27 Jul 2021, at 11:25 pm, Micah Snyder (micasnyd)  
> wrote:
>  
> Mark:
>  
> I’m sorry about breaking your scripts. For what it’s worth, all of the 
> dependency builds should stay the same but you’ll have to change the commands 
> for building ClamAV itself.
>  
> One of those reasons why CMake is awesome is that it’s really easy to build 
> installers. Just last week Hanspeter and I figured out how to link ClamAV 
> with a static libcurl build and have it bring along all of libcurl’s 
> dependencies. This was a roadblock for a couple things to include building a 
> PKG installer for macOS. After seeing your comments about Homebrew, and with 
> that roadblock finally removed, you successfully nerd-sniped me into figuring 
> out the rest of the macOS installer build.
>  
> I just finished a pull-request to add support to build a PKG installer for 
> Mac. I would love your input on it: 
> https://github.com/Cisco-Talos/clamav/pull/228 
> 
> Note that I picked an install path /opt/clamav rather arbitrarily.  If we’re 
> going to add a macOS PKG installer to our Downloads page, I’d appreciate 
> input on where you think it should actually install to.
>  
> My example in the PR (and commit message) rely on having used Mussels, our 
> dependency build automation tool, to build all of the static libs 
> (https://github.com/Cisco-Talos/Mussels 
> ).
> We use Mussels to build the dependencies for Windows and for Linux (for 
> OSS-Fuzz). Crafting recipes for static libs for macOS wasn’t so bad. I added 
> those last night. You can review the recipes the “clamav cookbook” uses to 
> build each dependency here: 
> https://github.com/Cisco-Talos/clamav-mussels-cookbook/ 
> 
>  
> If you want to give it a try instead of using your own build tools, the 
> Mussels project page has some basic instructions but for a leg up here are 
> some commands to get you started:
>  
> python3 -m pip install mussels
> msl --help
> msl up
> msl cookbook trust clamav
> msl build --help
> msl build clamav_deps -t host-static --dry-run
> msl build clamav_deps -t host-static 
>  
> I have not yet modified the clamav recipe to build the PKG installer, since 
> the above PR hasn’t merged yet, but “msl build clamav -t host-static” should 
> also work.
>  
> Anyways, please let me know what you think.  
>  
> Respectfully,
> Micah
>  
>  
> From: clamav-users  > On Behalf Of Mark Allan via 
> clamav-users
> Sent: Monday, July 26, 2021 5:27 PM
> To: ClamAV users ML  >
> Cc: Mark Allan mailto:markjal...@gmail.com>>
> Subject: Re: [clamav-users] ClamAV® blog: ClamAV 0.104.0 Release Candidate is 
> here!
>  
> I find myself asking the same question. Just from a personal point of view, 
> I've invested a lot of time over the years creating scripts that pull down 
> dependencies, build & install them in the right order, and then build package 
> and deploy ClamAV. Looks like I'll now have to spend even more time, trying 
> to get my head around making them work with CMakeand for what? What 
> benefit does it bring?
>  
> Of course, I understand that this is your project and you can do whatever you 
> like with it, and that you don't owe us any explanation for doing anything, 
> but it still seems odd to change the whole build process without at least 
> saying what the benefits are.
>  
> ...and don't get me started on the official recommendation to use Homebrew on 
> macOS.
>  
> Regards
> Mark
> 
> 
> On 26 Jul 2021, at 4:35 pm, Rick Cooper  > wrote:
>  
> And what, exactly, is the reason for moving to cmake? I am sure you know it's 
> going to be problematic for thousands of people so I am curious what 
> tremendous gain of speed, size, memory usage or seciurity the other users get 
> from this change, or if it's just a convenience thing for the developers?
>  
>  
>  
> From: clamav-users [mailto:clamav-users-boun...@lists.clamav.net 
> ] On Behalf Of Joel Esler 
> (jesler) via clamav-users
> Sent: Thursday, July 22, 2021 12:19 PM
> To: ClamAV users ML; ClamAV 

Re: [clamav-users] Freshclam - can't apply latest patch 26246

[Andrew C Aitchison via clamav-users]

On Thu, 29 Jul 2021, Asenova, Elia via clamav-users wrote:


Thanks for the replies. Yes, deleting daily.cld fixed the
problem. My concern is that I'm building a docker image with clamav
inside it and I have to delete daily.cld on every new build if I
want freshclam to work correctly the first time. About the
subsequent runs when I tried to run freshclam on two different pods
after image deploy, daily.cld was updated to the latest version only
on one of them. These are the logs for both pods:

#1st pod (successful update):
Connecting via dnat.genesaas.io
ClamAV update process started at Thu Jul 29 08:54:30 2021
daily database available for update (local version: 26231, remote version: 
26246)
Current database is 15 versions behind.
Downloading database patch # 26232...
ERROR: cdiff_apply: lseek(desc, -350, SEEK_END) failed
ERROR: downloadPatch: Can't apply patch
WARNING: Incremental update failed, trying to download daily.cvd
Time:   21.8s, ETA:0.0s [>]   54.95MiB/54.95MiB
Testing database: 
'/var/lib/clamav/tmp.98ba2d17af/clamav-474d295bd3248aa18d6abaf0dc93f952.tmp-daily.cvd'
 ...
Database test passed.
daily.cvd updated (version: 26246, sigs: 1964581, f-level: 90, builder: raynman)
main.cvd database is up-to-date (version: 61, sigs: 6607162, f-level: 90, 
builder: sigmgr)
bytecode.cvd database is up-to-date (version: 333, sigs: 92, f-level: 63, 
builder: awillia2)


Start with daily 26233 (or better whatever is the latest today) and main 61.
By starting with daily 26231 and main 59 you immediately have to do a major
(once in maybe six months) update.

As Matus and Ged have suggested, you should not need to install the 
database on each docker instance.

Unless you have a large anti-virus farm, you don't even need to *run* the
d clam daemon on every VM. Start up a single remote clamd server and the 
other VMs can pass their scans to your clamd server with clamdscan.




2nd pod (unsuccessful update):
Connecting via dnat.genesaas.io
ClamAV update process started at Thu Jul 29 09:14:16 2021
daily database available for update (local version: 26231, remote version: 
26247)
Current database is 16 versions behind.
Downloading database patch # 26232...
ERROR: cdiff_apply: lseek(desc, -350, SEEK_END) failed
ERROR: downloadPatch: Can't apply patch
WARNING: Incremental update failed, trying to download daily.cvd
Time:   26.5s, ETA:0.0s [>]   54.95MiB/54.95MiB
Received an older daily CVD than was advertised. We'll retry so the incremental 
update will ensure we're up-to-date.
daily database available for update (local version: 26231, remote version: 
26247)
Current database is 16 versions behind.
Downloading database patch # 26232...
ERROR: cdiff_apply: lseek(desc, -350, SEEK_END) failed
ERROR: downloadPatch: Can't apply patch
WARNING: Incremental update failed, trying to download daily.cvd
Time:   28.0s, ETA:0.0s [>]   54.95MiB/54.95MiB
Received an older daily CVD than was advertised. We'll retry so the incremental 
update will ensure we're up-to-date.
daily database available for update (local version: 26231, remote version: 
26247)
Current database is 16 versions behind.
Downloading database patch # 26232...
ERROR: cdiff_apply: lseek(desc, -350, SEEK_END) failed
ERROR: downloadPatch: Can't apply patch
WARNING: Incremental update failed, trying to download daily.cvd
Time:   25.5s, ETA:0.0s [>]   54.95MiB/54.95MiB
Received an older daily CVD than was advertised. We'll retry so the incremental 
update will ensure we're up-to-date.
main.cvd database is up-to-date (version: 61, sigs: 6607162, f-level: 90, 
builder: sigmgr)
bytecode.cvd database is up-to-date (version: 333, sigs: 92, f-level: 63, 
builder: awillia2)



What might be the reason of this inconsistent behavior?



From those logs it appears that daily 26247 was advertised between the two runs,

but had't reach the mirror that you downloaded from.



And about the ReceiveTimeout this is what I have in freshclam.conf:
# Maximum time in seconds for each download operation. 0 means no timeout.
# Default: 0
#ReceiveTimeout 1800



So, it should have no timeout, right?


I would add a line
  ReceiveTimeout 0
to be sure. Sometimes the commented out line reflects that actual default.

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk

___

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Re: [clamav-users] Freshclam - can't apply latest patch 26246

[G.W. Haywood via clamav-users]

Hi there,

On Thu, 29 Jul 2021, Asenova, Elia via clamav-users wrote:


... deleting daily.cld fixed the problem.


:)


... I'm building a docker image with clamav inside it ... when I
tried to run freshclam on two different pods after image deploy,
daily.cld was updated to the latest version only on one of them.


In the section in

https://docs.clamav.net/manual/Installing/Docker.html

headed

"The official images on Docker Hub"

there are a couple of suggestions for using ClamAV with Docker.
Did you see those?

I'd have thought the simplest approach would be to have a local ClamAV
database mirror - maybe another Docker container - which could supply
the up-to-date databases to your other containers with no CDN bandwith
issues, and no need to update the container's ClamAV after startup.
It's certainly unreasonable to expect Sourcefire to have to pay for a
fifty megabyte download every time you start a Docker container.


And about the ReceiveTimeout this is what I have in freshclam.conf:

# Maximum time in seconds for each download operation. 0 means no timeout.
# Default: 0
#ReceiveTimeout 1800

So, it should have no timeout, right?


Right.

With regard to logging, have you checked your configurations for the
'LogVerbose' option?  I think Micah meant for you to set that to give
more information about what could potentially be a fault in ClamAV.

I never saw a reply to my question about your computer's clock.  Of
course I understand that there may be other issues, but it appears
that only six minutes separated the log of the failure of freshclam in
your second pod to update, and the timestamp of your mail message...

--

73,
Ged.

___

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Re: [clamav-users] Freshclam - can't apply latest patch 26246

[Matus UHLAR - fantomas]

On 29.07.21 09:20, Asenova, Elia via clamav-users wrote:

Thanks for the replies.  Yes, deleting daily.cld fixed the problem.  My
concern is that I'm building a docker image with clamav inside it and I
have to delete daily.cld on every new build if I want freshclam to work
correctly the first time. 


if you do that often, this behaviour can get you blocked.
maybe running local mirror outside of a docker?

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"Two words: Windows survives." - Craig Mundie, Microsoft senior strategist
"So does syphillis. Good thing we have penicillin." - Matthew Alton

___

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Re: [clamav-users] can't cmake 1.0.4rc

[Gene Heskett via clamav-users]

On Thursday 29 July 2021 03:52:57 G.W. Haywood via clamav-users wrote:

> Hi Gene,
>
> On Wed, 28 Jul 2021, Gene Heskett via clamav-users wrote:
> > On Wednesday 28 July 2021 14:24:46 G.W. Haywood via clamav-users wrote:
> >> On Wed, 28 Jul 2021, Gene Heskett via clamav-users wrote:
> >>> /usr/bin/ld: cannot find -lpthreads
> >>>
> >>> But pthread is installed. "sudo ldconfg -v|grep pthread" comes
> >>> back empty
> >>>
> >>> Now what?
> >>
> >> I'm guessing you have the stable version of ClamAV already
> >> installed on the box, and so clamscan is installed?  Assuming so,
> >> please post the output of ...
> >
> > ls -l `locate libpthread.so`
> > lrwxrwxrwx 1 root root  18 Feb  6  2019 /lib32/libpthread.so.0 ->
> > libpthread-2.24.so lrwxrwxrwx 1 root root  18 Feb  6  2019
> > /lib/x86_64-linux-gnu/libpthread.so.0 -> libpthread-2.24.so
> > -rw-r--r-- 1 root root 252 Feb  6  2019
> > /usr/lib/x86_64-linux-gnu/libpthread.so
> >
> > ldconfig -p | grep pthread
> >libpthread_workqueue.so.0 (libc6,x86-64) =>
> > /usr/lib/x86_64-linux-gnu/libpthread_workqueue.so.0
> > libpthread_workqueue.so (libc6,x86-64) =>
> > /usr/lib/x86_64-linux-gnu/libpthread_workqueue.so libpthread.so.0
> > (libc6,x86-64, OS ABI: Linux 2.6.32) =>
> > /lib/x86_64-linux-gnu/libpthread.so.0 libpthread.so.0 (libc6, OS
> > ABI: Linux 2.6.32) => /lib32/libpthread.so.0
> > libevent_pthreads-2.0.so.5 (libc6,x86-64) =>
> > /usr/lib/x86_64-linux-gnu/libevent_pthreads-2.0.so.5
>
> Ah.  You have both 32 bit and 64 bit versions.  That might be the
> issue.
>
> > ldd `which clamscan` | grep pthread
> >libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> > (0x7fc1d4f17000)
>
> The old version of clamscan is using the 64 bit version.  Presumably
> you're building the new version also to be 64 bit executables?
>
> >> You may need to upgrade the library if the version of libpthread is
> >> not accepted by the build, otherwise I guess you'll have to tell
> >> the ClamAV build process where to find the shared object.
> >
> > I may need some help on that. Can I assume its looking in
> > /usr/local, and not in /usr?
>
> Maybe there's no need to worry about that.  I've seen cases where the
> build process looks for a shared object, finds a 32 bit version when
> it's building for 64 bit, and then complains that it doesn't exist.
> It does exist, but it's found the one for the wrong architecture and
> doesn't understand what it's found.  If this is the case here, it's a
> little disappointing (after the build-up we've had for cmake) that it
> will get it as badly around its neck as autotools.
>
> Do you really need the 32-bit stuff?

I am involved with linuxcnc, and since IRQ latency is much better 
with the 32 bit kernels, out of 6 machines here, 5 are running machinery
and are running older 32 bit kernels with the correspondingly smaller 
stack frame that makes a context switch quite a bit faster.
I am getting setup to put a 64 bit bullseye on this box, but getting it all
together will be another week at least.
 
> Do you have mixed 32 bit and 64 
> bit binaries on your system?  If so you're going to run into this kind
> of thing more or less randomly when you build anything and you might
> need to dig into it yourself a bit more.  If you don't need the mixed
> architectures you'd be better off without the 32 bit stuff in there.
>
> You could try using the package manage to try to remove the 32 bit
> version of libpthread.  If it's needed by something it will tell you,
> and you can take a view on what to do abuot it.

synaptic isn't really advertising the 32 bit stuff, the only libpthread
that wasn't x86-64 was python-pthread, and nothing squawked when I removed it.
Now a rerun gets this:

gene@coyote:~/src/clamav-0.104.0-rc/build$ /usr/local/bin/cmake .. -D 
CMAKE_BUILD_TYPE="Release"
CMake Error at 
/usr/local/share/cmake-3.21/Modules/FindPackageHandleStandardArgs.cmake:230 
(message):
  Could NOT find Libcheck (missing: LIBCHECK_INCLUDE_DIR LIBCHECK_LIBRARY)
Call Stack (most recent call first):
  /usr/local/share/cmake-3.21/Modules/FindPackageHandleStandardArgs.cmake:594 
(_FPHSA_FAILURE_MESSAGE)
  cmake/FindLibcheck.cmake:89 (find_package_handle_standard_args)
  CMakeLists.txt:192 (find_package)


-- Configuring incomplete, errors occurred!
See also "/home/gene/src/clamav-0.104.0-rc/build/CMakeFiles/CMakeOutput.log".
See also "/home/gene/src/clamav-0.104.0-rc/build/CMakeFiles/CMakeError.log".

Libcheck, its a perl thing that depends on libexporter which several 
versions, not all of which are installed

CMakeError.log ends with this:

Linking C executable cmTC_38c19
/usr/local/bin/cmake -E cmake_link_script CMakeFiles/cmTC_38c19.dir/link.txt 
--verbose=1
/usr/bin/cc  -DCHECK_FUNCTION_EXISTS=pthread_create 
CMakeFiles/cmTC_38c19.dir/CheckFunctionExists.c.o -o cmTC_38c19  -lpthreads
/usr/bin/ld: cannot find -lpthreads
collect2: error: ld returned 1 exit status
CMakeFiles/cmTC_38c19.dir/build.make:98: recipe for target 'cmTC_38c19' 

Re: [clamav-users] Freshclam - can't apply latest patch 26246

[Asenova, Elia via clamav-users]

Hello guys,


Thanks for the replies. Yes, deleting daily.cld fixed the problem. My concern 
is that I'm building a docker image with clamav inside it and I have to delete 
daily.cld on every new build if I want freshclam to work correctly the first 
time. About the subsequent runs when I tried to run freshclam on two different 
pods after image deploy, daily.cld was updated to the latest version only on 
one of them. These are the logs for both pods:



#1st pod (successful update):

Connecting via dnat.genesaas.io

ClamAV update process started at Thu Jul 29 08:54:30 2021

daily database available for update (local version: 26231, remote version: 
26246)

Current database is 15 versions behind.

Downloading database patch # 26232...

ERROR: cdiff_apply: lseek(desc, -350, SEEK_END) failed

ERROR: downloadPatch: Can't apply patch

WARNING: Incremental update failed, trying to download daily.cvd

Time:   21.8s, ETA:0.0s [>]   54.95MiB/54.95MiB

Testing database: 
'/var/lib/clamav/tmp.98ba2d17af/clamav-474d295bd3248aa18d6abaf0dc93f952.tmp-daily.cvd'
 ...

Database test passed.

daily.cvd updated (version: 26246, sigs: 1964581, f-level: 90, builder: raynman)

main.cvd database is up-to-date (version: 61, sigs: 6607162, f-level: 90, 
builder: sigmgr)

bytecode.cvd database is up-to-date (version: 333, sigs: 92, f-level: 63, 
builder: awillia2)



2nd pod (unsuccessful update):

Connecting via dnat.genesaas.io

ClamAV update process started at Thu Jul 29 09:14:16 2021

daily database available for update (local version: 26231, remote version: 
26247)

Current database is 16 versions behind.

Downloading database patch # 26232...

ERROR: cdiff_apply: lseek(desc, -350, SEEK_END) failed

ERROR: downloadPatch: Can't apply patch

WARNING: Incremental update failed, trying to download daily.cvd

Time:   26.5s, ETA:0.0s [>]   54.95MiB/54.95MiB

Received an older daily CVD than was advertised. We'll retry so the incremental 
update will ensure we're up-to-date.

daily database available for update (local version: 26231, remote version: 
26247)

Current database is 16 versions behind.

Downloading database patch # 26232...

ERROR: cdiff_apply: lseek(desc, -350, SEEK_END) failed

ERROR: downloadPatch: Can't apply patch

WARNING: Incremental update failed, trying to download daily.cvd

Time:   28.0s, ETA:0.0s [>]   54.95MiB/54.95MiB

Received an older daily CVD than was advertised. We'll retry so the incremental 
update will ensure we're up-to-date.

daily database available for update (local version: 26231, remote version: 
26247)

Current database is 16 versions behind.

Downloading database patch # 26232...

ERROR: cdiff_apply: lseek(desc, -350, SEEK_END) failed

ERROR: downloadPatch: Can't apply patch

WARNING: Incremental update failed, trying to download daily.cvd

Time:   25.5s, ETA:0.0s [>]   54.95MiB/54.95MiB

Received an older daily CVD than was advertised. We'll retry so the incremental 
update will ensure we're up-to-date.

main.cvd database is up-to-date (version: 61, sigs: 6607162, f-level: 90, 
builder: sigmgr)

bytecode.cvd database is up-to-date (version: 333, sigs: 92, f-level: 63, 
builder: awillia2)



What might be the reason of this inconsistent behavior?



And about the ReceiveTimeout this is what I have in freshclam.conf:

# Maximum time in seconds for each download operation. 0 means no timeout.

# Default: 0

#ReceiveTimeout 1800



So, it should have no timeout, right?



Best Regards,

Elia

From: Micah Snyder (micasnyd) 
Sent: Wednesday, July 28, 2021 10:02 PM
To: ClamAV users ML 
Cc: Asenova, Elia ; Solakov, Panayot 

Subject: [EXTERNAL] RE: Freshclam - can't apply latest patch 26246

External email: Do not click the links. Verify legitimacy before taking action.
Hi Elia,

I would need to see the log messages from your subsequent updates to be sure 
what's going wrong. The logs you shared in your initial email show a bug but 
subsequent freshclam runs _should_ work.
If you want, the verbose log may reveal something.

Like Joel suggested, it may be the ReceiveTimeout issue discussed here: 
https://blog.clamav.net/2021/07/psa-freshclam-database-download-issue.html
Regardless, I think that deleting your daily.cld database 
(/var/lib/clamav/daily.cld) and trying again should get you back in business.

Sorry about the trouble.

Regards,
Micah

From: clamav-users 
mailto:clamav-users-boun...@lists.clamav.net>>
 On Behalf Of Asenova, Elia via clamav-users
Sent: Wednesday, July 28, 2021 8:15 AM
To: clamav-users@lists.clamav.net
Cc: Asenova, Elia 
mailto:elia.asen...@experian.com>>; Solakov, Panayot 
mailto:panayot.sola...@experian.com>>
Subject: [clamav-users] 

Re: [clamav-users] can't cmake 1.0.4rc

[G.W. Haywood via clamav-users]

Hi Gene,

On Wed, 28 Jul 2021, Gene Heskett via clamav-users wrote:


On Wednesday 28 July 2021 14:24:46 G.W. Haywood via clamav-users wrote:

On Wed, 28 Jul 2021, Gene Heskett via clamav-users wrote:

/usr/bin/ld: cannot find -lpthreads

But pthread is installed. "sudo ldconfg -v|grep pthread" comes back
empty

Now what?


I'm guessing you have the stable version of ClamAV already installed
on the box, and so clamscan is installed?  Assuming so, please post
the output of ...


ls -l `locate libpthread.so`
lrwxrwxrwx 1 root root  18 Feb  6  2019 /lib32/libpthread.so.0 -> 
libpthread-2.24.so
lrwxrwxrwx 1 root root  18 Feb  6  2019 /lib/x86_64-linux-gnu/libpthread.so.0 
-> libpthread-2.24.so
-rw-r--r-- 1 root root 252 Feb  6  2019 /usr/lib/x86_64-linux-gnu/libpthread.so

ldconfig -p | grep pthread
   libpthread_workqueue.so.0 (libc6,x86-64) => 
/usr/lib/x86_64-linux-gnu/libpthread_workqueue.so.0
   libpthread_workqueue.so (libc6,x86-64) => 
/usr/lib/x86_64-linux-gnu/libpthread_workqueue.so
   libpthread.so.0 (libc6,x86-64, OS ABI: Linux 2.6.32) => 
/lib/x86_64-linux-gnu/libpthread.so.0
   libpthread.so.0 (libc6, OS ABI: Linux 2.6.32) => /lib32/libpthread.so.0
   libevent_pthreads-2.0.so.5 (libc6,x86-64) => 
/usr/lib/x86_64-linux-gnu/libevent_pthreads-2.0.so.5



Ah.  You have both 32 bit and 64 bit versions.  That might be the issue.


ldd `which clamscan` | grep pthread
   libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fc1d4f17000)


The old version of clamscan is using the 64 bit version.  Presumably
you're building the new version also to be 64 bit executables?


You may need to upgrade the library if the version of libpthread is
not accepted by the build, otherwise I guess you'll have to tell the
ClamAV build process where to find the shared object.


I may need some help on that. Can I assume its looking in /usr/local,
and not in /usr?


Maybe there's no need to worry about that.  I've seen cases where the
build process looks for a shared object, finds a 32 bit version when
it's building for 64 bit, and then complains that it doesn't exist.
It does exist, but it's found the one for the wrong architecture and
doesn't understand what it's found.  If this is the case here, it's a
little disappointing (after the build-up we've had for cmake) that it
will get it as badly around its neck as autotools.

Do you really need the 32-bit stuff?  Do you have mixed 32 bit and 64
bit binaries on your system?  If so you're going to run into this kind
of thing more or less randomly when you build anything and you might
need to dig into it yourself a bit more.  If you don't need the mixed
architectures you'd be better off without the 32 bit stuff in there.

You could try using the package manage to try to remove the 32 bit
version of libpthread.  If it's needed by something it will tell you,
and you can take a view on what to do abuot it.

--

73,
Ged.




___

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

[clamav-users] ClamAV 0.104.0 Release Candidate with CMake required!

[Avram-Teodor Berindeie]

ClamAV 0.104.0 Release Candidate has been compiled without any problems and
works properly in Slackware64-current (development tree for upcoming
versions of Slackware -> 15.0).
The transition from Autotools to CMake took a few minutes until I managed
to choose my compilation options (I have been compiling ClamAV from sources
over 10 years in Slackware).
I consider that switching to CMake is a good choice, I hope you add support
for the new versions of LLVM as soon as possible and continue the
development of antivirus.
I have used (for many years) Sophos Antivirus for Linux + SAV Dynamic
Interface (SAVDI) and ClamAV for mail server protection but after the
withdrawal of the free version for Sophos Antivirus for Linux and
management through Sophos Central for the paid version (change that I do
not like ) I have to give up Sophos and rely only on ClamAV.

___

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml