Mailing List Archive

> While I applaud the re-use of existing components, requiring this
> (minimum) version of libcurl will be a problem for redhat/centOS 7
> users: everybody is still on RHEL7 (RHEL8 is "just" released and still
> lacks support from many vendors).
> In RHEL/Centos, clamav is only packaged in EPEL, and EPEL packages
> will never include packages that the base OS also provides (in this
> case libcurl + libssh2 as a dependancy). This would mean that 0.102
> will never be available in RHEL7 (that is here until 2024).
> So, maybe a solution could be to include libcurl in the clam distro
> itself and build/use a static lib version of that (and not a shared
> .so) in case the OS-version of libcurl is not sufficient? If not, EPEL
> will never create an rpm for clamav 0.102, and that would leave a lot
> of existing users "in the cold" and force them into using an "old"
> version.

Franky,

As has been stated numerous times, the minimum requirement for curl is
ONLY to build with the OPTIONAL argument for on-access scanning.

The ClamAV team is not responsible for 3rd party packages, if you want
a static libcurl built you would need to contact the PACKAGE
MAINTAINER. Which for RHEL appears to be a couple people.

Look at the changelog:
https://centos.pkgs.org/7/epel-x86_64/clamav-0.101.4-1.el7.x86_64.rpm.html

Sure, it can be done.... for RHEL 6 they built a static version of
zlib in the ClamAV package due to a bug with the OS version. But it is
up to YOU to tell THEM... i.e. on Redhat's Bugzilla... Alternatively
now that you know exactly what feature is being used, instead of
building a full static version with clamav, you could request that
feature be backported into the existing curl package (as a different
route to achieve the same end-goal)...

Additionally, you *can* install the latest Curl from a 3rd party repo:

https://mirror.city-fan.org/ftp/contrib/sysutils/Mirroring/

And if you want to add the repo to yum:

http://www.city-fan.org/ftp/contrib/yum-repo/

Ironic you are complaining about not getting a new version, when
almost all packages in a RHEL distro are frozen versions (ex: curl)
and merely receive backported bug fixes and features...

It's not hard to update curl, I already did it on my EL6 system. I
haven't updated ClamAV yet, I'm waiting for the stable release.

_______________________________________________

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

Op Maandag, 30-09-2019 om 15:14 schreef J.R. via clamav-users:
> > While I applaud the re-use of existing components, requiring this
> > (minimum) version of libcurl will be a problem for redhat/centOS 7
> > users: everybody is still on RHEL7 (RHEL8 is "just" released and still
> > lacks support from many vendors).
> > In RHEL/Centos, clamav is only packaged in EPEL, and EPEL packages
> > will never include packages that the base OS also provides (in this
> > case libcurl + libssh2 as a dependancy). This would mean that 0.102
> > will never be available in RHEL7 (that is here until 2024).
> > So, maybe a solution could be to include libcurl in the clam distro
> > itself and build/use a static lib version of that (and not a shared
> > .so) in case the OS-version of libcurl is not sufficient? If not, EPEL
> > will never create an rpm for clamav 0.102, and that would leave a lot
> > of existing users "in the cold" and force them into using an "old"
> > version.
>
> Franky,
>
> As has been stated numerous times, the minimum requirement for curl is
> ONLY to build with the OPTIONAL argument for on-access scanning.
>
> The ClamAV team is not responsible for 3rd party packages, if you want
> a static libcurl built you would need to contact the PACKAGE
> MAINTAINER. Which for RHEL appears to be a couple people.
>
> Look at the changelog:
> https://centos.pkgs.org/7/epel-x86_64/clamav-0.101.4-1.el7.x86_64.rpm.html
>
> Sure, it can be done.... for RHEL 6 they built a static version of
> zlib in the ClamAV package due to a bug with the OS version. But it is
> up to YOU to tell THEM... i.e. on Redhat's Bugzilla... Alternatively
> now that you know exactly what feature is being used, instead of
> building a full static version with clamav, you could request that
> feature be backported into the existing curl package (as a different
> route to achieve the same end-goal)...
>
> Additionally, you *can* install the latest Curl from a 3rd party repo:
>
> https://mirror.city-fan.org/ftp/contrib/sysutils/Mirroring/
>
> And if you want to add the repo to yum:
>
> http://www.city-fan.org/ftp/contrib/yum-repo/
>
> Ironic you are complaining about not getting a new version, when
> almost all packages in a RHEL distro are frozen versions (ex: curl)
> and merely receive backported bug fixes and features...
>
> It's not hard to update curl, I already did it on my EL6 system. I
> haven't updated ClamAV yet, I'm waiting for the stable release.

