Mailing List Archive

1 2 3 4 5 6  View All
Re: Argument "perl_version" isn't numeric [ In reply to ]
Jim Clausing wrote:
> What I haven't noticed anyone else mention is that I was getting that error
> message even though the perl on my Ubuntu 14.04 system is 5.18.2.

You left off your spamassassin version. I assume 3.4.0? On my Debian
sid system. (But never use Unstable for a production system. Not
unless you enjoy having your house on fire every so often.)

$ spamassassin --version
SpamAssassin version 3.4.0
running on Perl version 5.20.1

There have been multiple facets to this problem. The first was a rule
update that produced warnings that produced email from every cron run
sa-update / sa-learn run if run on recent released spamassassin 3.4.0
but not the development trunk version. Therefore it hit almost
everyone running any type of production system. It hit your Ubuntu
14.04 system. That was mitigated by disabling the rule for the time
being.

The capability then being discussed was a suggested version gate using
an if expression syntax. This is the spamassassin config parser "if",
not the perl "if". That if expression worked for most but it had
problems on a quite a bit older perl 5.8.8 still in wide use in
RHEL5. It is somewhat surprising that the spamassassin config parser
would have a sensitivity there but regardless so it does.

Your Ubuntu 14.04 system with perl 5.18.2 probably also is running
spamassassin 3.4.0 like my Debian Sid system. It wasn't running the
development trunk spamassassin. Therefore the dynamic rule update
emitted that warning for you too. But the new suggested rule using
the improved if expression gating syntax will work okay for you.

Hope that helps,
Bob
Re: Argument "perl version" isn't numeric [ In reply to ]
On 03/12/2014 21:57, Kevin A. McGrail wrote:

>> Sure, if that was truly the case nor would I, but if you are running that old perl, there is plenty of stuff thats outdated, and not all of the goodness gets backports, not just with perl, but with most other things.
> I can't fight every windmill and changing how distros work re: versions of perl is one I choose not to battle.
>
> Regards,
> KAM

Oh absolutely! But why is it SA's problem? Or for that mater, any
up-stream's problem if distro X wants to only maintain
version_released_in_BC or some such, I mean if, and lets take Redhat for
example (not singling RH out, because debian are just as bad, if not
worse), they turn around and decide that RHEL since v5 will now be
supported for 10 years, not 5, at what point do you draw the line and
say " well RH that's your problem "

N
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 12/3/2014 6:39 PM, Noel Butler wrote:
>
> On 03/12/2014 21:57, Kevin A. McGrail wrote:
>
>>> Sure, if that was truly the case nor would I, but if you are running
>>> that old perl, there is plenty of stuff thats outdated, and not all
>>> of the goodness gets backports, not just with perl, but with most
>>> other things.
>>>
>> I can't fight every windmill and changing how distros work re:
>> versions of perl is one I choose not to battle.
>>
>> Regards,
>> KAM
>
> Oh absolutely! But why is it SA's problem? Or for that mater, any
> up-stream's problem if distro X wants to only maintain
> version_released_in_BC or some such, I mean if, and lets take Redhat
> for example (not singling RH out, because debian are just as bad, if
> not worse), they turn around and decide that RHEL since v5 will now be
> supported for 10 years, not 5, at what point do you draw the line and
> say " well RH that's your problem "
>
I try to avoid the "that's your problem" discussions as much as possible
because, for example, I could make the same argument about supporting
3.3.2 or go further and provide rules at all for the software.

So I take the maintain status quo approach as long as the code continues
to move forward and we don't spend too many cycles having to work around
legacy issues.

regards,
KAM
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 12/3/2014 7:38 AM, Jim Clausing wrote:
> What I haven't noticed anyone else mention is that I was getting that
> error message even though the perl on my Ubuntu 14.04 system is 5.18.2.
>

No, they mentioned it - the problem is that the proposed "fix" to allow
inclusion of the new fancy rules only works with newer Perl versions.
The argument now is since the proposed fix breaks antique versions of
Perl, are we going to tell those people to pound sand or not?

Ted


