Mailing List Archive

1 2 3 4 5 6  View All
Re: Argument "perl_version" isn't numeric [ In reply to ]
On Sun, 30 Nov 2014, Benny Pedersen wrote:

> On 30. nov. 2014 20.53.19 John Hardin <jhardin@impsec.org> wrote:
>
>> Sadly that doesn't work. The else branch of a conditional still gets
>> partially parsed, so the perl_version type warning is still emitted even
>> if it is inside a conditional that evaluates to false.
>>
>> Try this:
>>
>> if 0 > 0
>
> Psudo if trunc

Huh?

>> if fnord > 0
>
> Psudo fnord would exists in trunc

This has nothing to do with trunk code, if that's what you're suggesting.
I'm illustrating the behavior of parsing vs. conditionals with something
that will generate a warning simliar to what we're seeing with
perl_version. Did you actually *try* what I suggested?

>> meta SYN_ERROR
>> endif
>> endif
>>
>> SA won't generate a warning about the syntax of the SYN_ERROR rule, but it
>> will emit a warning about fnord not being numeric.
>
> Not if trunc installed, hopefully,

I tested the above against trunk before recommending you try it.

> is it a svn tag check in sa ?

No. "fnord" is just a token that I know will not match anything in
conditional parsing, even in trunk. It's a guaranteed parse warning.
Sorry, I meant to use "fnord" literally to illustrate the problem, not as
a generic placeholder.

> Hopefully it would be resolved in future sa verions to not break any admin
> legs :)

It's possible that the parser could be revised to not parse false
conditional branches as much as it is, but that would *not* correct this
behavior in existing releases so doing this won't succeed in preventing
these warnings in older SA when a new release that supports perl_version
goes out:

if release > 3.004001
if perl_version >= 5.010000
body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
endif
endif

--
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
-----------------------------------------------------------------------
15 days until Bill of Rights day
Re: Argument "perl_version" isn't numeric [ In reply to ]
Am 30.11.2014 um 21:49 schrieb Dave Pooser:
> On 11/30/14, 2:04 PM, "Reindl Harald" <h.reindl@thelounge.net> wrote:
>
>> it's *not* about a "crufty version of perl"
>>
>> it's about a perl version check not existing in SpamAssassin 3.4.0
>> it's visible on recent perl versions
>> without the version checks issing the warnings they had no problem
>
> OK, I could have been clearer there. Let me spell out my logic:
>
> 1) Red Hat is not going to release a new version of SpamAssassin for their
> existing distros. That's not how they roll.
> 2) Any rule that uses a regex that requires a version of Perl later than
> the 2006-era Perl 5.8.8 will cause a fatal sa-update error unless it's
> wrapped in a version check
> 3) Using version_check creates a non-fatal warning on versions of SA =<
> 3.4.0
>
> So, we have three options
> 1) Force Red Hat users to endure a warning unless they update their
> spamassassin outside of normal distro channels to gain version_check
> capabilities
> 2) Take the version_check out and break sa-update on computers running
> older versions of perl
> 3) Write all spamassassin rules to use the lowest-common-denominator perl,
> which would be the "crufty version of perl" I referred to above.
>
> Do you see a fourth option?

4)
don't publish a rule with a 0.001 score introducing problems
the impact of that rule can't beat out the cron-mails at all

5)
make the condition to the SA version, there are already ton's of "if
(version >= 3.004000)" rules and so it needs just to depend on SA bigger
than 3.4.0 instead of the perl check

why that would work?
well, older RHEL versions as you said won't upgrade SA or perl
that setups would not use the rule, recent ones would
Re: Argument "perl_version" isn't numeric [ In reply to ]
On Sun, 30 Nov 2014, Reindl Harald wrote:

> 5)
> make the condition to the SA version, there are already ton's of "if (version
> > = 3.004000)" rules and so it needs just to depend on SA bigger than
> 3.4.0 instead of the perl check
>
> why that would work?
> well, older RHEL versions as you said won't upgrade SA or perl
> that setups would not use the rule, recent ones would

