All is ok now
thanks a lot
Stan
Le 08/03/2017 à 22:19, Al Varnell a écrit :
The problem was fixed by the very next signature update (daily - 23162), seven
hours after 23161 was released.
-Al-
On Wed, Mar 08, 2017 at 12:35 PM, Stanislas LEVEAU wrote:
Hi,
You known when this build is ok f
The problem was fixed by the very next signature update (daily - 23162), seven
hours after 23161 was released.
-Al-
On Wed, Mar 08, 2017 at 12:35 PM, Stanislas LEVEAU wrote:
>
> Hi,
>
> You known when this build is ok for pcre libraries older than 7.0?
>
> Thanks for your help.
>
> Regards.
Hi,
You known when this build is ok for pcre libraries older than 7.0?
Thanks for your help.
Regards.
Stan
Le 03/03/2017 à 22:00, Alain Zidouemba a écrit :
We are coming to the same conclusions.
The issue seem to isolated to using pcre libraries older than 7.0. I does
not affect users of n
On 3/3/17, 2:14 PM, "clamav-users on behalf of Steven Morgan"
wrote:
Hi Aaron and Leonardo,
What are the versions of libpcre on your systems?
Thanks,
Steve
___
clamav-users mailing list
clamav-users@lists.clamav.n
This is why user base feedback is important.
Regarding lack of detection, this is something I'm having a hard time agreeing
with. We are producing more detection now than we ever have and faster. That's
a tricky think about detection. Detection is only as good as the last thing
missed.
--
I didn't see any problems on CentOS 7 or CentOS 6 on my systems using
clamav with the 23161 daily update. Are you saying you had a problem with
them? The only problem was with CentOS 5 on my systems. The workaround
would apply to any distribution though that was affected by the regexp not
workin
On 3/5/2017 6:51 AM, Joel Esler (jesler) wrote:
> The question here is, do we strive to make a package that is installable on
> more machines, (even ones that are going EOL?), or do we strive to make a
> package that is the best for security?
>
It's my understanding that the new features in pcr
Adam Gibson skrev den 2017-03-05 16:29:
This whitelists those patterns so they do not even get processed to
cause
the crash in the regexp engine that clamd uses. Clamd started up fine
for
me with CentOS 5 after doing that.
did you test that this is same problem in centos 7 ?
come on :=)
y
I build Linux ClamAV from source, mainly due to distro maintainers
being (quite) behind the latest official ClamAV. Also, I build ClamAV
into /opt, so I can keep previous versions just in case.
On Sun, 5 Mar 2017 12:51:04 +
"Joel Esler (jesler)" wrote:
> The question here is, do we strive t
I had email domain issues which kept me from posting this the day of the
problem unfortunately so this info is just for future reference I guess.
If a problem like this comes up again, I found that you can create a
whitelist file to ignore some signatures.
I put the following file in the virus da
Am 05.03.2017 um 14:07 schrieb Carlos Velasco:
Another option would be to include a "static" internal version of pcre in
ClamAV. Although this option I like much less...
this is not a good option because you have easily multiple versions of
the pcre library in the same process when somethin
El 05/03/2017 a las 13:51, Joel Esler (jesler) escribió:
> The question here is, do we strive to make a package that is installable on
> more machines, (even ones that are going EOL?), or do we strive to make a
> package that is the best for security?
>
> If the package maintainers are doing a g
Em 04/03/17 22:03, Reindl Harald escreveu:
Am 04.03.2017 um 23:54 schrieb Joel Esler (jesler):
We cannot be tied to distribution support problems.
but when you think as long as every other software works on
RHEL/CentOS and only ClamAV decides to make hard requirements breaking
that from one
The question here is, do we strive to make a package that is installable on
more machines, (even ones that are going EOL?), or do we strive to make a
package that is the best for security?
If the package maintainers are doing a good job, ClamAV with a higher
dependency would install the higher
On 04/03/17 22:54, Joel Esler (jesler) wrote:
We cannot be tied to distribution support problems.
That's fine Joel. You obviously know your own target audience. If it's
not me I can look elsewhere for solutions :-)
On Mar 4, 2017, at 17:44, Benny Pedersen wrote:
Leonardo Rodrigues skrev
Am 04.03.2017 um 23:54 schrieb Joel Esler (jesler):
We cannot be tied to distribution support problems.
but when you think as long as every other software works on RHEL/CentOS
and only ClamAV decides to make hard requirements breaking that from one
day to another i fear ClamAV (as apckage n
Am 04.03.2017 um 23:43 schrieb Benny Pedersen:
Leonardo Rodrigues skrev den 2017-03-04 23:12:
is clamav a redhat product ?!?! I don't think so. That being said, i
see absolutely no point at all on saying clamav should do this because
redhat does that.
good point
Anyone wishing to be update
Am 04.03.2017 um 23:12 schrieb Leonardo Rodrigues:
is clamav a redhat product ?!?! I don't think so. That being said, i
see absolutely no point at all on saying clamav should do this because
redhat does that.
Anyone wishing to be updated with a 10+ years rhel install, should
call redh
Joel Esler (jesler) skrev den 2017-03-04 23:54:
We cannot be tied to distribution support problems.
where did i ask for that ?
___
clamav-users mailing list
clamav-users@lists.clamav.net
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users
We cannot be tied to distribution support problems.
--
Sent from my iPhone
> On Mar 4, 2017, at 17:44, Benny Pedersen wrote:
>
> Leonardo Rodrigues skrev den 2017-03-04 23:12:
>> is clamav a redhat product ?!?! I don't think so. That being said, i
>> see absolutely no point at all on saying cl
Leonardo Rodrigues skrev den 2017-03-04 23:12:
is clamav a redhat product ?!?! I don't think so. That being said, i
see absolutely no point at all on saying clamav should do this because
redhat does that.
good point
Anyone wishing to be updated with a 10+ years rhel install, should
call redha
is clamav a redhat product ?!?! I don't think so. That being said,
i see absolutely no point at all on saying clamav should do this because
redhat does that.
Anyone wishing to be updated with a 10+ years rhel install, should
call redhat for that :)
my 0.02 cents ...
Em 04/03/
On 03/03/17 23:53, Scott Kitterman wrote:
As far as I can tell, pcre 7 came out before 2008. I think a decade is enough
time to insist people upgrade.
Scott K
Red Hat typically now supports each release of RHEL for at least a
decade, and that's not including any additional extended support
In Debian we back port security fixes the same way, but libraries with
different SO names are co-installable, so there's generally ways to deal with
these things. Clamav itself is an exception since not keeping up in
functionality means you lose the arms race.
Scott K
On March 3, 2017 7:04:03
Hello,
Insist :) Well, its considered bad practice to upgrade packages
independently on a RH-based system where dependancies break. Security
fixes are back-ported to older versions to preserve versioning an
compatibility. Thats a Redhat feature I agree, and RHEL5 will be EOL in
28 days, so
As far as I can tell, pcre 7 came out before 2008. I think a decade is enough
time to insist people upgrade.
Scott K
On Friday, March 03, 2017 11:21:30 PM Joel Esler wrote:
> If we required pcre 7, it would allow us to publish this kind of sig in the
> future of 99.3 and high versions by requir
If we required pcre 7, it would allow us to publish this kind of sig in the
future of 99.3 and high versions by requiring a certain "flevel".
--
Sent from my iPhone
> On Mar 3, 2017, at 18:18, Chris Conn wrote:
>
> Hello,
>
> Looks like my off-list email went on the list LOL. So much for no
Hello,
Looks like my off-list email went on the list LOL. So much for not
making noise. Woops.
If the 0.99.3 or whatever later version where this would be implemented
requires PCRE 7, would that break database updates for versions that
have not upgraded if this pcre format is re-used in th
A new daily with the Sig dropped.
Probably what we will do to prevent this from happening again, is to have
0.99.3 (the upcoming version) require pcre 7.
How does that sound?
--
Sent from my iPhone
> On Mar 3, 2017, at 18:08, Chris Conn wrote:
>
> Hello,
>
> I hope you don't mind my cont
Hello,
I hope you don't mind my contact off-list, I don't want to make noise on
it for all. Apologies.
This new build, are we talking about a daily.cvd (23162?) or a new build
of clam/pcre?
Thanks again in advance for your help,
Chris
On 3/3/2017 4:00 PM, Alain Zidouemba wrote:
We are
thanks for this build
because i have the same problem with pcre in rel5
Now, I think it will be necessary to quickly update the servers ;-)
regards
Le 03/03/2017 à 22:00, Alain Zidouemba a écrit :
We are coming to the same conclusions.
The issue seem to isolated to using pcre libraries olde
We are coming to the same conclusions.
The issue seem to isolated to using pcre libraries older than 7.0. I does
not affect users of newer versions of pcre or users of pcre2.
A new build with the fix is in progress now.
Apologies for the impact this has caused.
Alain
On Fri, Mar 3, 2017 at 2:3
Hello,
That may be true, but you also have to maintain a self-compiled version
of clamav now, and future updates you will need to re-do this.
This may be satisfactory to you as I don't of course know or understand
your particular situation, but for the clamav userbase that is using
RHEL5 (or
Em 03/03/17 17:31, Chris Conn escreveu:
Updating the PCRE manually doesn't seem like an option as it will
break dependancies for important packages, grep, php and httpd among
others.
I had success installing new PCRE libs on /usr/local (thus keeping
system libraries untouched) and recom
Hello,
If I can add to this discussion; since daily 23161 some RHEL5 systems
(pcre-6.6-9) are failing with that same error. A number of them have
down clamd at the moment.
Updating the PCRE manually doesn't seem like an option as it will break
dependancies for important packages, grep, php
I said in a previous mail, that i had the problem on CentOS 6
boxes, and that's not true, sorry for that. All my CentOS 6 boxes are
OK, and they have latest pcre from CentOS:
[root@correio ~]# rpm -qa | grep pcre
pcre-devel-7.8-7.el6.x86_64
pcre-7.8-7.el6.x86_64
The boxes on CentOS 5
Hi Aaron and Leonardo,
What are the versions of libpcre on your systems?
Thanks,
Steve
___
clamav-users mailing list
clamav-users@lists.clamav.net
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users
Help us build a comprehensive ClamAV guide
On Fri, March 3, 2017 7:20 pm, Alain Zidouemba wrote:
> We're pulling the signature causing the issue now, while we investigate
> the cause.
>
> - Alain
Hi Alain,
I think the fix is... Replace ? with ?P when the PCRE library is old
ie. ?< to ?P<
On...
Doc.Macro.GenericHeuristic-5901772-0
Doc
We're pulling the signature causing the issue now, while we investigate the
cause.
- Alain
On Fri, Mar 3, 2017 at 12:38 PM, Aaron C. Bolch wrote:
> Greetings,
>
> After Daily Update 23161 was applied, the following error happened:
>
> Database initialization error: can’t compile engine: Malform
OK, so it's PCRE related. Compiling new PCRE libs and linking
clamav to it should solve the problem, that's right ?
Em 03/03/17 15:11, Steve Basford escreveu:
It's a macro detecting ldb Sig that fails due to an old pcre engine
being used.
The Sig can be rewritten to work on older pcre
It's a macro detecting ldb Sig that fails due to an old pcre engine being used.
The Sig can be rewritten to work on older pcre versions .. or you need to
update.
Sorry I can't help more.
Cheers,
Steve
Twitter: @sanesecurity
On 3 March 2017 17:39:48 "Aaron C. Bolch" wrote:
Greetings,
A
Same problem here with 0.99.2 on CentOS 6 machine:
[root@correio clamav]# service clamd start
Starting Clam AV daemon: LibClamAV Error: cli_pcre_compile: PCRE
compilation failed at offset 52: unrecognized character after (?<
LibClamAV Error: cli_pcre_build: failed to build pcre regex
ERROR
Greetings,
After Daily Update 23161 was applied, the following error happened:
Database initialization error: can’t compile engine: Malformed Database
When starting Clamd:
LibCLamAV Error: cli_pcre_compile: PCRE compilation failed at offset 52:
unrecognized character after (?<
LibClamAV Error
43 matches
Mail list logo