> --
> Jim Clausing
> GIAC GSE #26, GREM-Gold, CISSP
> GPG fingerprint = 4780 13A4 F33E BF4E AE86 0D64 0EFD B3E3 03BF 407A
>
> On or about Tue, 2 Dec 2014, Noel Butler pontificated thusly:
>
>>
>>
>> On 02/12/2014 23:10, Kevin A. McGrail wrote:
>>
>>>> 5.10 is only what, six years old? Surely anyone running anything
>>>> older have far greater issues :)
>>>>
>>>> (says the guy running a few slackware 13.1 boxes with 5.10.1 hehe
>>>> but theyll join the 14 series this Christmas when I can take them
>>>> offline to upgrade em, even -current is useing a 12 month old 5.18.1)
>>> There is a fairly consistent streak in some distros to backport
>>> patches to older versions rather than move the version forward. 5.8.8
>>> is in pretty far spread use from my knowledge.
>>
>> Likely in antique versions of debian and Redhat (which again will have
>> bigger issues), there surely must come a time when the line is drawn and
>> say - you're unsupported from this_date, give them plenty of notice, I
>> think 12 months notice is plenty of time for planned upgrades or devise
>> workarounds, SA is not updated all that often, so a next major release
>> would be about 12 months away, short of a serious exploit found anyway,
>> so there's plenty of time for lazy admins to do what they actually get
>> paid to do :)
>>
>>
Re: Argument "perl_version" isn't numeric [ In reply to ]
On Wed, 3 Dec 2014, Bob Proulx wrote:

> There have been multiple facets to this problem. The first was a rule
> update that produced warnings that produced email from every cron run
> sa-update / sa-learn run if run on recent released spamassassin 3.4.0
> but not the development trunk version.

That was actually the second facet. The first facet was a new test rule
using a perl RE syntax that was introduced in 5.10.0 This rule passed dev
validation on perl 5.18-ish, but when it was installed by sa-update on a
production 5.8.8-based install it failed lint and the entire rules update
was rejected. Avoiding that was the impetus for being able to test the
version of perl in a SA conditional.

The rest has just been trying to figure out how to do that in a
backwards-compatible manner.

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
You do not examine legislation in the light of the benefits it
will convey if properly administered, but in the light of the
wrongs it would do and the harms it would cause if improperly
administered. -- Lyndon B. Johnson
-----------------------------------------------------------------------
11 days until Bill of Rights day
Re: Argument "perl_version" isn't numeric [ In reply to ]
John Hardin wrote:
> Bob Proulx wrote:
> > There have been multiple facets to this problem. The first was a rule
> > update that produced warnings that produced email from every cron run
> > sa-update / sa-learn run if run on recent released spamassassin 3.4.0
> > but not the development trunk version.
>
> That was actually the second facet. The first facet was a new test rule
> using a perl RE syntax that was introduced in 5.10.0 This rule passed dev
> validation on perl 5.18-ish, ...

But, but, but... It also failed lint and produced cron noise on my
perl 5.20.1 system too. Running spamassassin 3.4.0. That is later
than perl 5.18 and it definitely produced the warning message. It
couldn't have been solely due to perl version or there wouldn't have
been any warnings there. It could only have been due to the
spamassassin version 3.4.0, the latest released version, which did not
include the development trunk code.

> but when it was installed by sa-update on a production 5.8.8-based
> install it failed lint and the entire rules update was
> rejected. Avoiding that was the impetus for being able to test the
> version of perl in a SA conditional.

AIUI the combination of versions there is RHEL5/CentOS5 with perl
5.8.8 and spamassassin 3.3.1. Apparently there it is the perl 5.8.8
that tickled a problem because 3.3.2 with perl 5.14 is okay.

> The rest has just been trying to figure out how to do that in a
> backwards-compatible manner.

Yep. The devil is in the details!

Bob
Re: Argument "perl_version" isn't numeric [ In reply to ]
On Thu, 4 Dec 2014, Bob Proulx wrote:

> John Hardin wrote:
>> Bob Proulx wrote:
>>> There have been multiple facets to this problem. The first was a rule
>>> update that produced warnings that produced email from every cron run
>>> sa-update / sa-learn run if run on recent released spamassassin 3.4.0
>>> but not the development trunk version.
>>
>> That was actually the second facet. The first facet was a new test rule
>> using a perl RE syntax that was introduced in 5.10.0 This rule passed dev
>> validation on perl 5.18-ish, ...
>
> But, but, but... It also failed lint and produced cron noise on my
> perl 5.20.1 system too. Running spamassassin 3.4.0. That is later
> than perl 5.18 and it definitely produced the warning message.