And anyone who is running SA prior to 3.4.0 on perl newer than 5.8.8
(where it would run just fine) does not get the benefit of the rule, and
anyone running 3.4.0 on perl 5.8.8 (which is entirely possible) has their
sa-update lint blow up and they don't get *any* new rules.

The assumption "newer SA = newer perl" is not really justified.

--
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
-----------------------------------------------------------------------
The fetters imposed on liberty at home have ever been forged out
of the weapons provided for defense against real, pretended, or
imaginary dangers from abroad. -- James Madison, 1799
-----------------------------------------------------------------------
15 days until Bill of Rights day
Re: Argument "perl_version" isn't numeric [ In reply to ]
On Sun, 30 Nov 2014, John Hardin wrote:

> if release > 3.004001
> if perl_version >= 5.010000
> body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
> endif
> endif

dammit.

if version > 3.004001
if perl_version >= 5.010000
body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
endif
endif


--
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
-----------------------------------------------------------------------
The fetters imposed on liberty at home have ever been forged out
of the weapons provided for defense against real, pretended, or
imaginary dangers from abroad. -- James Madison, 1799
-----------------------------------------------------------------------
15 days until Bill of Rights day
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 30. nov. 2014 22.15.12 John Hardin <jhardin@impsec.org> wrote:

> if version > 3.004001
> if perl_version >= 5.010000
> body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
> endif
> endif

If this works now in spamassassin 3.3.2, problem solved, can i send
bitcoins somewhere ? :)
Re: Argument "perl_version" isn't numeric [ In reply to ]
Am 30.11.2014 um 22:13 schrieb John Hardin:
> On Sun, 30 Nov 2014, Reindl Harald wrote:
>
>> 5)
>> make the condition to the SA version, there are already ton's of "if
>> (version > = 3.004000)" rules and so it needs just to depend on SA
>> bigger than 3.4.0 instead of the perl check
>>
>> why that would work?
>> well, older RHEL versions as you said won't upgrade SA or perl
>> that setups would not use the rule, recent ones would
>
> And anyone who is running SA prior to 3.4.0 on perl newer than 5.8.8
> (where it would run just fine) does not get the benefit of the rule, and
> anyone running 3.4.0 on perl 5.8.8 (which is entirely possible) has
> their sa-update lint blow up and they don't get *any* new rules.
>
> The assumption "newer SA = newer perl" is not really justified

true - at the end of the day "we" need to draw a line and outweight
benefit/drawbacks for each case

the final conclusion can even be "the benefit of a specific rule is not
high enough to beat out the drawbacks" until all possible and reasonable
conditions are evaluated

maybe the same rule result could be achived with a not that nice syntax
working with older SA as well perl versions and if that's not possible
the question "is it really worth the trouble" remains

what i mean if there is no better solution: there is hardly a new rule
that from one day to the next will stop a reasonable large amount of
spam not already caught by the summary of other rules
Re: Argument "perl_version" isn't numeric [ In reply to ]
Perhaps the rules that need the version check could be put into a separate file
that is only used with SA version 3.4.x and above. It might be possible to get
the appropriate sa_update patch for older versions through Red Hat, if that is
needed. It might not be if 3.3.x does not load rule files marked for 3.4.x. I
note there are separate storage areas for rules for various versions. If it's
really used that's perhaps the best fix.

(And if I'm thinking as well as I think in the above maybe I should get back to
paying work.)

{^_^}