I think you misunderstand me, I'm merely stating a fact here. Epel won't do anything about libcurl, and redhat won't just backport new features "because of". Even so, backport requests take a long time at redhat. Maybe the epel guys will include a static version of libcurl for clamav, I hope so.
I do know that this requirement is for clamonacc, that's just the feature I'm interested in.
Of course I know how to replace libcurl (I already did it and built clamav myself), but clamav packages would need to be done/provided/maintained by a recommended third-party (like epel) for the company I'm currently working at (maintaining own rpms is fine and I could even do it myself if clamav would provide/maintain a spec-file).

An extra thing is that the blog article states "This is only relevant if you are installing from source", so I hope that all this is just a non-issue (I'll need to rebuild myself later today again to verify).

Franky

F.

_______________________________________________

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

Op Maandag, 30-09-2019 om 15:27 schreef Franky Van Liedekerke via clamav-users:
> Op Maandag, 30-09-2019 om 15:14 schreef J.R. via clamav-users:
> > > While I applaud the re-use of existing components, requiring this
> > > (minimum) version of libcurl will be a problem for redhat/centOS 7
> > > users: everybody is still on RHEL7 (RHEL8 is "just" released and still
> > > lacks support from many vendors).
> > > In RHEL/Centos, clamav is only packaged in EPEL, and EPEL packages
> > > will never include packages that the base OS also provides (in this
> > > case libcurl + libssh2 as a dependancy). This would mean that 0.102
> > > will never be available in RHEL7 (that is here until 2024).
> > > So, maybe a solution could be to include libcurl in the clam distro
> > > itself and build/use a static lib version of that (and not a shared
> > > .so) in case the OS-version of libcurl is not sufficient? If not, EPEL
> > > will never create an rpm for clamav 0.102, and that would leave a lot
> > > of existing users "in the cold" and force them into using an "old"
> > > version.
> >
> > Franky,
> >
> > As has been stated numerous times, the minimum requirement for curl is
> > ONLY to build with the OPTIONAL argument for on-access scanning.
> >
> > The ClamAV team is not responsible for 3rd party packages, if you want
> > a static libcurl built you would need to contact the PACKAGE
> > MAINTAINER. Which for RHEL appears to be a couple people.
> >
> > Look at the changelog:
> > https://centos.pkgs.org/7/epel-x86_64/clamav-0.101.4-1.el7.x86_64.rpm.html
> >
> > Sure, it can be done.... for RHEL 6 they built a static version of
> > zlib in the ClamAV package due to a bug with the OS version. But it is
> > up to YOU to tell THEM... i.e. on Redhat's Bugzilla... Alternatively
> > now that you know exactly what feature is being used, instead of
> > building a full static version with clamav, you could request that
> > feature be backported into the existing curl package (as a different
> > route to achieve the same end-goal)...
> >
> > Additionally, you *can* install the latest Curl from a 3rd party repo:
> >
> > https://mirror.city-fan.org/ftp/contrib/sysutils/Mirroring/
> >
> > And if you want to add the repo to yum:
> >
> > http://www.city-fan.org/ftp/contrib/yum-repo/
> >
> > Ironic you are complaining about not getting a new version, when
> > almost all packages in a RHEL distro are frozen versions (ex: curl)
> > and merely receive backported bug fixes and features...
> >
> > It's not hard to update curl, I already did it on my EL6 system. I
> > haven't updated ClamAV yet, I'm waiting for the stable release.
>
> I think you misunderstand me, I'm merely stating a fact here. Epel won't do anything about libcurl, and redhat won't just backport new features "because of". Even so, backport requests take a long time at redhat. Maybe the epel guys will include a static version of libcurl for clamav, I hope so.
> I do know that this requirement is for clamonacc, that's just the feature I'm interested in.
> Of course I know how to replace libcurl (I already did it and built clamav myself), but clamav packages would need to be done/provided/maintained by a recommended third-party (like epel) for the company I'm currently working at (maintaining own rpms is fine and I could even do it myself if clamav would provide/maintain a spec-file).
>
> An extra thing is that the blog article states "This is only relevant if you are installing from source", so I hope that all this is just a non-issue (I'll need to rebuild myself later today again to verify).

To continue this: it is not only relevant if installing from source, the clamonacc binary currently indeed needs the newer libcurl library (so just copying the resulting clam binaries to another server would not be sufficient).

Franky

_______________________________________________

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

> I think you misunderstand me, I'm merely stating a fact here.
> Epel won't do anything about libcurl, and redhat won't just backport new
> features "because of". Even so, backport requests take a long time at redhat.
> Maybe the epel guys will include a static version of libcurl for clamav, I hope so.
> I do know that this requirement is for clamonacc, that's just the feature I'm interested in.
> Of course I know how to replace libcurl (I already did it and built clamav myself),
> but clamav packages would need to be done/provided/maintained by a recommended
> third-party (like epel) for the company I'm currently working at (maintaining own
> rpms is fine and I could even do it myself if clamav would provide/maintain a spec-file).

Well, then I guess we could all just sit around waiting another 10
years for an eventual Redhat release that uses a semi-modern version
of libcurl... *rolleyes*

It's a double-edge sword... You can use legacy code for so long, but
then as the OS become more modern, backwards compatibility is only
maintained for so long. Or you can use more modern code, and leave
behind the legacy systems (or at least the systems that choose to use
legacy libraries)... Chicken & the egg... one has to come first before
the other will follow... Sorry you don't get the latest & greatest
features, but that's the trade-off on Enterprise vs Fedora.

As mentioned before, take a look at the EL 6 ClamAV source RPM... It
has zlib building and compiled in statically... You can use that as a
TEMPLATE and build curl statically too, and specify that source when
it builds clamav for your EL 7 system ... Not rocket science...

ClamAV releases are not *that* often... Simply being on the mailing
list is enough to get the announcements when they are released. Often
building a new version is simply replacing the source tar.gz and
firing off rpmbuild...

ClamAV isn't responsible for maintaining spec files, those are
DISTRO-SPECIFIC... Imagine if they were supposed to maintain packages
for every distro out there... That would basically bring development
to a grinding halt...

Grab the last ClamAV .src.rpm for your OS... replace the source
.tar.gz with the version you want, update version number, check if any
.patch files are still relevant or not, and give it the good old
'rpmbuild -ba --clean clamav.spec' and cross your fingers you get a
successful build... It might take a few tries if there are any new
files that have to be added to the files list. That's the great thing
about OPEN SOURCE... If you don't like how someone else is doing
something, you can take that source and modify and build it however it
suits YOU....

Depending on how many machines you have, this could be an excuse at
work to start your own local REPO for custom packages tailored to your
BUSINESS NEEDS...

> To continue this: it is not only relevant if installing from source, the clamonacc
> binary currently indeed needs the newer libcurl library (so just copying the
> resulting clam binaries to another server would not be sufficient).

Because RHEL (and many other distros) use dynamic libraries... That's
why I said above you could build your own version of curl in with
clamav, leaving the system's version intact...


Sorry if I sound grouchy... Still drinking my coffee this morning...

_______________________________________________

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

On Oct 1, 2019, at 10:29 AM, J.R. via clamav-users <clamav-users@lists.clamav.net<mailto:clamav-users@lists.clamav.net>> wrote:

ClamAV isn't responsible for maintaining spec files, those are
DISTRO-SPECIFIC... Imagine if they were supposed to maintain packages
for every distro out there... That would basically bring development
to a grinding halt...

ClamAV can't also wait for distros to get their lives together. Security software has to move forward.

--
Joel Esler
Manager, Communities Division
Cisco Talos Intelligence Group
http://www.talosintelligence.com

Not wanting to appear stuipid but exactly what important security feature
does the new lincurl include that is so important to moving clamav forward?


Rick

_____

From: clamav-users [mailto:clamav-users-bounces@lists.clamav.net] On Behalf
Of Joel Esler (jesler) via clamav-users
Sent: Tuesday, October 01, 2019 11:00 AM
To: ClamAV users ML
Cc: Joel Esler (jesler); J.R.
Subject: Re: [clamav-users] [Clamav-devel] ClamAV(R) blog: ClamAV 0.102.0
Release Candidate is now available





On Oct 1, 2019, at 10:29 AM, J.R. via clamav-users
<clamav-users@lists.clamav.net> wrote:

ClamAV isn't responsible for maintaining spec files, those are
DISTRO-SPECIFIC... Imagine if they were supposed to maintain packages
for every distro out there... That would basically bring development
to a grinding halt...


ClamAV can't also wait for distros to get their lives together. Security
software has to move forward.

--
Joel Esler
Manager, Communities Division
Cisco Talos Intelligence Group
http://www.talosintelligence.com

Ssl interaction with mirrors and ClamAV.net.

Sent from my ? iPhone

> On Oct 2, 2019, at 16:42, Rick Cooper <rcooper@dwford.com> wrote:
>
> ?
> Not wanting to appear stuipid but exactly what important security feature does the new lincurl include that is so important to moving clamav forward?
>
>
> Rick
>
> From: clamav-users [mailto:clamav-users-bounces@lists.clamav.net] On Behalf Of Joel Esler (jesler) via clamav-users
> Sent: Tuesday, October 01, 2019 11:00 AM
> To: ClamAV users ML
> Cc: Joel Esler (jesler); J.R.
> Subject: Re: [clamav-users] [Clamav-devel] ClamAV(R) blog: ClamAV 0.102.0 Release Candidate is now available
>
>
>
>> On Oct 1, 2019, at 10:29 AM, J.R. via clamav-users <clamav-users@lists.clamav.net> wrote:
>>
>> ClamAV isn't responsible for maintaining spec files, those are
>> DISTRO-SPECIFIC... Imagine if they were supposed to maintain packages
>> for every distro out there... That would basically bring development
>> to a grinding halt...
>
> ClamAV can't also wait for distros to get their lives together. Security software has to move forward.
>
> --
> Joel Esler
> Manager, Communities Division
> Cisco Talos Intelligence Group
> http://www.talosintelligence.com
>
> _______________________________________________
>
> 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

> Not wanting to appear stuipid but exactly what important security feature
> does the new lincurl include that is so important to moving clamav forward?

Shamelessly ripped from Micah's post the other week:

Unlike clamdscan, which has the network socket code written by hand,
clamonacc depends on libcurl for all of its network code to
communicate with clamd.

The specific feature that we used which bumps the libcurl version
requirement to 7.45.0 is "CURLINFO_ACTIVESOCKET".
See https://curl.haxx.se/libcurl/c/CURLINFO_ACTIVESOCKET.html for details.

_______________________________________________

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

Does this obsolete earlier versions of ClamAV?

dp

On 10/2/19 2:20 PM, Joel Esler (jesler) via clamav-users wrote:
> Ssl interaction with mirrors and ClamAV.net.
>
> Sent from my ? iPhone
>
>> On Oct 2, 2019, at 16:42, Rick Cooper <rcooper@dwford.com> wrote:
>>
>> ?
>> Not wanting to appear stuipid but exactly what important security feature
>> does the new lincurl include that is so important to moving clamav forward?

On 03.10.19 11:05, Dennis Peterson wrote:
>Does this obsolete earlier versions of ClamAV?

depending on what you exactly mean by obsoleting.
older versions will work and will be supported for some time.
but freshclam will warn about newer version available.

if you have installed clamav via any OS/distribution, you usually can trust
them to provide newer version soon.

>On 10/2/19 2:20 PM, Joel Esler (jesler) via clamav-users wrote:
>>Ssl interaction with mirrors and ClamAV.net.
>>
>>Sent from my ? iPhone
>>
>>>On Oct 2, 2019, at 16:42, Rick Cooper <rcooper@dwford.com> wrote:
>>>
>>>?
>>>Not wanting to appear stuipid but exactly what important security
>>>feature does the new lincurl include that is so important to
>>>moving clamav forward?

--
Matus UHLAR - fantomas, uhlar@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.
I drive way too fast to worry about cholesterol.

_______________________________________________

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

Hi there,

On Fri, 4 Oct 2019, Matus UHLAR - fantomas wrote:

> On 03.10.19 11:05, Dennis Peterson wrote:
>> Does this obsolete earlier versions of ClamAV?
>
> depending on what you exactly mean by obsoleting.
> older versions will work and will be supported for some time.
> but freshclam will warn about newer version available.
>
> if you have installed clamav via any OS/distribution, you usually can trust
> them to provide newer version soon.

In case it's of any interest:

For several weeks I ran a mix of three versions of clamd, from both
0.101.4, and 0.102rc side-by-side, all on the same machine, with no
problems (other than that obviously they're a little picky about
library versions). They all used the same set of databases, updated
by a single freshclam instance. A milter piped the mail to all three
clamd instances concurrently, and in this usage I saw no evidence of
any differences in their performance.

--

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

This particular hard requirement (libcurl) affects the communication channel
which is different than causing the code to fail to run at all. So the question
is do the new libcurl requirements immediately break existing systems that are
not yet updated with new libcurl functionality. It is kind of a big deal to
update a widely used library and creates knock-on problems from ripple effect
for production systems subject to strong configuration management policies.

dp

On 10/4/19 7:22 AM, G.W. Haywood via clamav-users wrote:
> Hi there,
>
> On Fri, 4 Oct 2019, Matus UHLAR - fantomas wrote:
>
>> On 03.10.19 11:05, Dennis Peterson wrote:
>>> Does this obsolete earlier versions of ClamAV?
>>
>> depending on what you exactly mean by obsoleting.
>> older versions will work and will be supported for some time.
>> but freshclam will warn about newer version available.
>>
>> if you have installed clamav via any OS/distribution, you usually can trust
>> them to provide newer version soon.
>
> In case it's of any interest:
>
> For several weeks I ran a mix of three versions of clamd, from both
> 0.101.4, and 0.102rc side-by-side, all on the same machine, with no
> problems (other than that obviously they're a little picky about
> library versions).  They all used the same set of databases, updated
> by a single freshclam instance.  A milter piped the mail to all three
> clamd instances concurrently, and in this usage I saw no evidence of
> any differences in their performance.
>


_______________________________________________

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

This is super critical to the future of where ClamAV is headed. So, while I understand it’s a pain in the butt, we need to work out, as a community, maybe with an faq page contributed by all of us, how to get past this hurdle.

Sent from my ? iPhone

> On Oct 5, 2019, at 09:41, Dennis Peterson <dennispe@inetnw.com> wrote:
>
> ?This particular hard requirement (libcurl) affects the communication channel which is different than causing the code to fail to run at all. So the question is do the new libcurl requirements immediately break existing systems that are not yet updated with new libcurl functionality. It is kind of a big deal to update a widely used library and creates knock-on problems from ripple effect for production systems subject to strong configuration management policies.
>
> dp
>
>> On 10/4/19 7:22 AM, G.W. Haywood via clamav-users wrote:
>> Hi there,
>>
>>> On Fri, 4 Oct 2019, Matus UHLAR - fantomas wrote:
>>>
>>> On 03.10.19 11:05, Dennis Peterson wrote:
>>>> Does this obsolete earlier versions of ClamAV?
>>>
>>> depending on what you exactly mean by obsoleting.
>>> older versions will work and will be supported for some time.
>>> but freshclam will warn about newer version available.
>>>
>>> if you have installed clamav via any OS/distribution, you usually can trust
>>> them to provide newer version soon.
>>
>> In case it's of any interest:
>>
>> For several weeks I ran a mix of three versions of clamd, from both
>> 0.101.4, and 0.102rc side-by-side, all on the same machine, with no
>> problems (other than that obviously they're a little picky about
>> library versions). They all used the same set of databases, updated
>> by a single freshclam instance. A milter piped the mail to all three
>> clamd instances concurrently, and in this usage I saw no evidence of
>> any differences in their performance.
>>
>
>
> _______________________________________________
>
> 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

Hi there,

On Sat, 5 Oct 2019, Dennis Peterson wrote:

> This particular hard requirement (libcurl) affects the communication channel
> which is different than causing the code to fail to run at all. So the
> question is do the new libcurl requirements immediately break existing
> systems that are not yet updated with new libcurl functionality. ...

Sorry, I thought I'd explained in an earlier post. I'm using libcurl v7.38.
So that I didn't need to update libcurl to v7.45 for clamonacc, I disabled it:

8<----------------------------------------------------------------------
$ curl -V
curl 7.38.0 (x86_64-pc-linux-gnu) libcurl/7.38.0 OpenSSL[...snip,snip...]
8<----------------------------------------------------------------------
$ head -7 ~/src/net/mail/clamav-devel-dev-0.102/config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by ClamAV configure 0.102.0-rc, which was
generated by GNU Autoconf 2.69. Invocation command line was

$ ./configure --disable-clamonacc
8<----------------------------------------------------------------------
$ ps axufwww | grep freshclam | grep -v grep
clamav 14105 0.5 0.0 193092 13080 ? Ss Oct04 7:24 \
/usr/local/bin/freshclam -d --config-file=/etc/mail/clamav/freshclam.conf
8<----------------------------------------------------------------------
$ freshclam -V --config-file /etc/mail/freshclam.conf
ClamAV 0.102.0-rc/25593/Sat Oct 5 09:30:21 2019
8<----------------------------------------------------------------------
$ ls -l /var/lib/clamav/daily.cld
-rw-r--r-- 1 clamav clamav 147439104 Oct 5 10:44 /var/lib/clamav/daily.cld
8<----------------------------------------------------------------------

> It is kind of a big deal to update a widely used library and creates
> knock-on problems from ripple effect for production systems subject
> to strong configuration management policies.

Not to mention publishing 0.102 with changes from 0.102rc which break 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

Hi there,

On Sat, 5 Oct 2019, Joel Esler (jesler) via clamav-users wrote:

> ... maybe with an faq page contributed by all of us ...

Do safebrowsing.cdiff files *have* to be 20 megabytes? That's more
than a quarter of the safebrowsing file size. Seems like something
isn't quite right. Incrementally creeping timeouts is bad news, and
the freshclam download timeout now seems to be an order of magnitude
bigger than it was a few years ago.

--

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

> This particular hard requirement (libcurl) affects the communication channel
> which is different than causing the code to fail to run at all. So the question
> is do the new libcurl requirements immediately break existing systems that are
> not yet updated with new libcurl functionality. It is kind of a big deal to
> update a widely used library and creates knock-on problems from ripple effect
> for production systems subject to strong configuration management policies.

It's only a requirement for a new feature...

I suppose the alternative is for distros to do their usual
back-porting of exploits only and freeze the release number? That's
the *usual* route for distro packages instead of constantly updating
and getting the latest & greatest new release and newest features...
*rolleyes*

It *is* an open-source project (i.e. FREE)... If you don't like how
they are doing something you *can* take the code and do whatever you
please with it to suit your needs...

_______________________________________________

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

Op Maandag, 07-10-2019 om 14:18 schreef J.R. via clamav-users:
> > This particular hard requirement (libcurl) affects the communication channel
> > which is different than causing the code to fail to run at all. So the question
> > is do the new libcurl requirements immediately break existing systems that are
> > not yet updated with new libcurl functionality. It is kind of a big deal to
> > update a widely used library and creates knock-on problems from ripple effect
> > for production systems subject to strong configuration management policies.
>
> It's only a requirement for a new feature...
>

I'd like to disagree here: it is a new implementation for an existing feature (on-access scanning).
There was already a remark in a redhat bugzilla request to disable on-access for the epel-build for 0.102 (on which I commented, since that would impact a lot of users).
I won't go into the discussion of supporting "old" libraries on "old OS's" again, but for enterprise users (RHEL 6/7, Centos, Ubuntu LTS, ...) this is a bit of a problem (since the libcurl lib is also provided by the OS vendor itself).

Franky

_______________________________________________

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

Perhaps there is something we can do to make it easier to statically link libcurl, specifically, with freshclam, clamsubmit, and clamonacc.

Regards,
Micah

?On 10/7/19, 9:22 AM, "clamav-users on behalf of Franky Van Liedekerke via clamav-users" <clamav-users-bounces@lists.clamav.net on behalf of clamav-users@lists.clamav.net> wrote:

Op Maandag, 07-10-2019 om 14:18 schreef J.R. via clamav-users:
> > This particular hard requirement (libcurl) affects the communication channel
> > which is different than causing the code to fail to run at all. So the question
> > is do the new libcurl requirements immediately break existing systems that are
> > not yet updated with new libcurl functionality. It is kind of a big deal to
> > update a widely used library and creates knock-on problems from ripple effect
> > for production systems subject to strong configuration management policies.
>
> It's only a requirement for a new feature...
>

I'd like to disagree here: it is a new implementation for an existing feature (on-access scanning).
There was already a remark in a redhat bugzilla request to disable on-access for the epel-build for 0.102 (on which I commented, since that would impact a lot of users).
I won't go into the discussion of supporting "old" libraries on "old OS's" again, but for enterprise users (RHEL 6/7, Centos, Ubuntu LTS, ...) this is a bit of a problem (since the libcurl lib is also provided by the OS vendor itself).

Franky

_______________________________________________

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 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

Ged, all,

My apologies. We should have done a second release candidate after the configure changes.

Fortunately, and very intentionally, 0.102 doesn’t include any security related bug fixes in case there were users who wouldn't be able to update due to some unforeseen issue. The next time we publish a patch release, we will also backport the security-related patches to 0.101 (i.e. simultaneously publish 0.101.5).

I think it should be no surprise that distributions that wish to support new versions of some software, but not new versions of libraries, will have issues such as this. I think static linking is the natural solution for this kind of policy mix. Yes it's harder to maintain, because a vuln-fix in the statically linked library requires an update to the application. I don't know of a better solution though.

-Micah


?On 10/5/19, 12:11 PM, "clamav-users on behalf of G.W. Haywood via clamav-users" <clamav-users-bounces@lists.clamav.net on behalf of clamav-users@lists.clamav.net> wrote:

Hi there,

On Sat, 5 Oct 2019, Dennis Peterson wrote:

> This particular hard requirement (libcurl) affects the communication channel
> which is different than causing the code to fail to run at all. So the
> question is do the new libcurl requirements immediately break existing
> systems that are not yet updated with new libcurl functionality. ...

Sorry, I thought I'd explained in an earlier post. I'm using libcurl v7.38.
So that I didn't need to update libcurl to v7.45 for clamonacc, I disabled it:

8<----------------------------------------------------------------------
$ curl -V
curl 7.38.0 (x86_64-pc-linux-gnu) libcurl/7.38.0 OpenSSL[...snip,snip...]
8<----------------------------------------------------------------------
$ head -7 ~/src/net/mail/clamav-devel-dev-0.102/config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by ClamAV configure 0.102.0-rc, which was
generated by GNU Autoconf 2.69. Invocation command line was

$ ./configure --disable-clamonacc
8<----------------------------------------------------------------------
$ ps axufwww | grep freshclam | grep -v grep
clamav 14105 0.5 0.0 193092 13080 ? Ss Oct04 7:24 \
/usr/local/bin/freshclam -d --config-file=/etc/mail/clamav/freshclam.conf
8<----------------------------------------------------------------------
$ freshclam -V --config-file /etc/mail/freshclam.conf
ClamAV 0.102.0-rc/25593/Sat Oct 5 09:30:21 2019
8<----------------------------------------------------------------------
$ ls -l /var/lib/clamav/daily.cld
-rw-r--r-- 1 clamav clamav 147439104 Oct 5 10:44 /var/lib/clamav/daily.cld
8<----------------------------------------------------------------------

> It is kind of a big deal to update a widely used library and creates
> knock-on problems from ripple effect for production systems subject
> to strong configuration management policies.

Not to mention publishing 0.102 with changes from 0.102rc which break 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 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

I'm always willing to test. However, I don't think freshclam and
clamsubmit need newer libcurl versions, so I guess - if changes are
need - that only clamonacc needs to be reviewed (for the linking
part).

With friendly regards,
Franky

Op Maandag, 07-10-2019 om 16:08 schreef Micah Snyder (micasnyd):


Perhaps there is something we can do to make it easier to statically
link libcurl, specifically, with freshclam, clamsubmit, and clamonacc.

Regards,
Micah

?On 10/7/19, 9:22 AM, "clamav-users on behalf of Franky Van
Liedekerke via clamav-users" wrote:

    Op Maandag, 07-10-2019 om 14:18 schreef J.R. via clamav-users:
    > > This particular hard requirement (libcurl) affects the
communication channel
    > > which is different than causing the code to fail to run at
all. So the question
    > > is do the new libcurl requirements immediately break
existing systems that are
    > > not yet updated with new libcurl functionality. It is kind
of a big deal to
    > > update a widely used library and creates knock-on problems
from ripple effect
    > > for production systems subject to strong configuration
management policies.
    >
    > It's only a requirement for a new feature...
    >
    
    I'd like to disagree here: it is a new implementation for an
existing feature (on-access scanning).
    There was already a remark in a redhat bugzilla request to
disable on-access for the epel-build for 0.102 (on which I commented,
since that would impact a lot of users).
    I won't go into the discussion of supporting "old" libraries
on "old OS's" again, but for enterprise users (RHEL 6/7, Centos,
Ubuntu LTS, ...) this is a bit of a problem (since the libcurl lib is
also provided by the OS vendor itself).
    
    Franky
    
    _______________________________________________
    
    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
    

> Franky Van Liedekerke
> I won't go into the discussion of supporting "old" libraries on "old OS's" again,
> but for enterprise users (RHEL 6/7, Centos, Ubuntu LTS, ...) this is a bit of a problem

> Micah Snyder:
> Perhaps there is something we can do to make it easier to statically link libcurl,
> specifically, with freshclam, clamsubmit, and clamonacc.

As I've said several times already, take a look at the EXISTING EL 6
RPM (and likely several fedora's)... You will discover that a newer
zlib is included and built statically (due to an existing bug with the
distro's version)...

https://download-ib01.fedoraproject.org/pub/epel/6/SRPMS/Packages/c/clamav-0.100.3-1.el6.src.rpm

I haven't tested personally, but you *should* be able to do the exact
same thing with a newer version of CURL, as there is the clamav
configure option: --with-libcurl[=DIR]

Build it, test it, submit the patches to bugzilla, and then you can
have your on-access scanner that is part of the official distro.

Otherwise, like I said before, it would be likely that the enterprise
versions will continue along the .100 / .101 branch and merely
back-port any security vulnerabilities like *most* packages on the
OS...

_______________________________________________

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