That's two separate issues. The perl RE lint *error* was due to use of the
\w++ construct from 5.10+ on a 5.8.8 install. That's perl version
dependent.

The addition of a perl_version conditional to protect that rule without
also having a check for the SA version to ensure it supported perl_version
is what generated the SA parse *warning*. That's SA version dependent.

Adding a check for SA version to that conditional suppressed the SA parse
warning, *except* on perl < 5.10, apparently due to a change in perl's
expression shortcut semantics (but this is not proven). That's perl
version dependent.

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Of the twenty-two civilizations that have appeared in history,
nineteen of them collapsed when they reached the moral state the
United States is in now. -- Arnold Toynbee
-----------------------------------------------------------------------
11 days until Bill of Rights day
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 2014-12-03 15:39, Noel Butler wrote:
> On 03/12/2014 21:57, Kevin A. McGrail wrote:
>
>>> Sure, if that was truly the case nor would I, but if you are running that old
>>> perl, there is plenty of stuff thats outdated, and not all of the goodness
>>> gets backports, not just with perl, but with most other things.
>>>
>> I can't fight every windmill and changing how distros work re: versions of
>> perl is one I choose not to battle.
>>
>> Regards,
>> KAM
>
> Oh absolutely! But why is it SA's problem? Or for that mater, any up-stream's
> problem if distro X wants to only maintain version_released_in_BC or some such,
> I mean if, and lets take Redhat for example (not singling RH out, because debian
> are just as bad, if not worse), they turn around and decide that RHEL since v5
> will now be supported for 10 years, not 5, at what point do you draw the line
> and say " well RH that's your problem "
>
> N

OK, if RHEL elects to upgrade SA to 3.4.x and leaves perl as it was, they bought
their headaches. If SA provides specific updates to earlier versions so that
perl_version is declared and is numeric and the if clause works for each of the
old versions it makes the distro maintainers' job easy. If after that the distro
does not update AND SA posts word about the fix on the website VERY prominently
then the it becomes the distro maintainers who are the bad guys. Trying to Meet
them half way there seems like the polite thing to do. After all, it is a latent
SA bug that has come out to bite us. So we at least lead the horses to water.
They can choose to drink or not.

The alternate solution is rule updates for 3.4.x that contain the fancy rules
and separate rule updates for lower SA versions. If a sysadmin runs 3.4.2
against perl 5.8.6 he's bought his own problems. LTS distros don't tend to do
such upgrades.

{^_^}
Re: Argument "perl_version" isn't numeric [ In reply to ]
John Hardin wrote:
> Bob Proulx wrote:
> >But, but, but... It also failed lint and produced cron noise on my
> >perl 5.20.1 system too. Running spamassassin 3.4.0. That is later
> >than perl 5.18 and it definitely produced the warning message.
>
> That's two separate issues. The perl RE lint *error* was due to use of the
> \w++ construct from 5.10+ on a 5.8.8 install. That's perl version dependent.

Ah... I never saw that error. So I didn't come online until the
perl_version noise through cron every hour due to sa-learn runs and
once a day due to sa-update runs.

> The addition of a perl_version conditional to protect that rule without also
> having a check for the SA version to ensure it supported perl_version is
> what generated the SA parse *warning*. That's SA version dependent.

Since it is recommended to run sa-update by cron (as you now know :-) )
it generates email noise. Additionally many of us set
"bayes_auto_expire 0" so that we never pause to expire during an SA
run but then run sa-learn --force-expire by cron often. I run it
hourly. It is mostly those runs that caused hourly emails. And I
have seven systems emailing me those messages. But as an email admin
I really don't mind getting a lot of email and can handle that quite
easily. :-)

> Adding a check for SA version to that conditional suppressed the SA parse
> warning, *except* on perl < 5.10, apparently due to a change in perl's
> expression shortcut semantics (but this is not proven). That's perl version
> dependent.

That one I knew about.

Thanks for the clarification on the issues. I had missed that first part.

Bob

1 2 3 4 5 6  View All