On 2014-11-30 12:49, Dave Pooser wrote:
> On 11/30/14, 2:04 PM, "Reindl Harald" <h.reindl@thelounge.net> wrote:
>
>> it's *not* about a "crufty version of perl"
>>
>> it's about a perl version check not existing in SpamAssassin 3.4.0
>> it's visible on recent perl versions
>> without the version checks issing the warnings they had no problem
>
> OK, I could have been clearer there. Let me spell out my logic:
>
> 1) Red Hat is not going to release a new version of SpamAssassin for their
> existing distros. That's not how they roll.
> 2) Any rule that uses a regex that requires a version of Perl later than
> the 2006-era Perl 5.8.8 will cause a fatal sa-update error unless it's
> wrapped in a version check
> 3) Using version_check creates a non-fatal warning on versions of SA =<
> 3.4.0
>
> So, we have three options
> 1) Force Red Hat users to endure a warning unless they update their
> spamassassin outside of normal distro channels to gain version_check
> capabilities
> 2) Take the version_check out and break sa-update on computers running
> older versions of perl
> 3) Write all spamassassin rules to use the lowest-common-denominator perl,
> which would be the "crufty version of perl" I referred to above.
>
> Do you see a fourth option?
>
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 2014-11-30 13:13, John Hardin wrote:
> On Sun, 30 Nov 2014, Reindl Harald wrote:
>
>> 5)
>> make the condition to the SA version, there are already ton's of "if (version
>> > = 3.004000)" rules and so it needs just to depend on SA bigger than 3.4.0
>> instead of the perl check
>>
>> why that would work?
>> well, older RHEL versions as you said won't upgrade SA or perl
>> that setups would not use the rule, recent ones would
>
> And anyone who is running SA prior to 3.4.0 on perl newer than 5.8.8 (where it
> would run just fine) does not get the benefit of the rule, and anyone running
> 3.4.0 on perl 5.8.8 (which is entirely possible) has their sa-update lint blow
> up and they don't get *any* new rules.
>
> The assumption "newer SA = newer perl" is not really justified.

Um, er, ah, <shuffle-feet and diffidently raise a hand>

I'd like to note that I am seeing this warning with SL6.6 loaded from EL6
repository. It's version is 5.10.1. This seems to discredit the word about perl
versions greater than 5.8.8.

Perhaps a plugin could be developed to benignly figure out the version of perl
that is loaded. That could produce a value to be used in the rule parsing
process. Perhaps somebody could figure out what versions of perl really do fail
this way. It seems that there are an interesting plethora of missing data points
to consider here. I'll help such as I can in my feeble way. I'll give up my
recreational time playing with Software Defined Radios. (They're dangerously
addictive fun for some folks with a long history in radio.)

{^_^} Joanne
Re: Argument "perl_version" isn't numeric [ In reply to ]
Am 30.11.2014 um 22:22 schrieb Reindl Harald:
> Am 30.11.2014 um 22:13 schrieb John Hardin:
>> On Sun, 30 Nov 2014, Reindl Harald wrote:
>>
>>> 5)
>>> make the condition to the SA version, there are already ton's of "if
>>> (version > = 3.004000)" rules and so it needs just to depend on SA
>>> bigger than 3.4.0 instead of the perl check
>>>
>>> why that would work?
>>> well, older RHEL versions as you said won't upgrade SA or perl
>>> that setups would not use the rule, recent ones would
>>
>> And anyone who is running SA prior to 3.4.0 on perl newer than 5.8.8
>> (where it would run just fine) does not get the benefit of the rule, and
>> anyone running 3.4.0 on perl 5.8.8 (which is entirely possible) has
>> their sa-update lint blow up and they don't get *any* new rules.
>>
>> The assumption "newer SA = newer perl" is not really justified
>
> true - at the end of the day "we" need to draw a line and outweight
> benefit/drawbacks for each case
>
> the final conclusion can even be "the benefit of a specific rule is not
> high enough to beat out the drawbacks" until all possible and reasonable
> conditions are evaluated
>
> maybe the same rule result could be achived with a not that nice syntax
> working with older SA as well perl versions and if that's not possible
> the question "is it really worth the trouble" remains
>
> what i mean if there is no better solution: there is hardly a new rule
> that from one day to the next will stop a reasonable large amount of
> spam not already caught by the summary of other rules

additionally if you have the "if perl_version" *inside* a "if version"
and only apply it that way to SA >= 3.4.0 the warnings at least would
only occur on systems with a old perl and recent SA which is hopefully
the minority

from my knowledge the "if perl_version" should not get touched in that
case at all, at least in the interpreted languages i am working with a
"and" condition is evaluated from left to right and the right oart is
skipped if the left one is negative

the currect rolled out rule affects pretty recent SA running with pretty
recent perl and that's a not reasonable penalty
Re: Argument "perl_version" isn't numeric [ In reply to ]
On Sun, Nov 30, 2014 at 3:30 PM, Ted Mittelstaedt <tedm@ipinc.net> wrote:
> I guess the $64K question is, does the new rule that's version dependent
> Increase the "spam catch" Because if it does, then I don't regard it as a
> problem. Instead, I want it!

The real $64K question is: If you really want it (in your production
systems) would you be willing to just accept only being able to get it
via patches posted to a mailinglist?

I'm in agreement with Reindl, SA updates should be tested against all
versions in use (that info is easy to get), and regular updates
shouldn't produce failures on systems that apply them (heck, Microsoft
figured that out back in the 90s). Barring that, advanced
notifications should go out indicating that future updates will break
things, or cause errors that may raise concern.

-Jim P.
Re: Argument "perl_version" isn't numeric [ In reply to ]
On Sun, 30 Nov 2014, Benny Pedersen wrote:

> On 30. nov. 2014 22.15.12 John Hardin <jhardin@impsec.org> wrote:
>
>> if version > 3.004001
>> if perl_version >= 5.010000
>> body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
>> endif
>> endif
>
> If this works now in spamassassin 3.3.2, problem solved, can i send bitcoins
> somewhere ? :)

It "works" in 3.3.2 *IF* you accept the warning about perl_version being
non-numeric that this entire thread is about. The non-5.8.8-compatible RE
is skipped, because the perl_version conditional fails to false on the
type warning and doesn't include the rule.

--
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
-----------------------------------------------------------------------
The fetters imposed on liberty at home have ever been forged out
of the weapons provided for defense against real, pretended, or
imaginary dangers from abroad. -- James Madison, 1799
-----------------------------------------------------------------------
15 days until Bill of Rights day
Re: Argument "perl_version" isn't numeric [ In reply to ]
On Sun, 30 Nov 2014, jdow wrote:

> Perhaps the rules that need the version check could be put into a separate
> file that is only used with SA version 3.4.x and above. It might be possible
> to get the appropriate sa_update patch for older versions through Red Hat, if
> that is needed. It might not be if 3.3.x does not load rule files marked for
> 3.4.x. I note there are separate storage areas for rules for various
> versions. If it's really used that's perhaps the best fix.

That is a potential fix.

Rewriting the rule to use 5.8.8-compatible syntax is another possibility.
This is a rule that somebody on the list asked for masscheck results on
and it performed well enough to get promoted. I haven't taken a close look
at the RE itself to see whether the non-5.8.8-compatible syntax is
critical or it can indeed be modified to be 5.8.8-compatible.

> (And if I'm thinking as well as I think in the above maybe I should get back
> to paying work.)

Or back to bed with some tea and cold drugs and a good book.

> {^_^}
>
> On 2014-11-30 12:49, Dave Pooser wrote:
>> On 11/30/14, 2:04 PM, "Reindl Harald" <h.reindl@thelounge.net> wrote:
>>
>> > it's *not* about a "crufty version of perl"
>> >
>> > it's about a perl version check not existing in SpamAssassin 3.4.0
>> > it's visible on recent perl versions
>> > without the version checks issing the warnings they had no problem
>>
>> OK, I could have been clearer there. Let me spell out my logic:
>>
>> 1) Red Hat is not going to release a new version of SpamAssassin for their
>> existing distros. That's not how they roll.
>> 2) Any rule that uses a regex that requires a version of Perl later than
>> the 2006-era Perl 5.8.8 will cause a fatal sa-update error unless it's
>> wrapped in a version check
>> 3) Using version_check creates a non-fatal warning on versions of SA =<
>> 3.4.0
>>
>> So, we have three options
>> 1) Force Red Hat users to endure a warning unless they update their
>> spamassassin outside of normal distro channels to gain version_check
>> capabilities
>> 2) Take the version_check out and break sa-update on computers running
>> older versions of perl
>> 3) Write all spamassassin rules to use the lowest-common-denominator perl,
>> which would be the "crufty version of perl" I referred to above.
>>
>> Do you see a fourth option?
>>
>
>

--
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
-----------------------------------------------------------------------
The fetters imposed on liberty at home have ever been forged out
of the weapons provided for defense against real, pretended, or
imaginary dangers from abroad. -- James Madison, 1799
-----------------------------------------------------------------------
15 days until Bill of Rights day
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 11/30/2014 4:58 PM, John Hardin wrote:
> On Sun, 30 Nov 2014, Benny Pedersen wrote:
>
>> On 30. nov. 2014 22.15.12 John Hardin <jhardin@impsec.org> wrote:
>>
>>> if version > 3.004001
>>> if perl_version >= 5.010000
>>> body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
>>> endif
>>> endif
>>
>> If this works now in spamassassin 3.3.2, problem solved, can i send
>> bitcoins somewhere ? :)
>
> It "works" in 3.3.2 *IF* you accept the warning about perl_version
> being non-numeric that this entire thread is about. The
> non-5.8.8-compatible RE is skipped, because the perl_version
> conditional fails to false on the type warning and doesn't include the
> rule.
>
I think we have to accept from the noise on the traffic that the warning
is not considered acceptable.

What do you see wrong with the use of the can/has solution that both
Mark and I proposed? I think it will be trivial and should not cause
any errors for older SA's.

regards,
KAM
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 2014-11-30 13:58, John Hardin wrote:
> On Sun, 30 Nov 2014, Benny Pedersen wrote:
>
>> On 30. nov. 2014 22.15.12 John Hardin <jhardin@impsec.org> wrote:
>>
>>> if version > 3.004001
>>> if perl_version >= 5.010000
>>> body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
>>> endif
>>> endif
>>
>> If this works now in spamassassin 3.3.2, problem solved, can i send bitcoins
>> somewhere ? :)
>
> It "works" in 3.3.2 *IF* you accept the warning about perl_version being
> non-numeric that this entire thread is about. The non-5.8.8-compatible RE is
> skipped, because the perl_version conditional fails to false on the type warning
> and doesn't include the rule.
>

Would a corrected syntax version of this work?

if version > 3.004001 && perl_version >= 5.010000
body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
endif

{^_^}
Re: Argument "perl_version" isn't numeric [ In reply to ]
On Sun, 30 Nov 2014, jdow wrote:

> On 2014-11-30 13:13, John Hardin wrote:
>> On Sun, 30 Nov 2014, Reindl Harald wrote:
>>
>> > 5)
>> > make the condition to the SA version, there are already ton's of "if
>> > (version
>> > > = 3.004000)" rules and so it needs just to depend on SA bigger than
>> > > 3.4.0
>> > instead of the perl check
>> >
>> > why that would work?
>> > well, older RHEL versions as you said won't upgrade SA or perl
>> > that setups would not use the rule, recent ones would
>>
>> And anyone who is running SA prior to 3.4.0 on perl newer than 5.8.8
>> (where it
>> would run just fine) does not get the benefit of the rule, and anyone
>> running
>> 3.4.0 on perl 5.8.8 (which is entirely possible) has their sa-update lint
>> blow
>> up and they don't get *any* new rules.
>>
>> The assumption "newer SA = newer perl" is not really justified.
>
> Um, er, ah, <shuffle-feet and diffidently raise a hand>
>
> I'd like to note that I am seeing this warning with SL6.6 loaded from EL6
> repository. It's version is 5.10.1. This seems to discredit the word about
> perl versions greater than 5.8.8.

Again:

This problem is not related to the version of perl that is installed.
Changing the version of perl will not fix it. It's related to the ability
to add new conditional features to SA.

There is a new feature in SA trunk that allows a conditional to check a
new pseudo-variable named "perl_version", to determine the version of perl
that is installed, similar to how the "version" pseudo-variable allows
rules to check the version of SA that is installed. For example:

# avoid generating a fatal lint error in perl 5.8.8
if perl_version >= 5.010000
body NON_5_8_8_COMPATIBLE_RE /\w++/
endif

Checking perl_version in non-trunk versions of SA causes a type error
because those versions don't recognize "perl_version" as something to
replace with the perl version and instead treat it as a literal string,
which causes a type conflict because >= is a numeric operator.
Effectively, this is what's happening in older SA:

if "perl_version" >= 5.010000
body NON_5_8_8_COMPATIBLE_RE /\w++/
endif

This would not be fixed by changing the version of perl, and will be a
problem in older SA installs even after support for "perl_version" is
officially released.

> Perhaps a plugin could be developed to benignly figure out the version of
> perl that is loaded. That could produce a value to be used in the rule
> parsing process.

The change to the parser to recognize perl_version was about as trivial as
such changes get, much more lightweight (and neater) than a plugin. And a
change to recognize a value returned by a plugin in conditionals would
probably land us in the same place we're in now - older SA emitting a
warning regarding an unrecognized capability.

There was also a suggestion about making a can() check to determine the
perl version, but as that would require code changes in the parser to
support a parameter, we're right back to where we are now: earlier SA will
generate a warning on the conditional syntax.

Example:

if can(Mail::SpamAssassin::Conf::min_perl_version(5.010000))

Nov 30 14:13:11.973 [17507] warn: config: error in if -
$self->cond_clause_can( "Mail::SpamAssassin::Conf::min_perl_version" (
5.010000 ) ) : syntax error at (eval 2557) line 1, near
""Mail::SpamAssassin::Conf::min_perl_version" ( "

Another (ugly) alternative would be to define a bunch of functions like
this for various perl versions:

if can(Mail::SpamAssassin::Conf::min_perl_version_5010000)


--
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
-----------------------------------------------------------------------
Activist: Someone who gets involved.
Unregistered Lobbyist: Someone who gets involved with something
the MSM doesn't approve of. -- WizardPC
-----------------------------------------------------------------------
15 days until Bill of Rights day
Re: Argument "perl_version" isn't numeric [ In reply to ]
On Sun, 30 Nov 2014, Reindl Harald wrote:
>
> additionally if you have the "if perl_version" *inside* a "if version" and
> only apply it that way to SA >= 3.4.0 the warnings at least would only occur
> on systems with a old perl and recent SA which is hopefully the minority

Not true, please see my discussion of this earlier.

> from my knowledge the "if perl_version" should not get touched in that case
> at all,

Sadly, it does.

--
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
-----------------------------------------------------------------------
Activist: Someone who gets involved.
Unregistered Lobbyist: Someone who gets involved with something
the MSM doesn't approve of. -- WizardPC
-----------------------------------------------------------------------
15 days until Bill of Rights day
Re: Argument "perl_version" isn't numeric [ In reply to ]
On Sun, 30 Nov 2014, jdow wrote:

>> On Sun, 30 Nov 2014, Benny Pedersen wrote:
>> > On 30. nov. 2014 22.15.12 John Hardin <jhardin@impsec.org> wrote:
>> >
>> > > if version > 3.004001
>> > > if perl_version >= 5.010000
>> > > body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
>> > > endif
>> > > endif
>> >
>> > If this works now in spamassassin 3.3.2, problem solved, can i send
>> > bitcoins
>> > somewhere ? :)
>>
>> It "works" in 3.3.2 *IF* you accept the warning about perl_version
>> being non-numeric that this entire thread is about. The
>> non-5.8.8-compatible RE is skipped, because the perl_version
>> conditional fails to false on the type warning and doesn't include the
>> rule.
>
> Would a corrected syntax version of this work?
>
> if version > 3.004001 && perl_version >= 5.010000
> body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
> endif

Yes. That *does* work.

Thank you! I think you just solved it.

--
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
-----------------------------------------------------------------------
Activist: Someone who gets involved.
Unregistered Lobbyist: Someone who gets involved with something
the MSM doesn't approve of. -- WizardPC
-----------------------------------------------------------------------
15 days until Bill of Rights day
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 11/30/2014 5:20 PM, jdow wrote:
> Would a corrected syntax version of this work?
>
> if version > 3.004001 && perl_version >= 5.010000
> body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
> endif
>
> {^_^}

The core issue is that only SA currently in trunk contains the code for
the if functionality on the perl_version.

So I believe any use of perl_version is likely to throw warnings unless
people are using SA from svn trunk.

Regards,
KAM
Re: Argument "perl_version" isn't numeric [ In reply to ]
On Sun, 30 Nov 2014, Kevin A. McGrail wrote:

> I think we have to accept from the noise on the traffic that the warning is
> not considered acceptable.

Yeah.

> What do you see wrong with the use of the can/has solution that both Mark and
> I proposed? I think it will be trivial and should not cause any errors for
> older SA's.

I think jdow just proposed a workable solution.

--
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
-----------------------------------------------------------------------
Activist: Someone who gets involved.
Unregistered Lobbyist: Someone who gets involved with something
the MSM doesn't approve of. -- WizardPC
-----------------------------------------------------------------------
15 days until Bill of Rights day
Re: Argument "perl_version" isn't numeric [ In reply to ]
Am 30.11.2014 um 23:29 schrieb John Hardin:
> On Sun, 30 Nov 2014, jdow wrote:
>>> On Sun, 30 Nov 2014, Benny Pedersen wrote:
>>> > On 30. nov. 2014 22.15.12 John Hardin <jhardin@impsec.org> wrote:
>>> > > > if version > 3.004001
>>> > > if perl_version >= 5.010000
>>> > > body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
>>> > > endif
>>> > > endif
>>> > > If this works now in spamassassin 3.3.2, problem solved, can i
>>> send > bitcoins
>>> > somewhere ? :)
>>>
>>> It "works" in 3.3.2 *IF* you accept the warning about perl_version
>>> being non-numeric that this entire thread is about. The
>>> non-5.8.8-compatible RE is skipped, because the perl_version
>>> conditional fails to false on the type warning and doesn't include the
>>> rule.
>>
>> Would a corrected syntax version of this work?
>>
>> if version > 3.004001 && perl_version >= 5.010000
>> body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
>> endif
>
> Yes. That *does* work.
>
> Thank you! I think you just solved it

exactly that's what i menat with "from my knowledge the 'if
perl_version' should not get touched in that case at all"

if($a > 1 && undefined_function())
{

}

in PHP will also not throw an error when $a <= 1
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 30. nov. 2014 23.00.54 John Hardin <jhardin@impsec.org> wrote:

> >> if version > 3.004001
> >> if perl_version >= 5.010000
> >> body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
> >> endif
> >> endif
> >
> > If this works now in spamassassin 3.3.2, problem solved, can i send bitcoins
> > somewhere ? :)
>
> It "works" in 3.3.2 *IF* you accept the warning about perl_version being
> non-numeric that this entire thread is about. The non-5.8.8-compatible RE
> is skipped, because the perl_version conditional fails to false on the
> type warning and doesn't include the rule.

So rules are brokken in 3..3.2 ?

As i understand if check above is that perl version is not checked since
version is not 3.4.1 eg trunk sa atleast

Why is version brokken aswell ?

Giving up :(
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 30. nov. 2014 23.15.50 "Kevin A. McGrail" <KMcGrail@PCCC.com> wrote:

> >>> if version > 3.004001
> >>> if perl_version >= 5.010000
> >>> body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
> >>> endif
> >>> endif

> What do you see wrong with the use of the can/has solution that both
> Mark and I proposed? I think it will be trivial and should not cause
> any errors for older SA's.

Why does the above not work aswell ?
Re: Argument "perl_version" isn't numeric [ In reply to ]
John Hardin wrote:
> I underestimated the reaction to having such a warning emitted. I will
> disable that rule until the perl_version catability is offically released.

I wanted to take a moment to say thank you John for working with the
community to resolve this problem. That just by itself is a wonderful
thing! We have all dealt with bad upstreams so often that some of us
get punchy and expect ill from all of them and some of us react badly
ourselves. That is our fault. Sorry. We should do better. We can
do better. (Everyone out there reading this listening? Do better!)

We know that you were working in good faith to improve SpamAssassin
when you submitted that rule. Okay. So it didn't work out as you
intended. Thank you for working with the community to fix the
problem. We all make mistakes. We have all been there at some point
or another. I can't cast any stones. It is water under the bridge
now. We will get over it. :-)

I know that we have all benefited from your long efforts with
SpamAssassin. I am hoping this won't make you gun-shy from continuing
your fine work on the project. Please don't let this minor bump in
the road discourage you from future work. That would be a tragedy for
the project and for the users.

Please keep up the good work!

Bob
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 2014-11-30 14:29, John Hardin wrote:
> On Sun, 30 Nov 2014, jdow wrote:
>
>>> On Sun, 30 Nov 2014, Benny Pedersen wrote:
>>> > On 30. nov. 2014 22.15.12 John Hardin <jhardin@impsec.org> wrote:
>>> > > > if version > 3.004001
>>> > > if perl_version >= 5.010000
>>> > > body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
>>> > > endif
>>> > > endif
>>> > > If this works now in spamassassin 3.3.2, problem solved, can i send >
>>> bitcoins
>>> > somewhere ? :)
>>>
>>> It "works" in 3.3.2 *IF* you accept the warning about perl_version
>>> being non-numeric that this entire thread is about. The
>>> non-5.8.8-compatible RE is skipped, because the perl_version
>>> conditional fails to false on the type warning and doesn't include the
>>> rule.
>>
>> Would a corrected syntax version of this work?
>>
>> if version > 3.004001 && perl_version >= 5.010000
>> body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
>> endif
>
> Yes. That *does* work.
>
> Thank you! I think you just solved it.

Here is another idea that might be helpful if....

if ((ref( perl_version ) == SCALAR ) && (perl_version >= 5.010000))
body yatta yatta
endif

Simply determine that the data type for perl_version will work when evaluating
the second half if the if.

{^_^}
{^_^}
Re: Argument "perl_version" isn't numeric [ In reply to ]
On 2014-11-30 14:30, Kevin A. McGrail wrote:
> On 11/30/2014 5:20 PM, jdow wrote:
>> Would a corrected syntax version of this work?
>>
>> if version > 3.004001 && perl_version >= 5.010000
>> body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
>> endif
>>
>> {^_^}
>
> The core issue is that only SA currently in trunk contains the code for the if
> functionality on the perl_version.
>
> So I believe any use of perl_version is likely to throw warnings unless people
> are using SA from svn trunk.
>
> Regards,
> KAM

Here my pertinent question is when does the error get produced? Is it during
evaluation of the expression or during a syntax check for the line?

{^_^}

1 2 3 4 5 6  View All