Mailing List Archive

On Sat, Nov 29, 2014 at 5:25 AM, Niamh Holding <niamh@fullbore.co.uk> wrote:
>
> Hello
>
> Anyone else seen this in v3.4.0?
>
> sa-learn --dump magic
> Argument "perl_version" isn't numeric in numeric ge (>=) at (eval 530) line 2.
> Argument "perl_version" isn't numeric in numeric ge (>=) at (eval 1023) line 2.

Last night's 3.003002 update spit out this:
Argument "perl_version" isn't numeric in numeric ge (>=) at (eval 490) line 1.
Argument "perl_version" isn't numeric in numeric ge (>=) at (eval
1000) line 1.

-Jim P.

Am 29.11.2014 um 11:39 schrieb Jim Popovitch:
> On Sat, Nov 29, 2014 at 5:25 AM, Niamh Holding <niamh@fullbore.co.uk> wrote:
>>
>> Hello
>>
>> Anyone else seen this in v3.4.0?
>>
>> sa-learn --dump magic
>> Argument "perl_version" isn't numeric in numeric ge (>=) at (eval 530) line 2.
>> Argument "perl_version" isn't numeric in numeric ge (>=) at (eval 1023) line 2.
>
> Last night's 3.003002 update spit out this:
> Argument "perl_version" isn't numeric in numeric ge (>=) at (eval 490) line 1.
> Argument "perl_version" isn't numeric in numeric ge (>=) at (eval
> 1000) line 1.

the same here with perl-5.18.4-291.fc20.x86_64

Argument "perl_version" isn't numeric in numeric ge (>=) at (eval 652)
line 1.
Argument "perl_version" isn't numeric in numeric ge (>=) at (eval 1145)
line 1.
29-Nov-2014 05:25:31: SpamAssassin: Update processed successfully

-----Original Message-----
From: Martin [mailto:marti@ntlworld.com]
Sent: Saturday, November 29, 2014 10:58 AM
To: 'Niamh Holding'
Subject: RE: Argument "perl_version" isn't numeric

> -----Original Message-----
> From: Niamh Holding [mailto:niamh@fullbore.co.uk]
> Sent: Saturday, November 29, 2014 10:26 AM
> To: users@spamassassin.apache.org
> Subject: Argument "perl_version" isn't numeric
>
>
> Hello
>
> Anyone else seen this in v3.4.0?
>
> sa-learn --dump magic
> Argument "perl_version" isn't numeric in numeric ge (>=) at (eval 530)
> line 2.
> Argument "perl_version" isn't numeric in numeric ge (>=) at (eval
> 1023) line 2.
> 0.000 0 3 0 non-token data: bayes
> db version
> 0.000 0 916480 0 non-token data: nspam
> 0.000 0 641170 0 non-token data: nham
> 0.000 0 176425 0 non-token data: ntokens
> 0.000 0 1415097712 0 non-token data: oldest atime
> 0.000 0 1417254571 0 non-token data: newest atime
> 0.000 0 1417250274 0 non-token data: last
> journal sync atime
> 0.000 0 1417231548 0 non-token data: last
> expiry atime
> 0.000 0 0 0 non-token data: last
> expire atime delta
> 0.000 0 0 0 non-token data: last
> expire reduction count
>
> --
> Best regards,
> Niamh mailto:niamh@fullbore.co.uk

Since cron ran sa-update last night, I get these errors running sa-compile,
sa-learn and spamassassin --lint, which showed it happening after reading
72_active.cf.

I had just re-installed spamassassin thinking something was broken my end,
glad it's not just me.

Martin

I seem to have found the problems in 72active.cf

if perl_version >= 5.010000
meta PDS_FROM_2_EMAILS __PDS_FROM_2_EMAILS && !__VIA_ML &&
!__VIA_RESIGNER
endif

And

if perl_version >= 5.010000
header __PDS_FROM_2_EMAILS From =~
/^\W+([\w+.-]+\@[\w.-]+\.\w\w++)(?:[^\n\w<]{0,80})?<(?!\1)[^\n\s]*\@/i
endif

I have hashed them out and all seems fine now

On Sat, 2014-11-29 at 10:25 +0000, Niamh Holding wrote:
> Hello
>
> Anyone else seen this in v3.4.0?
>
Yes, but with 3.3.2, not 3.4.0.

Last night was the first time I've ever seen it. It was displayed by the
sa_update cron job.


Martin

There were changes made but I had a feeling they might not be backwards compatible. Will look at changing that to a has/can function but leave the new perl version code for future use.
Regards,
KAM

On November 29, 2014 6:32:15 AM EST, Martin <marti@ntlworld.com> wrote:
>
>I seem to have found the problems in 72active.cf
>
>if perl_version >= 5.010000
> meta PDS_FROM_2_EMAILS __PDS_FROM_2_EMAILS && !__VIA_ML &&
>!__VIA_RESIGNER
>endif
>
>And
>
>if perl_version >= 5.010000
> header __PDS_FROM_2_EMAILS From =~
>/^\W+([\w+.-]+\@[\w.-]+\.\w\w++)(?:[^\n\w<]{0,80})?<(?!\1)[^\n\s]*\@/i
>endif
>
>I have hashed them out and all seems fine now

Am 29.11.2014 um 15:11 schrieb Kevin A. McGrail:
> There were changes made but I had a feeling they might not be backwards
> compatible. Will look at changing that to a has/can function but leave
> the new perl version code for future use.

that hapens also with a recent perl-5.18 while the old rule did not have
a problem on such setups but now the "if perl_version >= 5.010000" seems
to not work as expected on old as well as recent environments

> On November 29, 2014 6:32:15 AM EST, Martin <marti@ntlworld.com> wrote:
>
>
> I seem to have found the problems in72active.cf <http://72active.cf>
>
> if perl_version >= 5.010000
> meta PDS_FROM_2_EMAILS __PDS_FROM_2_EMAILS && !__VIA_ML &&
> !__VIA_RESIGNER
> endif
>
> And
>
> if perl_version >= 5.010000
> header __PDS_FROM_2_EMAILS From =~
> /^\W+([\w+.-]+\@[\w.-]+\.\w\w++)(?:[^\n\w<]{0,80})?<(?!\1)[^\n\s]*\@/i
> endif
>
> I have hashed them out and all seems fine now

On Sat, 2014-11-29 at 15:24 +0100, Reindl Harald wrote:
>
> Am 29.11.2014 um 15:11 schrieb Kevin A. McGrail:
> > There were changes made but I had a feeling they might not be backwards
> > compatible. Will look at changing that to a has/can function but leave
> > the new perl version code for future use.
>
> that hapens also with a recent perl-5.18 while the old rule did not have
> a problem on such setups but now the "if perl_version >= 5.010000" seems
> to not work as expected on old as well as recent environments
>
And 5.16.3 too

....yeah, I know I need an upgrade but I just can't get a round tuit.



Martin

It is a Spamassassin code change to try and limit rules that require a specific version of perl.
Regards,
KAM

On November 29, 2014 9:53:16 AM EST, Martin Gregorie <martin@gregorie.org> wrote:
>On Sat, 2014-11-29 at 15:24 +0100, Reindl Harald wrote:
>>
>> Am 29.11.2014 um 15:11 schrieb Kevin A. McGrail:
>> > There were changes made but I had a feeling they might not be
>backwards
>> > compatible. Will look at changing that to a has/can function but
>leave
>> > the new perl version code for future use.
>>
>> that hapens also with a recent perl-5.18 while the old rule did not
>have
>> a problem on such setups but now the "if perl_version >= 5.010000"
>seems
>> to not work as expected on old as well as recent environments
>>
>And 5.16.3 too
>
>....yeah, I know I need an upgrade but I just can't get a round tuit.
>
>
>
>Martin

On Sat, 29 Nov 2014, Niamh Holding wrote:

> Anyone else seen this in v3.4.0?
>
> sa-learn --dump magic
> Argument "perl_version" isn't numeric in numeric ge (>=) at (eval 530) line 2.
> Argument "perl_version" isn't numeric in numeric ge (>=) at (eval 1023) line 2.

Please see https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7107
and https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7108

This is just a warning.

Unfortunately this can't be hidden from the parser using
if version > 3.004000
as the parser will still try to parse stuff inside the false branch of a
conditions.

I underestimated the reaction to having such a warning emitted. I will
disable that rule until the perl_version catability is offically released.

--
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
-----------------------------------------------------------------------
"Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never
does quite what I want. I wish Christopher Robin was here."
-- Peter da Silva in a.s.r
-----------------------------------------------------------------------
26 days until Christmas

Hello John,

Saturday, November 29, 2014, 6:21:01 PM, you wrote:

JH> This is just a warning.

I guessed given that the bayes lesrning carried on after.

--
Best regards,
Niamh mailto:niamh@fullbore.co.uk

On 29. nov. 2014 17.14.44 "Kevin A. McGrail" <KMcGrail@PCCC.com> wrote:

> It is a Spamassassin code change to try and limit rules that require a
> specific version of perl.
> Regards,

Upgraded here to latest trunk version of sa, there is it working as
designed, but on older 3.4.1, 3.4.0, 3.3.2 it fails

On Sat, 29 Nov 2014, Benny Pedersen wrote:

> On 29. nov. 2014 17.14.44 "Kevin A. McGrail" <KMcGrail@PCCC.com> wrote:
>
>> It is a Spamassassin code change to try and limit rules that require a
>> specific version of perl.
>
> Upgraded here to latest trunk version of sa, there is it working as designed,
> but on older 3.4.1, 3.4.0, 3.3.2 it fails

Of course it fails, they don't recognize "perl_version" in a conditional.
If that construct is ever used to protect rules that use more-recent perl
syntax, we will have to accept that older SA will behave this way.

However, it is a *warning*, not a fatal error. And it's better than the
rule killing lint and blocking sa-update completely on an install that
uses an older perl.

--
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
-----------------------------------------------------------------------
"Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never
does quite what I want. I wish Christopher Robin was here."
-- Peter da Silva in a.s.r
-----------------------------------------------------------------------
26 days until Christmas

Am 29.11.2014 um 23:27 schrieb John Hardin:
> On Sat, 29 Nov 2014, Benny Pedersen wrote:
>
>> On 29. nov. 2014 17.14.44 "Kevin A. McGrail" <KMcGrail@PCCC.com> wrote:
>>
>>> It is a Spamassassin code change to try and limit rules that require a
>>> specific version of perl.
>>
>> Upgraded here to latest trunk version of sa, there is it working as
>> designed, but on older 3.4.1, 3.4.0, 3.3.2 it fails
>
> Of course it fails, they don't recognize "perl_version" in a
> conditional. If that construct is ever used to protect rules that use
> more-recent perl syntax, we will have to accept that older SA will
> behave this way.
>
> However, it is a *warning*, not a fatal error. And it's better than the
> rule killing lint and blocking sa-update completely on an install that
> uses an older perl

don't get me wrong but this *warning* triggers cron mails and spits
messages in case of every SA related command - that's unacceptable and
in fact worser than without that check

before *only* outdated perl versions where affected, now it hits also
recent Fedora setups working before without any warning and with that
rule included

if that rule can't work in most environments and not made conditionally
it has to be dropped at all because it has more drawbacks than benefits

On Sun, 30 Nov 2014, Reindl Harald wrote:
> Am 29.11.2014 um 23:27 schrieb John Hardin:
>>
>> However, it is a *warning*, not a fatal error. And it's better than the
>> rule killing lint and blocking sa-update completely on an install that
>> uses an older perl
>
> don't get me wrong but this *warning* triggers cron mails and spits messages
> in case of every SA related command - that's unacceptable and in fact worser
> than without that check
>
> before *only* outdated perl versions where affected, now it hits also recent
> Fedora setups working before without any warning and with that rule included

As I said, I underestimated the reaction to doing that.

> if that rule can't work in most environments and not made conditionally it
> has to be dropped at all because it has more drawbacks than benefits

It has already been commented out in my sandbox.

But this effectively means we cannot add new features to SA conditionals
because they might do this to older installs.

--
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
-----------------------------------------------------------------------
"Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never
does quite what I want. I wish Christopher Robin was here."
-- Peter da Silva in a.s.r
-----------------------------------------------------------------------
26 days until Christmas

On Sat, 2014-11-29 at 20:39 -0800, John Hardin wrote:
> But this effectively means we cannot add new features to SA conditionals
> because they might do this to older installs.
>
Can SA set a $too_old flag to say that that the Perl version number
check failed?

If so, it seems the me that, at runtime, it would be reasonable to
exclude new version-dependent features if either the $too_old flag is
set or the version number is lower than the feature needs. It would also
be reasonable for sa_update to report the exclusion since that serves to
remind the sysadmin to upgrade.


Martin

> -----Original Message-----
> From: Martin Gregorie [mailto:martin@gregorie.org]
> Sent: Sunday, November 30, 2014 11:08 AM
> To: users@spamassassin.apache.org
> Subject: Re: Argument "perl_version" isn't numeric
>
> On Sat, 2014-11-29 at 20:39 -0800, John Hardin wrote:
> > But this effectively means we cannot add new features to SA
> > conditionals because they might do this to older installs.
> >
> Can SA set a $too_old flag to say that that the Perl version
> number check failed?
>
> If so, it seems the me that, at runtime, it would be
> reasonable to exclude new version-dependent features if
> either the $too_old flag is set or the version number is
> lower than the feature needs. It would also be reasonable for
> sa_update to report the exclusion since that serves to remind
> the sysadmin to upgrade.
>
>
> Martin
>

Personally I don’t want any warning messages unless something has failed.

Yesterday and again this morning I was getting warning emails every 5 minutes from cron jobs, which is really annoying.

Will the file available via sa-update be the commented out one from tonight? Or do I need to turn sa-update off for a while?

Martin

Am 30.11.2014 um 05:39 schrieb John Hardin:
> On Sun, 30 Nov 2014, Reindl Harald wrote:
>> Am 29.11.2014 um 23:27 schrieb John Hardin:
>>>
>>> However, it is a *warning*, not a fatal error. And it's better than the
>>> rule killing lint and blocking sa-update completely on an install that
>>> uses an older perl
>>
>> don't get me wrong but this *warning* triggers cron mails and spits
>> messages in case of every SA related command - that's unacceptable and
>> in fact worser than without that check
>>
>> before *only* outdated perl versions where affected, now it hits also
>> recent Fedora setups working before without any warning and with that
>> rule included
>
> As I said, I underestimated the reaction to doing that.
>
>> if that rule can't work in most environments and not made
>> conditionally it has to be dropped at all because it has more
>> drawbacks than benefits
>
> It has already been commented out in my sandbox.
>
> But this effectively means we cannot add new features to SA conditionals
> because they might do this to older installs

which new features?
which newer perl?

spamassassin-3.4.0-7.fc20.x86_64
perl-5.18.4-291.fc20.x86_64

that "fix" for older versions is just broken and leads to warnings on a
recent SA with a recent perl while as first people with outdated setups
complained all was fine here

On 11/30/2014 04:08 AM, Martin Gregorie wrote:
> On Sat, 2014-11-29 at 20:39 -0800, John Hardin wrote:
>> But this effectively means we cannot add new features to SA conditionals
>> because they might do this to older installs.
> Can SA set a $too_old flag to say that that the Perl version number
> check failed?
>
> If so, it seems the me that, at runtime, it would be reasonable to
> exclude new version-dependent features if either the $too_old flag is
> set or the version number is lower than the feature needs. It would also
> be reasonable for sa_update to report the exclusion since that serves to
> remind the sysadmin to upgrade.
So just so I understand something is it expected that those of us with
RHEL 5.11 and RHEL 6.6 servers are expected to upgrade our perl versions
just for spamassassin's sa-update? The whole idea of running servers
with those versions of server software is for stability. I have no
intention of running any other version of perl then what comes with the
OS. As such I do not expect to get any warnings period. Spamassassin or
sa-update putting out warnings as a public service is crazy.

--
Paul (ganci@nurdog.com)

This issue has been discussed here:

http://askubuntu.com/questions/554537/argument-perl-version-isnt-numeric-in-numeric-ge-at-eval-534-line-1

There is a link to patches for 2 Perl modules that turn off
the warnings. Worked for me when I applied those patches.

Ted

On 11/30/2014 4:42 AM, Reindl Harald wrote:
>
> Am 30.11.2014 um 05:39 schrieb John Hardin:
>> On Sun, 30 Nov 2014, Reindl Harald wrote:
>>> Am 29.11.2014 um 23:27 schrieb John Hardin:
>>>>
>>>> However, it is a *warning*, not a fatal error. And it's better than the
>>>> rule killing lint and blocking sa-update completely on an install that
>>>> uses an older perl
>>>
>>> don't get me wrong but this *warning* triggers cron mails and spits
>>> messages in case of every SA related command - that's unacceptable and
>>> in fact worser than without that check
>>>
>>> before *only* outdated perl versions where affected, now it hits also
>>> recent Fedora setups working before without any warning and with that
>>> rule included
>>
>> As I said, I underestimated the reaction to doing that.
>>
>>> if that rule can't work in most environments and not made
>>> conditionally it has to be dropped at all because it has more
>>> drawbacks than benefits
>>
>> It has already been commented out in my sandbox.
>>
>> But this effectively means we cannot add new features to SA conditionals
>> because they might do this to older installs
>
> which new features?
> which newer perl?
>
> spamassassin-3.4.0-7.fc20.x86_64
> perl-5.18.4-291.fc20.x86_64
>
> that "fix" for older versions is just broken and leads to warnings on a
> recent SA with a recent perl while as first people with outdated setups
> complained all was fine here
>

On 11/29/2014 8:39 PM, John Hardin wrote:
> On Sun, 30 Nov 2014, Reindl Harald wrote:
>> Am 29.11.2014 um 23:27 schrieb John Hardin:
>>>
>>> However, it is a *warning*, not a fatal error. And it's better than the
>>> rule killing lint and blocking sa-update completely on an install that
>>> uses an older perl
>>
>> don't get me wrong but this *warning* triggers cron mails and spits
>> messages in case of every SA related command - that's unacceptable and
>> in fact worser than without that check
>>
>> before *only* outdated perl versions where affected, now it hits also
>> recent Fedora setups working before without any warning and with that
>> rule included
>
> As I said, I underestimated the reaction to doing that.
>
>> if that rule can't work in most environments and not made
>> conditionally it has to be dropped at all because it has more
>> drawbacks than benefits
>
> It has already been commented out in my sandbox.
>
> But this effectively means we cannot add new features to SA conditionals
> because they might do this to older installs.
>

No, just release patches to the older versions to Conf.pm and Parser.pm

These are not COMPILED modules so it is easy to patch them.

The people who even notice the warnings are going to be competent enough
to run patch, and for the people who are running SpamAssassin who aren't
competent enough to be able to do that, I doubt they will be noticing
log entries.

Ted

On 11/30/14 12:34 PM, "Paul R. Ganci" <ganci@nurdog.com> wrote:

>So just so I understand something is it expected that those of us with
>RHEL 5.11 and RHEL 6.6 servers are expected to upgrade our perl versions
>just for spamassassin's sa-update? The whole idea of running servers
>with those versions of server software is for stability.

Yep. And the whole point of running SpamAssassin with sa-update is for
flexibility and agility. The two goals are necessarily in conflict. So...
Looks like you have a few options:
1) Don't run SA on RHEL
2) Run SA on RHEL but turn off sa-update and sacrifice automated reaction
to new spam in the interest of keeping your system static
3) Run SA on RHEL but upgrade perl and SpamAssassin using
third-party-packages or update from source
4) Run SA on RHEL with system perl and system SpamAssassin, run sa-update
with output redirected to /dev/null, and write your own monitoring script
to tell you if sa-update broke spamd
5) Run SA in some kind of container or VM so you can optimize for
spamassassin without tainting the purity of your RHEL install
--
Dave Pooser
Cat-Herder-in-Chief, Pooserville.com
"...Life is not a journey to the grave with the intention of arriving
safely in one pretty and well-preserved piece, but to slide across the
finish line broadside, thoroughly used up, worn out, leaking oil, and
shouting GERONIMO!!!" -- Bill McKenna

On Sun, 30 Nov 2014, Reindl Harald wrote:

>
> Am 30.11.2014 um 05:39 schrieb John Hardin:
>> On Sun, 30 Nov 2014, Reindl Harald wrote:
>> > if that rule can't work in most environments and not made
>> > conditionally it has to be dropped at all because it has more
>> > drawbacks than benefits
>>
>> But this effectively means we cannot add new features to SA conditionals
>> because they might do this to older installs
>
> which new features?

The perl version check in a conditional.

Trunk SA supports doing that now. But if actually *using* that feature,
even once it's officially released, results in unacceptable warnings in
older SA installs, then at what point can the new feature *actually be
used*?

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

On Sun, 30 Nov 2014, Ted Mittelstaedt wrote:

> This issue has been discussed here:
>
> http://askubuntu.com/questions/554537/argument-perl-version-isnt-numeric-in-numeric-ge-at-eval-534-line-1
>
> There is a link to patches for 2 Perl modules that turn off
> the warnings. Worked for me when I applied those patches.
>
> Ted

Yes, distro maintainers applying the patch that implements perl_version
support is another way to address this problem. It's dirt simple and
should be compatible back a long ways.

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

Am 30.11.2014 um 19:44 schrieb Ted Mittelstaedt:
> This issue has been discussed here:
>
> http://askubuntu.com/questions/554537/argument-perl-version-isnt-numeric-in-numeric-ge-at-eval-534-line-1
>
> There is a link to patches for 2 Perl modules that turn off
> the warnings. Worked for me when I applied those patches.

unacceptable workaround

frankly doing so may get you fired because you risk to break other
packages from the operating system with unknown side-affects and
recommend such actions should start with a big warning

* Fedora 20 is one of the most recent OS environments
* SpamAssassin 3.4.0 is the recent upstream version
* Perl 5.18.4 is recent (Fri Oct 03 2014)
"if perl_version >= 5.010000" must not throw warning with perl 5.18.x

nobody right in has mind is patching perl-modules installed with the OS
package-managment in case of recent SA installed with the
package-managment to work around broken rules on a production server

the issue was introduced with SA rule-updates and has to be fixed there

> On 11/30/2014 4:42 AM, Reindl Harald wrote:
>>
>> Am 30.11.2014 um 05:39 schrieb John Hardin:
>>> On Sun, 30 Nov 2014, Reindl Harald wrote:
>>>> Am 29.11.2014 um 23:27 schrieb John Hardin:
>>>>>
>>>>> However, it is a *warning*, not a fatal error. And it's better than
>>>>> the
>>>>> rule killing lint and blocking sa-update completely on an install that
>>>>> uses an older perl
>>>>
>>>> don't get me wrong but this *warning* triggers cron mails and spits
>>>> messages in case of every SA related command - that's unacceptable and
>>>> in fact worser than without that check
>>>>
>>>> before *only* outdated perl versions where affected, now it hits also
>>>> recent Fedora setups working before without any warning and with that
>>>> rule included
>>>
>>> As I said, I underestimated the reaction to doing that.
>>>
>>>> if that rule can't work in most environments and not made
>>>> conditionally it has to be dropped at all because it has more
>>>> drawbacks than benefits
>>>
>>> It has already been commented out in my sandbox.
>>>
>>> But this effectively means we cannot add new features to SA conditionals
>>> because they might do this to older installs
>>
>> which new features?
>> which newer perl?
>>
>> spamassassin-3.4.0-7.fc20.x86_64
>> perl-5.18.4-291.fc20.x86_64
>>
>> that "fix" for older versions is just broken and leads to warnings on a
>> recent SA with a recent perl while as first people with outdated setups
>> complained all was fine here

On 2014-11-30 03:08, Martin Gregorie wrote:
> On Sat, 2014-11-29 at 20:39 -0800, John Hardin wrote:
>> But this effectively means we cannot add new features to SA conditionals
>> because they might do this to older installs.
>>
> Can SA set a $too_old flag to say that that the Perl version number
> check failed?
>
> If so, it seems the me that, at runtime, it would be reasonable to
> exclude new version-dependent features if either the $too_old flag is
> set or the version number is lower than the feature needs. It would also
> be reasonable for sa_update to report the exclusion since that serves to
> remind the sysadmin to upgrade.
>
>
> Martin

That gets unnecessarily annoying to sysadmins running things like Scientific
Linux 6. Spamassassin is not going to get updated to 3.4.whizzy. And going off
distro often invites annoying problems that require a lot of effort to deal
with. I know *I* do not like to invite problems when I can stay on distro and
use the freed up time for other important work.

Now, if you guys could work with RHEL, SUSE, and other major distros to make it
easy for them to upgrade spamassassin that situation might change. But SA seems
to be moderately low on the criticality lists for major distros.

{^_^} Joanne

Am 30.11.2014 um 19:48 schrieb Ted Mittelstaedt:
> On 11/29/2014 8:39 PM, John Hardin wrote:
>>> if that rule can't work in most environments and not made
>>> conditionally it has to be dropped at all because it has more
>>> drawbacks than benefits
>>
>> It has already been commented out in my sandbox.
>>
>> But this effectively means we cannot add new features to SA conditionals
>> because they might do this to older installs.
>>
>
> No, just release patches to the older versions to Conf.pm and Parser.pm
>
> These are not COMPILED modules so it is easy to patch them.
>
> The people who even notice the warnings are going to be competent enough
> to run patch, and for the people who are running SpamAssassin who aren't
> competent enough to be able to do that, I doubt they will be noticing
> log entries

stop that polemic! competent people would not patch files from a RPM package

the solution is not to publish rules not working on the last official SA
upstream version

[root@mail-gw:~]$ rpm -q --file
/usr/share/perl5/vendor_perl/Mail/SpamAssassin/Conf.pm
spamassassin-3.4.0-7.fc20.x86_64

On 2014-11-30 10:48, Ted Mittelstaedt wrote:
>
>
> On 11/29/2014 8:39 PM, John Hardin wrote:
>> On Sun, 30 Nov 2014, Reindl Harald wrote:
>>> Am 29.11.2014 um 23:27 schrieb John Hardin:
>>>>
>>>> However, it is a *warning*, not a fatal error. And it's better than the
>>>> rule killing lint and blocking sa-update completely on an install that
>>>> uses an older perl
>>>
>>> don't get me wrong but this *warning* triggers cron mails and spits
>>> messages in case of every SA related command - that's unacceptable and
>>> in fact worser than without that check
>>>
>>> before *only* outdated perl versions where affected, now it hits also
>>> recent Fedora setups working before without any warning and with that
>>> rule included
>>
>> As I said, I underestimated the reaction to doing that.
>>
>>> if that rule can't work in most environments and not made
>>> conditionally it has to be dropped at all because it has more
>>> drawbacks than benefits
>>
>> It has already been commented out in my sandbox.
>>
>> But this effectively means we cannot add new features to SA conditionals
>> because they might do this to older installs.
>>
>
> No, just release patches to the older versions to Conf.pm and Parser.pm
>
> These are not COMPILED modules so it is easy to patch them.
>
> The people who even notice the warnings are going to be competent enough
> to run patch, and for the people who are running SpamAssassin who aren't
> competent enough to be able to do that, I doubt they will be noticing log entries.
>
> Ted

Put a sock in it, Ted. For some, perhaps you, sysadmin is a hobby. For others it
is a necessary pain in the ass. Going off distro for some "patches" is precisely
what we wish to avoid with these long term professional distros. And you're
telling US that we have to risk the stability of the system? "Brown vaguely
stinky soft spludgy material such as emanates from the South end of a North
facing fertile male bovine."

{`,'}

Now now, be nice!

This issue affects ANY piece of OSS software that has multiple dependencies.

SpamAssassin has HUNDREDS of dependencies on different Perl modules.

Using your nasty logic if the author of Perl::Date or whatever
decided to make a change that broke SA than it's our tough luck, eh?

The authors of any OSS project - like SA, like any of the modules that
SA depends on - that depends on OTHER OSS
projects need to navigate this dependency hell with same guiding
principle that is used for Sendmail and other OSS projects:

Be liberal in what you accept, conservative in what you send.

Meaning this - you write a package like SA, or a package like
Perl::Date, that has published interfaces and API's, you need to do your
best to maintain consistency, and you need to be accepting
of changes that others make to the best of your ability.

If the SA authors want to add bells and whistles to a functioning design
that require certain newer versions of dependent programs that's fine -
but they need to install logic in those bells and whistles that either
makes them backwards compatible with older dependent programs or turns
those bells and whistles off.

If it turns out that an older released SA has a design flaw that makes
that impossible to do then patches need to be released for those older
versions.

There's no need to take a scorched Earth My way or the highway approach.

Ted

On 11/30/2014 10:50 AM, Dave Pooser wrote:
> On 11/30/14 12:34 PM, "Paul R. Ganci"<ganci@nurdog.com> wrote:
>
>> So just so I understand something is it expected that those of us with
>> RHEL 5.11 and RHEL 6.6 servers are expected to upgrade our perl versions
>> just for spamassassin's sa-update? The whole idea of running servers
>> with those versions of server software is for stability.
>
> Yep. And the whole point of running SpamAssassin with sa-update is for
> flexibility and agility. The two goals are necessarily in conflict. So...
> Looks like you have a few options:
> 1) Don't run SA on RHEL
> 2) Run SA on RHEL but turn off sa-update and sacrifice automated reaction
> to new spam in the interest of keeping your system static
> 3) Run SA on RHEL but upgrade perl and SpamAssassin using
> third-party-packages or update from source
> 4) Run SA on RHEL with system perl and system SpamAssassin, run sa-update
> with output redirected to /dev/null, and write your own monitoring script
> to tell you if sa-update broke spamd
> 5) Run SA in some kind of container or VM so you can optimize for
> spamassassin without tainting the purity of your RHEL install

On 11/30/2014 11:50 AM, Dave Pooser wrote:
> On 11/30/14 12:34 PM, "Paul R. Ganci" <ganci@nurdog.com> wrote:
>
>> So just so I understand something is it expected that those of us with
>> RHEL 5.11 and RHEL 6.6 servers are expected to upgrade our perl versions
>> just for spamassassin's sa-update? The whole idea of running servers
>> with those versions of server software is for stability.
> Yep. And the whole point of running SpamAssassin with sa-update is for
> flexibility and agility. The two goals are necessarily in conflict. So...
> Looks like you have a few options:
> 1) Don't run SA on RHEL
> 2) Run SA on RHEL but turn off sa-update and sacrifice automated reaction
> to new spam in the interest of keeping your system static
> 3) Run SA on RHEL but upgrade perl and SpamAssassin using
> third-party-packages or update from source
> 4) Run SA on RHEL with system perl and system SpamAssassin, run sa-update
> with output redirected to /dev/null, and write your own monitoring script
> to tell you if sa-update broke spamd
> 5) Run SA in some kind of container or VM so you can optimize for
> spamassassin without tainting the purity of your RHEL install
You have to be joking if I am going to update my systems for sa-update.
It seems that this is a pretty much arrogant decision by spamassassin
development team. The problem is in sa-update. It should be fixed there.

--
Paul (ganci@nurdog.com)

On Sun, 30 Nov 2014, Dave Pooser wrote:

> On 11/30/14 12:34 PM, "Paul R. Ganci" <ganci@nurdog.com> wrote:
>
>> So just so I understand something is it expected that those of us with
>> RHEL 5.11 and RHEL 6.6 servers are expected to upgrade our perl versions
>> just for spamassassin's sa-update? The whole idea of running servers
>> with those versions of server software is for stability.
>
> Yep.

Um, nope. The whole point to this was to allow SA rules to deal gracefully
with older perl versions.

The problem at hand is not caused by the perl version that is installed,
and upgrading the version of perl will not fix it; it's caused by a single
rule that uses recent perl syntax (and which caused sa-update to fail lint
on perl 5.8.8) trying to avoid problems on older perl by using a brand new
SA feature, and use of that feature on older SA generates a warning.

I apologize, I thought that a warning was preferable to a fatal error, and
I underestimated the impact of the warning, and have again completely
disabled the rule in question until the situation is resolved, however
that ends up happening. This change did not go out in the last update,
hopefully it will be in the next.

> And the whole point of running SpamAssassin with sa-update is for
> flexibility and agility. The two goals are necessarily in conflict. So...
> Looks like you have a few options:
> 1) Don't run SA on RHEL
> 2) Run SA on RHEL but turn off sa-update and sacrifice automated reaction
> to new spam in the interest of keeping your system static
> 3) Run SA on RHEL but upgrade perl and SpamAssassin using
> third-party-packages or update from source
> 4) Run SA on RHEL with system perl and system SpamAssassin, run sa-update
> with output redirected to /dev/null, and write your own monitoring script
> to tell you if sa-update broke spamd
> 5) Run SA in some kind of container or VM so you can optimize for
> spamassassin without tainting the purity of your RHEL install

6) You patch, or RHEL (et. al.) patches the official SA distro package,
with the tiny change that implements perl_version support in conditionals
and avoids this warning, so that rule development can safely use perl
features from newer versions of perl without risking a *fatal* error in
sa-update at sites using older versions of perl.

7) SA implements some other more-complex, more-backwards-compatible method
of checking the version of perl in conditionals, such as a new function
that can be checked in a can().

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

Ted, I simply do not feel well enough just now to be nice. I reiterate my prior
observation about vaguely stinky and spludgy material such as emanates from the
South end of North facing fertile male bovines.

I have enough headaches with pure distro modules. I really REALLY *R*E*A*L*L*Y*
do not want to go through the nonsense again with off distro modules. I ran SA
off distro for a few years. I got tired of it. Too much stuff was starting to break.

Sorry if I am abusive - no - I'm not sorry. I feel like warmed over poo with
this blasted headcold. I DO NOT NEED THIS SORT OF AGGRAVATION JUST NOW PEEING ON
ME FROM MY LOGS.

{`,'}

On 2014-11-30 11:07, Ted Mittelstaedt wrote:
> Now now, be nice!
>
> This issue affects ANY piece of OSS software that has multiple dependencies.
>
> SpamAssassin has HUNDREDS of dependencies on different Perl modules.
>
> Using your nasty logic if the author of Perl::Date or whatever
> decided to make a change that broke SA than it's our tough luck, eh?
>
> The authors of any OSS project - like SA, like any of the modules that SA
> depends on - that depends on OTHER OSS
> projects need to navigate this dependency hell with same guiding
> principle that is used for Sendmail and other OSS projects:
>
> Be liberal in what you accept, conservative in what you send.
>
> Meaning this - you write a package like SA, or a package like Perl::Date, that
> has published interfaces and API's, you need to do your best to maintain
> consistency, and you need to be accepting
> of changes that others make to the best of your ability.
>
> If the SA authors want to add bells and whistles to a functioning design that
> require certain newer versions of dependent programs that's fine - but they need
> to install logic in those bells and whistles that either makes them backwards
> compatible with older dependent programs or turns those bells and whistles off.
>
> If it turns out that an older released SA has a design flaw that makes that
> impossible to do then patches need to be released for those older
> versions.
>
> There's no need to take a scorched Earth My way or the highway approach.
>
> Ted
>
> On 11/30/2014 10:50 AM, Dave Pooser wrote:
>> On 11/30/14 12:34 PM, "Paul R. Ganci"<ganci@nurdog.com> wrote:
>>
>>> So just so I understand something is it expected that those of us with
>>> RHEL 5.11 and RHEL 6.6 servers are expected to upgrade our perl versions
>>> just for spamassassin's sa-update? The whole idea of running servers
>>> with those versions of server software is for stability.
>>
>> Yep. And the whole point of running SpamAssassin with sa-update is for
>> flexibility and agility. The two goals are necessarily in conflict. So...
>> Looks like you have a few options:
>> 1) Don't run SA on RHEL
>> 2) Run SA on RHEL but turn off sa-update and sacrifice automated reaction
>> to new spam in the interest of keeping your system static
>> 3) Run SA on RHEL but upgrade perl and SpamAssassin using
>> third-party-packages or update from source
>> 4) Run SA on RHEL with system perl and system SpamAssassin, run sa-update
>> with output redirected to /dev/null, and write your own monitoring script
>> to tell you if sa-update broke spamd
>> 5) Run SA in some kind of container or VM so you can optimize for
>> spamassassin without tainting the purity of your RHEL install
>

John, if you make it a warning - warn ONCE not ever blessed time the file is run
and CLEARLY state this is a warning only and is not fatal. PLEASE PLEASE PLEASE

{o.o}

On 2014-11-30 11:11, John Hardin wrote:
> On Sun, 30 Nov 2014, Dave Pooser wrote:
>
>> On 11/30/14 12:34 PM, "Paul R. Ganci" <ganci@nurdog.com> wrote:
>>
>>> So just so I understand something is it expected that those of us with
>>> RHEL 5.11 and RHEL 6.6 servers are expected to upgrade our perl versions
>>> just for spamassassin's sa-update? The whole idea of running servers
>>> with those versions of server software is for stability.
>>
>> Yep.
>
> Um, nope. The whole point to this was to allow SA rules to deal gracefully with
> older perl versions.
>
> The problem at hand is not caused by the perl version that is installed, and
> upgrading the version of perl will not fix it; it's caused by a single rule that
> uses recent perl syntax (and which caused sa-update to fail lint on perl 5.8.8)
> trying to avoid problems on older perl by using a brand new SA feature, and use
> of that feature on older SA generates a warning.
>
> I apologize, I thought that a warning was preferable to a fatal error, and I
> underestimated the impact of the warning, and have again completely disabled the
> rule in question until the situation is resolved, however that ends up
> happening. This change did not go out in the last update, hopefully it will be
> in the next.
>
>> And the whole point of running SpamAssassin with sa-update is for
>> flexibility and agility. The two goals are necessarily in conflict. So...
>> Looks like you have a few options:
>> 1) Don't run SA on RHEL
>> 2) Run SA on RHEL but turn off sa-update and sacrifice automated reaction
>> to new spam in the interest of keeping your system static
>> 3) Run SA on RHEL but upgrade perl and SpamAssassin using
>> third-party-packages or update from source
>> 4) Run SA on RHEL with system perl and system SpamAssassin, run sa-update
>> with output redirected to /dev/null, and write your own monitoring script
>> to tell you if sa-update broke spamd
>> 5) Run SA in some kind of container or VM so you can optimize for
>> spamassassin without tainting the purity of your RHEL install
>
> 6) You patch, or RHEL (et. al.) patches the official SA distro package,
> with the tiny change that implements perl_version support in conditionals and
> avoids this warning, so that rule development can safely use perl features from
> newer versions of perl without risking a *fatal* error in sa-update at sites
> using older versions of perl.
>
> 7) SA implements some other more-complex, more-backwards-compatible method of
> checking the version of perl in conditionals, such as a new function that can be
> checked in a can().
>

On Sun, 30 Nov 2014, jdow wrote:

> John, if you make it a warning - warn ONCE not ever blessed time the file is
> run and CLEARLY state this is a warning only and is not fatal. PLEASE PLEASE
> PLEASE
>
> {o.o}

The reason it warns twice is the rule evaluation and promotion process
separates the two rules during publication. They are together in a single
if() in the sandbox file; if they were published that way there would only
be one warning. I don't know how complicated it would be to change that
behavior, probably very.

In the SA log it clearly states it's a warning. I don't know why that
information would be stripped when emitting to STDERR. And fixing that
wouldn't help existing SA installs.

--
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
-----------------------------------------------------------------------
We have to realize that people who run the government can and do
change. Our society and laws must assume that bad people -
criminals even - will run the government, at least part of the
time. -- John Gilmore
-----------------------------------------------------------------------
15 days until Bill of Rights day

On 30. nov. 2014 20.02.27 jdow <jdow@earthlink.net> wrote:

> Now, if you guys could work with RHEL, SUSE, and other major distros to make it
> easy for them to upgrade spamassassin that situation might change. But SA seems
> to be moderately low on the criticality lists for major distros.

I stopped using rpm based distro when redhat dropped support for redhat 8,
after that i changed to freebsd and gentoo, but to be more constructive to
rpm clients needs more attention to get svn version build as rpm packages

Ruleupdates should have being if version before if perl_version, so this
the test of perl was only done on svn version of sa, it have nothing to do
with update or change dependice of perl installed

On Sun, 30 Nov 2014, Benny Pedersen wrote:

> Ruleupdates should have being if version before if perl_version, so this the
> test of perl was only done on svn version of sa, it have nothing to do with
> update or change dependice of perl installed

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
if fnord > 0
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.

--
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
-----------------------------------------------------------------------
We have to realize that people who run the government can and do
change. Our society and laws must assume that bad people -
criminals even - will run the government, at least part of the
time. -- John Gilmore
-----------------------------------------------------------------------
15 days until Bill of Rights day

On 11/30/2014 10:59 AM, Reindl Harald wrote:
>
>
> Am 30.11.2014 um 19:44 schrieb Ted Mittelstaedt:
>> This issue has been discussed here:
>>
>> http://askubuntu.com/questions/554537/argument-perl-version-isnt-numeric-in-numeric-ge-at-eval-534-line-1
>>
>>
>> There is a link to patches for 2 Perl modules that turn off
>> the warnings. Worked for me when I applied those patches.
>
> unacceptable workaround
>
> frankly doing so may get you fired because you risk to break other
> packages from the operating system with unknown side-affects and
> recommend such actions should start with a big warning
>
> * Fedora 20 is one of the most recent OS environments
> * SpamAssassin 3.4.0 is the recent upstream version
> * Perl 5.18.4 is recent (Fri Oct 03 2014)
> "if perl_version >= 5.010000" must not throw warning with perl 5.18.x
>
> nobody right in has mind is patching perl-modules installed with the OS
> package-managment in case of recent SA installed with the
> package-managment to work around broken rules on a production server
>

This is an issue of degrees. Those patches came off the SA distro
they are not some 3rd parties idea of a great change that ought to be
made in SA. When the next version of SA is released those will be
incorporated in it - and if you run updates on your OS, assuming
your package maintainers are following the new releases of SA - your
going to get them eventually.

So your going to have to deal with those changes eventually as well as
any "unknown side effects"

> the issue was introduced with SA rule-updates and has to be fixed there
>

When the fix to allow older SA versions to silently accept the new
rule updates is a simple TEXT modification of 2 text Perl modules, you
are overreacting.

I agree that making such a change on a production server for something
like the operating system that is used by -everything- is risky. In
that case, perhaps it would have to rise to the importance of an
emergency security hole that was just discovered, for an out-of-band
patch to be made.

And of course, it was a bit too fast to make that change in SVN and not
give it a longer time to "cook" and for various distros to get updated
with it.

But in this case, you can make this MINOR change during an off-period,
give it 15 minutes and your going to know if it suddenly sends the CPU
to 100% or something, and you can pull it right back out ASAP.

The ENTIRE REASON that Perl modules are written in text and parsed
IS SO THEY CAN BE EASILY MODIFIED. That's the whole point of Perl.

This is a minor change to Conf.pm and Parser.pm. Those 2 modules are
only used in SA. Download and read the patches and decide if they are
significant or not.

Ted

>> On 11/30/2014 4:42 AM, Reindl Harald wrote:
>>>
>>> Am 30.11.2014 um 05:39 schrieb John Hardin:
>>>> On Sun, 30 Nov 2014, Reindl Harald wrote:
>>>>> Am 29.11.2014 um 23:27 schrieb John Hardin:
>>>>>>
>>>>>> However, it is a *warning*, not a fatal error. And it's better than
>>>>>> the
>>>>>> rule killing lint and blocking sa-update completely on an install
>>>>>> that
>>>>>> uses an older perl
>>>>>
>>>>> don't get me wrong but this *warning* triggers cron mails and spits
>>>>> messages in case of every SA related command - that's unacceptable and
>>>>> in fact worser than without that check
>>>>>
>>>>> before *only* outdated perl versions where affected, now it hits also
>>>>> recent Fedora setups working before without any warning and with that
>>>>> rule included
>>>>
>>>> As I said, I underestimated the reaction to doing that.
>>>>
>>>>> if that rule can't work in most environments and not made
>>>>> conditionally it has to be dropped at all because it has more
>>>>> drawbacks than benefits
>>>>
>>>> It has already been commented out in my sandbox.
>>>>
>>>> But this effectively means we cannot add new features to SA
>>>> conditionals
>>>> because they might do this to older installs
>>>
>>> which new features?
>>> which newer perl?
>>>
>>> spamassassin-3.4.0-7.fc20.x86_64
>>> perl-5.18.4-291.fc20.x86_64
>>>
>>> that "fix" for older versions is just broken and leads to warnings on a
>>> recent SA with a recent perl while as first people with outdated setups
>>> complained all was fine here
>

On 11/30/2014 11:06 AM, jdow wrote:
> On 2014-11-30 10:48, Ted Mittelstaedt wrote:
>>
>>
>> On 11/29/2014 8:39 PM, John Hardin wrote:
>>> On Sun, 30 Nov 2014, Reindl Harald wrote:
>>>> Am 29.11.2014 um 23:27 schrieb John Hardin:
>>>>>
>>>>> However, it is a *warning*, not a fatal error. And it's better than
>>>>> the
>>>>> rule killing lint and blocking sa-update completely on an install that
>>>>> uses an older perl
>>>>
>>>> don't get me wrong but this *warning* triggers cron mails and spits
>>>> messages in case of every SA related command - that's unacceptable and
>>>> in fact worser than without that check
>>>>
>>>> before *only* outdated perl versions where affected, now it hits also
>>>> recent Fedora setups working before without any warning and with that
>>>> rule included
>>>
>>> As I said, I underestimated the reaction to doing that.
>>>
>>>> if that rule can't work in most environments and not made
>>>> conditionally it has to be dropped at all because it has more
>>>> drawbacks than benefits
>>>
>>> It has already been commented out in my sandbox.
>>>
>>> But this effectively means we cannot add new features to SA conditionals
>>> because they might do this to older installs.
>>>
>>
>> No, just release patches to the older versions to Conf.pm and Parser.pm
>>
>> These are not COMPILED modules so it is easy to patch them.
>>
>> The people who even notice the warnings are going to be competent enough
>> to run patch, and for the people who are running SpamAssassin who aren't
>> competent enough to be able to do that, I doubt they will be noticing
>> log entries.
>>
>> Ted
>
> Put a sock in it, Ted. For some, perhaps you, sysadmin is a hobby. For
> others it is a necessary pain in the ass.

Sysadmining is a joy to me. It also happens to be one I am paid to do.

If it's a pain in the ass for you - I pity you. Your stuck in the wrong
job.

> Going off distro for some
> "patches" is precisely what we wish to avoid with these long term
> professional distros.

I think you mean what "I" wish to avoid.

> And you're telling US that we have to risk the
> stability of the system? "Brown vaguely stinky soft spludgy material
> such as emanates from the South end of a North facing fertile male bovine."
>

No I am telling you to use your head for something other than a place to
hang your hat. Read the patches. Decide if they are significant enough
to risk the stability of the system. If they are then don't apply them.

I have. They aren't. I applied them. As did many others on the thread
I posted, none of whom reported any ill effects.

As I said before, I really, really pity you and I'm sorry you feel so
trapped in your job. Honestly, there really is a better way to live.
Take up painting, music, whatever. Do what you love. Do it well and
people will pay you for it. And don't look back.

Ted

> {`,'}

On 11/30/14 1:07 PM, "Paul R. Ganci" <ganci@nurdog.com> wrote:

>You have to be joking if I am going to update my systems for sa-update.
>It seems that this is a pretty much arrogant decision by spamassassin
>development team. The problem is in sa-update. It should be fixed there.

You have to be joking if you think that spamassassin rules development
should forever be restricted to whatever crufty version of perl is still
present in the oldest still-supported vendor distro. The decision to
standardize on a 2006-era release of perl in RedHat 5 is not the fault of
the spamassassin team. The decision to run spamassassin on a distribution
that is constitutionally opposed to modern perl is not the fault of the
spamassassin team. The problem is in the system administrator who tries to
hammer every use case into the same square hole. It should be fixed there.
--
Dave Pooser
Cat-Herder-in-Chief, Pooserville.com
"...Life is not a journey to the grave with the intention of arriving
safely in one pretty and well-preserved piece, but to slide across the
finish line broadside, thoroughly used up, worn out, leaking oil, and
shouting GERONIMO!!!" -- Bill McKenna

Am 30.11.2014 um 20:58 schrieb Dave Pooser:
> On 11/30/14 1:07 PM, "Paul R. Ganci" <ganci@nurdog.com> wrote:
>
>> You have to be joking if I am going to update my systems for sa-update.
>> It seems that this is a pretty much arrogant decision by spamassassin
>> development team. The problem is in sa-update. It should be fixed there.
>
> You have to be joking if you think that spamassassin rules development
> should forever be restricted to whatever crufty version of perl is still
> present in the oldest still-supported vendor distro

what about people stop to contribute to that thread until the understand
what happens? "The problem is in sa-update. It should be fixed there" is
the correct answer - period

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

Am 30.11.2014 um 20:50 schrieb Ted Mittelstaedt:
> When the fix to allow older SA versions to silently accept the new
> rule updates is a simple TEXT modification of 2 text Perl modules, you
> are overreacting

no - i react correctly

* the problem was introduced with sa-update
* the problem has to be fixed with sa-update

problems have to be fixed at the root cause instead work around
downstream, that's a bad attitude and lead to problems sooner or later

if there would be a official SpamAssassin 3.4.1 we could discuss about
distributions should rapidly update their packages or even apply patches
local

until that happened rule-updates must not rely on features not supported
by the current GA version and hence i *really* don't get the point of
that discussion

On 2014-11-30 11:58, Ted Mittelstaedt wrote:
>
>
> On 11/30/2014 11:06 AM, jdow wrote:
>> On 2014-11-30 10:48, Ted Mittelstaedt wrote:
>>>
>>>
>>> On 11/29/2014 8:39 PM, John Hardin wrote:
>>>> On Sun, 30 Nov 2014, Reindl Harald wrote:
>>>>> Am 29.11.2014 um 23:27 schrieb John Hardin:
>>>>>>
>>>>>> However, it is a *warning*, not a fatal error. And it's better than
>>>>>> the
>>>>>> rule killing lint and blocking sa-update completely on an install that
>>>>>> uses an older perl
>>>>>
>>>>> don't get me wrong but this *warning* triggers cron mails and spits
>>>>> messages in case of every SA related command - that's unacceptable and
>>>>> in fact worser than without that check
>>>>>
>>>>> before *only* outdated perl versions where affected, now it hits also
>>>>> recent Fedora setups working before without any warning and with that
>>>>> rule included
>>>>
>>>> As I said, I underestimated the reaction to doing that.
>>>>
>>>>> if that rule can't work in most environments and not made
>>>>> conditionally it has to be dropped at all because it has more
>>>>> drawbacks than benefits
>>>>
>>>> It has already been commented out in my sandbox.
>>>>
>>>> But this effectively means we cannot add new features to SA conditionals
>>>> because they might do this to older installs.
>>>>
>>>
>>> No, just release patches to the older versions to Conf.pm and Parser.pm
>>>
>>> These are not COMPILED modules so it is easy to patch them.
>>>
>>> The people who even notice the warnings are going to be competent enough
>>> to run patch, and for the people who are running SpamAssassin who aren't
>>> competent enough to be able to do that, I doubt they will be noticing
>>> log entries.
>>>
>>> Ted
>>
>> Put a sock in it, Ted. For some, perhaps you, sysadmin is a hobby. For
>> others it is a necessary pain in the ass.
>
> Sysadmining is a joy to me. It also happens to be one I am paid to do.
>
> If it's a pain in the ass for you - I pity you. Your stuck in the wrong job.

I am doing it because it is a necessary job, somebody needs to do it, and I can
do it. This is NOT a large company. The theme park market is remarkably small so
we have to double and triple up on our jobs to stay afloat.

>> Going off distro for some
>> "patches" is precisely what we wish to avoid with these long term
>> professional distros.
>
> I think you mean what "I" wish to avoid.

If you have fun putting your systems at risk - have fun. I'd not want to employ
you. I guess I'm too conservative.

>> And you're telling US that we have to risk the
>> stability of the system? "Brown vaguely stinky soft spludgy material
>> such as emanates from the South end of a North facing fertile male bovine."
>>
>
> No I am telling you to use your head for something other than a place to
> hang your hat. Read the patches. Decide if they are significant enough to risk
> the stability of the system. If they are then don't apply them.

I might tell you precisely the same thing. How much do you ENJOY seeing nasty
messages crop up from cron jobs that had been working perfectly? I really do not
enjoy it and get rate acerbic when it happens.

> I have. They aren't. I applied them. As did many others on the thread I
> posted, none of whom reported any ill effects.

It is an accident of history that has me still watching this list. Loren and I
both had some fun building rules back in the SARE days. That wore off. Revenue
concerns took over. It pays infinitely (literally) better to design a tool that
allows 1024 audio in, 1024 audio out, ridiculous numbers of playbacks through an
audio matrix with gains on each cross point, equalization where needed, and so
forth. (It's not huge amounts of money. But anything other than zero divided by
zero is an infinite improvement in income. And when hungry one gets bloody
minded about that detail.)

> As I said before, I really, really pity you and I'm sorry you feel so trapped in
> your job. Honestly, there really is a better way to live. Take up painting,
> music, whatever. Do what you love. Do it well and people will pay you for it.
> And don't look back.

Again - put a dirty sock in it. I AM doing what I love. But that comes with a
side dose of trying to make life easier for us by doing what I can with system
administration on our barriers between the cold cold outside world and our cosy
little system here.

> Ted

{`,'} Joanne

>> {`,'}
>

On 11/30/2014 11:17 AM, jdow wrote:
> Ted, I simply do not feel well enough just now to be nice. I reiterate
> my prior observation about vaguely stinky and spludgy material such as
> emanates from the South end of North facing fertile male bovines.
>
> I have enough headaches with pure distro modules. I really REALLY
> *R*E*A*L*L*Y* do not want to go through the nonsense again with off
> distro modules. I ran SA off distro for a few years. I got tired of it.
> Too much stuff was starting to break.
>

In this situation I simply don't see that the patch recommendation
was all that big of a deal. It's a patch that's already going to be
included in the next version of SA, so if you really are running a
complete "on-distro" system and you are running updates on it, then
sooner or later most distro maintainers are going to include it and you
will get it the next time you run updates on your system.

> Sorry if I am abusive - no - I'm not sorry. I feel like warmed over poo
> with this blasted headcold. I DO NOT NEED THIS SORT OF AGGRAVATION JUST
> NOW PEEING ON ME FROM MY LOGS.
>

Nobody does, but...hypothetically, how many people screaming about this
"mistake" paid any money to the guy who created this program?

I save my nastiest screaming for companies like Microsoft who not only
periodically screw me over but they make me pay them to do it!!!

Ted

> {`,'}
>
> On 2014-11-30 11:07, Ted Mittelstaedt wrote:
>> Now now, be nice!
>>
>> This issue affects ANY piece of OSS software that has multiple
>> dependencies.
>>
>> SpamAssassin has HUNDREDS of dependencies on different Perl modules.
>>
>> Using your nasty logic if the author of Perl::Date or whatever
>> decided to make a change that broke SA than it's our tough luck, eh?
>>
>> The authors of any OSS project - like SA, like any of the modules that SA
>> depends on - that depends on OTHER OSS
>> projects need to navigate this dependency hell with same guiding
>> principle that is used for Sendmail and other OSS projects:
>>
>> Be liberal in what you accept, conservative in what you send.
>>
>> Meaning this - you write a package like SA, or a package like
>> Perl::Date, that
>> has published interfaces and API's, you need to do your best to maintain
>> consistency, and you need to be accepting
>> of changes that others make to the best of your ability.
>>
>> If the SA authors want to add bells and whistles to a functioning
>> design that
>> require certain newer versions of dependent programs that's fine - but
>> they need
>> to install logic in those bells and whistles that either makes them
>> backwards
>> compatible with older dependent programs or turns those bells and
>> whistles off.
>>
>> If it turns out that an older released SA has a design flaw that makes
>> that
>> impossible to do then patches need to be released for those older
>> versions.
>>
>> There's no need to take a scorched Earth My way or the highway approach.
>>
>> Ted
>>
>> On 11/30/2014 10:50 AM, Dave Pooser wrote:
>>> On 11/30/14 12:34 PM, "Paul R. Ganci"<ganci@nurdog.com> wrote:
>>>
>>>> So just so I understand something is it expected that those of us with
>>>> RHEL 5.11 and RHEL 6.6 servers are expected to upgrade our perl
>>>> versions
>>>> just for spamassassin's sa-update? The whole idea of running servers
>>>> with those versions of server software is for stability.
>>>
>>> Yep. And the whole point of running SpamAssassin with sa-update is for
>>> flexibility and agility. The two goals are necessarily in conflict.
>>> So...
>>> Looks like you have a few options:
>>> 1) Don't run SA on RHEL
>>> 2) Run SA on RHEL but turn off sa-update and sacrifice automated
>>> reaction
>>> to new spam in the interest of keeping your system static
>>> 3) Run SA on RHEL but upgrade perl and SpamAssassin using
>>> third-party-packages or update from source
>>> 4) Run SA on RHEL with system perl and system SpamAssassin, run
>>> sa-update
>>> with output redirected to /dev/null, and write your own monitoring
>>> script
>>> to tell you if sa-update broke spamd
>>> 5) Run SA in some kind of container or VM so you can optimize for
>>> spamassassin without tainting the purity of your RHEL install
>>

On 30. nov. 2014 20.53.19 John Hardin <jhardin@impsec.org> wrote:

> On Sun, 30 Nov 2014, Benny Pedersen wrote:
>
> > Ruleupdates should have being if version before if perl_version, so this the
> > test of perl was only done on svn version of sa, it have nothing to do with
> > update or change dependice of perl installed
>
> 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

> if fnord > 0

Psudo fnord would exists in trunc

> 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, is it a svn tag check in sa ?

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

On 11/30/2014 12:09 PM, Reindl Harald wrote:
>
> Am 30.11.2014 um 20:50 schrieb Ted Mittelstaedt:
>> When the fix to allow older SA versions to silently accept the new
>> rule updates is a simple TEXT modification of 2 text Perl modules, you
>> are overreacting
>
> no - i react correctly
>
> * the problem was introduced with sa-update
> * the problem has to be fixed with sa-update
>
> problems have to be fixed at the root cause instead work around
> downstream, that's a bad attitude and lead to problems sooner or later
>

Ah, but is this really a problem? 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!

> if there would be a official SpamAssassin 3.4.1 we could discuss about
> distributions should rapidly update their packages or even apply patches
> local
>

But, is that going to help most of the people complaining about the
problem? They still will have elderly Perl versions. If 3.4.1 requires
a newer Perl version they will be stuck at 3.4.0 since their maintainers
won't update. If new version-dependent rules require new
Perl versions then what?

> until that happened rule-updates must not rely on features not supported
> by the current GA version and hence i *really* don't get the point of
> that discussion
>

If the new version dependent rule update gives the spamfighting
community a significant compelling advantage against the spammers, then
Damn the torpedoes and full speed ahead!!!! I'll happily put in 2
minor patches to take advantage of the rule! What I spend in possible
headache doing that will be more than made up by the increased spam I
don't have to deal with!!

Ted

Am 30.11.2014 um 21:30 schrieb Ted Mittelstaedt:
> On 11/30/2014 12:09 PM, Reindl Harald wrote:
>>
>> Am 30.11.2014 um 20:50 schrieb Ted Mittelstaedt:
>>> When the fix to allow older SA versions to silently accept the new
>>> rule updates is a simple TEXT modification of 2 text Perl modules, you
>>> are overreacting
>>
>> no - i react correctly
>>
>> * the problem was introduced with sa-update
>> * the problem has to be fixed with sa-update
>>
>> problems have to be fixed at the root cause instead work around
>> downstream, that's a bad attitude and lead to problems sooner or later
>
> Ah, but is this really a problem? 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 answer to the $64K is simple: look in you rlogs, and *no*
0.001 will not have a impact in context of "the new version dependent
rule update gives the spamfighting community a significant compelling
advantage against the spammers"

why don't you just verify that at your own before assume things?

spamass-milter had rejected all relevant messages clearly without it
_______________________________________________________________

[root@localhost:~]$ sa-score.sh PDS_FROM_2_EMAILS
/var/lib/spamassassin/3.004000/updates_spamassassin_org
score PDS_FROM_2_EMAILS 1.402 0.001 1.402 0.001

[root@localhost:~]$ cat maillog | grep PDS_FROM_2_EMAILS
Nov 26 08:43:01 mail-gw spamd[13080]: spamd: result: Y 16 -
BAYES_50,CUST_DNSWL_2,FORGED_OUTLOOK_HTML,FROM_MISSPACED,FROM_MISSP_EH_MATCH,FROM_MISSP_MSFT,HTML_MESSAGE,MIME_HTML_ONLY,PDS_FROM_2_EMAILS,RCVD_IN_MSPIKE_H2,SPF_NONE,TO_NO_BRKTS_FROM_MSSP,TO_NO_BRKTS_MSFT,T_FROM_MISSP_DKIM
scantime=0.4,size=1962,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=19781,mid=<201411260742.sAQ7ghX0026176@smtp08.msg.oleane.net>,bayes=0.499989,autolearn=disabled
Nov 26 08:45:13 mail-gw spamd[13080]: spamd: result: Y 9 -
BAYES_50,CUST_DNSWL_2,CUST_DNSWL_5,FROM_MISSPACED,FROM_MISSP_EH_MATCH,HTML_MESSAGE,LOTS_OF_MONEY,MIME_HTML_ONLY,MONEY_FROM_MISSP,PDS_FROM_2_EMAILS,RCVD_IN_MSPIKE_H2,SPF_NONE,TO_NO_BRKTS_FROM_MSSP,T_FROM_MISSP_DKIM
scantime=0.2,size=2356,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=19806,mid=<0MPvIk-1Xphnn3lcw-0050kY@mrelayeu.kundenserver.de>,bayes=0.499996,autolearn=disabled
Nov 26 18:10:19 mail-gw spamd[8290]: spamd: result: Y 15 -
BAYES_50,CUST_DNSWL_2,FROM_MISSP_PHISH,HTML_IMAGE_ONLY_20,HTML_MESSAGE,MIME_HTML_ONLY,MISSING_DATE,MISSING_MID,PDS_FROM_2_EMAILS,SPF_NONE
scantime=1.3,size=3023,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=25917,mid=(unknown),bayes=0.493467,autolearn=disabled
Nov 27 04:49:23 mail-gw spamd[6160]: spamd: result: Y 11 -
BAYES_20,CUST_DNSBL_19,CUST_DNSWL_2,CUST_DNSWL_5,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,FROM_MISSPACED,FROM_MISSP_FREEMAIL,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,LOTS_OF_MONEY,MIME_HTML_ONLY,MONEY_FROM_MISSP,NAME_EMAIL_DIFF,PDS_FROM_2_EMAILS,RCVD_IN_MSPIKE_H2,SPF_PASS,TO_NO_BRKTS_FROM_MSSP,T_FROM_MISSP_DKIM
scantime=0.5,size=2359,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=29086,mid=<20141127034919.8BB0C2DB881@wt1c42874ffc.nazwa.pl>,bayes=0.140299,autolearn=disabled
Nov 27 06:40:16 mail-gw spamd[4064]: spamd: result: Y 13 -
BAYES_50,CUST_DNSWL_6,FORGED_OUTLOOK_HTML,FROM_MISSP_MSFT,HTML_IMAGE_ONLY_20,HTML_MESSAGE,MIME_HTML_ONLY,NAME_EMAIL_DIFF,PDS_FROM_2_EMAILS,SPF_NONE,TO_NO_BRKTS_MSFT
scantime=1.0,size=3439,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=29596,mid=<0MXWgY-1XNRVV1s2g-00WYjm@mrelayeu.kundenserver.de>,bayes=0.511470,autolearn=disabled
Nov 27 08:30:33 mail-gw spamd[4065]: spamd: result: . -2 -
BAYES_00,CUST_DNSWL_2,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HTML_FONT_SIZE_HUGE,HTML_MESSAGE,NAME_EMAIL_DIFF,PDS_FROM_2_EMAILS,SPF_PASS,T_RP_MATCHES_RCVD,T_TVD_FUZZY_SECTOR
scantime=0.7,size=23175,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=30274,mid=<20141127082938.42682@letter.eyepin.com>,bayes=0.000000,autolearn=disabled
Nov 27 09:33:08 mail-gw spamd[4066]: spamd: result: Y 19 -
BAYES_50,CUST_DNSBL_5,FROM_MISSPACED,FROM_MISSP_EH_MATCH,HTML_MESSAGE,MIME_HTML_ONLY,MISSING_DATE,MISSING_MID,NAME_EMAIL_DIFF,PDS_FROM_2_EMAILS,SPF_NONE,TO_NO_BRKTS_FROM_MSSP,T_FROM_MISSP_DKIM
scantime=4.7,size=1915,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=30915,mid=(unknown),bayes=0.586026,autolearn=disabled
Nov 27 09:35:14 mail-gw spamd[4066]: spamd: result: Y 10 -
BAYES_50,FROM_MISSP_PHISH,HTML_IMAGE_ONLY_16,HTML_MESSAGE,LOTS_OF_MONEY,MIME_HTML_ONLY,MONEY_FROM_MISSP,NAME_EMAIL_DIFF,PDS_FROM_2_EMAILS,SPF_NONE,T_REMOTE_IMAGE
scantime=1.7,size=3018,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=30947,mid=<20141127083458.3218630001D9@master.webbian.de>,bayes=0.494638,autolearn=disabled
Nov 27 16:16:17 mail-gw spamd[2551]: spamd: result: . -2 -
BAYES_00,CUST_DNSWL_2,NAME_EMAIL_DIFF,PDS_FROM_2_EMAILS,SPF_NONE,T_RP_MATCHES_RCVD
scantime=0.4,size=1662,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=35461,mid=<nfpeev.pom63m@dpd-business.at>,bayes=0.000064,autolearn=disabled
Nov 27 19:20:10 mail-gw spamd[2553]: spamd: result: Y 13 -
BAYES_50,CUST_DNSWL_2,FREEMAIL_FROM,FROM_MISSPACED,FROM_MISSP_EH_MATCH,FROM_MISSP_FREEMAIL,HTML_MESSAGE,MIME_HTML_ONLY,NAME_EMAIL_DIFF,PDS_FROM_2_EMAILS,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_NONE,SUBJECT_NEEDS_ENCODING,SUBJ_ILLEGAL_CHARS,T_FROM_MISSP_DKIM,T_RP_MATCHES_RCVD
scantime=2.2,size=2088,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=37148,mid=<54100E990B0790E0@vsmtp4.tin.it>,bayes=0.533918,autolearn=disabled
Nov 27 21:44:20 mail-gw spamd[2554]: spamd: result: Y 14 -
BAYES_50,CUST_DNSBL_8,CUST_DNSWL_5,FROM_MISSPACED,FROM_MISSP_EH_MATCH,HTML_MESSAGE,MIME_HTML_ONLY,NAME_EMAIL_DIFF,PDS_FROM_2_EMAILS,RCVD_IN_MSPIKE_BL,RCVD_IN_MSPIKE_L5,SPF_NONE,TO_NO_BRKTS_FROM_MSSP,T_FROM_MISSP_DKIM
scantime=0.2,size=2477,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=37955,mid=<0Lyh7L-1XwY8z2VV9-0164y5@mrelayeu.kundenserver.de>,bayes=0.465341,autolearn=disabled
Nov 28 00:42:04 mail-gw spamd[2556]: spamd: result: Y 9 -
BAYES_20,FROM_MISSPACED,FROM_MISSP_EH_MATCH,FROM_MISSP_PHISH,HTML_MESSAGE,MIME_HTML_ONLY,NAME_EMAIL_DIFF,PDS_FROM_2_EMAILS,SPF_NONE,TO_NO_BRKTS_FROM_MSSP,T_FROM_MISSP_DKIM
scantime=0.3,size=2492,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=38719,mid=<20141127234150.A405E4B04D3F@main4.simsforum.de>,bayes=0.180433,autolearn=disabled
Nov 28 00:42:04 mail-gw spamd[2555]: spamd: result: Y 9 -
BAYES_20,FROM_MISSPACED,FROM_MISSP_EH_MATCH,FROM_MISSP_PHISH,HTML_MESSAGE,MIME_HTML_ONLY,NAME_EMAIL_DIFF,PDS_FROM_2_EMAILS,SPF_NONE,TO_NO_BRKTS_FROM_MSSP,T_FROM_MISSP_DKIM
scantime=0.4,size=2461,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=38718,mid=<20141127234149.A2CDA4B04D33@main4.simsforum.de>,bayes=0.180433,autolearn=disabled
Nov 28 01:52:52 mail-gw spamd[2556]: spamd: result: Y 19 -
BAYES_50,FROM_MISSP_PHISH,HTML_IMAGE_ONLY_20,HTML_MESSAGE,LOTS_OF_MONEY,MIME_HTML_ONLY,MONEY_FROM_MISSP,NAME_EMAIL_DIFF,PDS_FROM_2_EMAILS,SPF_NONE,T_REMOTE_IMAGE,URIBL_BLACK,URIBL_DBL_ABUSE_MALW
scantime=0.7,size=4540,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=38999,mid=<20141128005236.19A726B01DA@lxmail3.lxcluster.at>,bayes=0.499719,autolearn=disabled

On 2014-11-30 12:19, Ted Mittelstaedt wrote:
>
>
> On 11/30/2014 11:17 AM, jdow wrote:
>> Ted, I simply do not feel well enough just now to be nice. I reiterate
>> my prior observation about vaguely stinky and spludgy material such as
>> emanates from the South end of North facing fertile male bovines.
>>
>> I have enough headaches with pure distro modules. I really REALLY
>> *R*E*A*L*L*Y* do not want to go through the nonsense again with off
>> distro modules. I ran SA off distro for a few years. I got tired of it.
>> Too much stuff was starting to break.
>>
>
> In this situation I simply don't see that the patch recommendation
> was all that big of a deal. It's a patch that's already going to be included in
> the next version of SA, so if you really are running a
> complete "on-distro" system and you are running updates on it, then
> sooner or later most distro maintainers are going to include it and you will get
> it the next time you run updates on your system.
>
>> Sorry if I am abusive - no - I'm not sorry. I feel like warmed over poo
>> with this blasted headcold. I DO NOT NEED THIS SORT OF AGGRAVATION JUST
>> NOW PEEING ON ME FROM MY LOGS.
>>
>
> Nobody does, but...hypothetically, how many people screaming about this
> "mistake" paid any money to the guy who created this program?
>
> I save my nastiest screaming for companies like Microsoft who not only
> periodically screw me over but they make me pay them to do it!!!
>
> Ted

Linux does not provide adequate facilities for some of the work I do. So I have
SL6.5 and Win 7 running, both. So far one Windows update has cost a lot of
people some sincere heartburn, fortunately not me. In that time I've been
RedHatted at least once. It seems I had to upgrade to SL6.6 in order to keep
receiving updates because I have Octave on the system as a tool for digital
filter work. I've also had nVidia make a bloody mess of the system as well.
(Nouveau at the time the system was put on line simply did not work at all
adequately.) So the score is pretty much 3 Linux pains in the ass for 1 Windows
potential pain in the ass. That said, I do NOT trust Windows bare to the
Internet. I do (mostly) trust Linux in that role. So I run both. I pick the OS
of choice based on which does the job I need better with less effort on my part.
I am slowing down as I get into my eighth decade now. So extra efforts forced
upon me by sloppy thought processes or arrogance really twist my teat and I get
angry.

My one happy thought in terms of one Ted Mittelstaedt is that he, too, will get
old and suffer, too. And if he does not mature somewhat he will suffer worse
than me. Somehow that thought warms my nasty cold little heart.

{^_^}

>> {`,'}
>>
>> On 2014-11-30 11:07, Ted Mittelstaedt wrote:
>>> Now now, be nice!
>>>
>>> This issue affects ANY piece of OSS software that has multiple
>>> dependencies.
>>>
>>> SpamAssassin has HUNDREDS of dependencies on different Perl modules.
>>>
>>> Using your nasty logic if the author of Perl::Date or whatever
>>> decided to make a change that broke SA than it's our tough luck, eh?
>>>
>>> The authors of any OSS project - like SA, like any of the modules that SA
>>> depends on - that depends on OTHER OSS
>>> projects need to navigate this dependency hell with same guiding
>>> principle that is used for Sendmail and other OSS projects:
>>>
>>> Be liberal in what you accept, conservative in what you send.
>>>
>>> Meaning this - you write a package like SA, or a package like
>>> Perl::Date, that
>>> has published interfaces and API's, you need to do your best to maintain
>>> consistency, and you need to be accepting
>>> of changes that others make to the best of your ability.
>>>
>>> If the SA authors want to add bells and whistles to a functioning
>>> design that
>>> require certain newer versions of dependent programs that's fine - but
>>> they need
>>> to install logic in those bells and whistles that either makes them
>>> backwards
>>> compatible with older dependent programs or turns those bells and
>>> whistles off.
>>>
>>> If it turns out that an older released SA has a design flaw that makes
>>> that
>>> impossible to do then patches need to be released for those older
>>> versions.
>>>
>>> There's no need to take a scorched Earth My way or the highway approach.
>>>
>>> Ted
>>>
>>> On 11/30/2014 10:50 AM, Dave Pooser wrote:
>>>> On 11/30/14 12:34 PM, "Paul R. Ganci"<ganci@nurdog.com> wrote:
>>>>
>>>>> So just so I understand something is it expected that those of us with
>>>>> RHEL 5.11 and RHEL 6.6 servers are expected to upgrade our perl
>>>>> versions
>>>>> just for spamassassin's sa-update? The whole idea of running servers
>>>>> with those versions of server software is for stability.
>>>>
>>>> Yep. And the whole point of running SpamAssassin with sa-update is for
>>>> flexibility and agility. The two goals are necessarily in conflict.
>>>> So...
>>>> Looks like you have a few options:
>>>> 1) Don't run SA on RHEL
>>>> 2) Run SA on RHEL but turn off sa-update and sacrifice automated
>>>> reaction
>>>> to new spam in the interest of keeping your system static
>>>> 3) Run SA on RHEL but upgrade perl and SpamAssassin using
>>>> third-party-packages or update from source
>>>> 4) Run SA on RHEL with system perl and system SpamAssassin, run
>>>> sa-update
>>>> with output redirected to /dev/null, and write your own monitoring
>>>> script
>>>> to tell you if sa-update broke spamd
>>>> 5) Run SA in some kind of container or VM so you can optimize for
>>>> spamassassin without tainting the purity of your RHEL install
>>>
>

How does the usual person not a member of the right mailing lists learn of this
patch? An hour spent Googling and vetting patches is an hour taken from my life
time. Fortunately for me I was still a member of this list. So I learned I can
just ignore the fool thing cluttering my mailbox. (I may even write an SA rule
to force marking it as extreme spam so that it sorts away from places where
important messages should appear. I like the irony of that idea.)

Have a nice day - you, too, will get really old and hurt a lot someday.....

{^_^}

On 2014-11-30 12:30, Ted Mittelstaedt wrote:
>
>
> On 11/30/2014 12:09 PM, Reindl Harald wrote:
>>
>> Am 30.11.2014 um 20:50 schrieb Ted Mittelstaedt:
>>> When the fix to allow older SA versions to silently accept the new
>>> rule updates is a simple TEXT modification of 2 text Perl modules, you
>>> are overreacting
>>
>> no - i react correctly
>>
>> * the problem was introduced with sa-update
>> * the problem has to be fixed with sa-update
>>
>> problems have to be fixed at the root cause instead work around
>> downstream, that's a bad attitude and lead to problems sooner or later
>>
>
> Ah, but is this really a problem? 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!
>
>> if there would be a official SpamAssassin 3.4.1 we could discuss about
>> distributions should rapidly update their packages or even apply patches
>> local
>>
>
> But, is that going to help most of the people complaining about the problem?
> They still will have elderly Perl versions. If 3.4.1 requires
> a newer Perl version they will be stuck at 3.4.0 since their maintainers won't
> update. If new version-dependent rules require new
> Perl versions then what?
>
>> until that happened rule-updates must not rely on features not supported
>> by the current GA version and hence i *really* don't get the point of
>> that discussion
>>
>
> If the new version dependent rule update gives the spamfighting community a
> significant compelling advantage against the spammers, then Damn the torpedoes
> and full speed ahead!!!! I'll happily put in 2 minor patches to take advantage
> of the rule! What I spend in possible headache doing that will be more than
> made up by the increased spam I don't have to deal with!!
>
> Ted
>

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?
--
Dave Pooser
Cat-Herder-in-Chief, Pooserville.com
"...Life is not a journey to the grave with the intention of arriving
safely in one pretty and well-preserved piece, but to slide across the
finish line broadside, thoroughly used up, worn out, leaking oil, and
shouting GERONIMO!!!" -- Bill McKenna

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

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

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

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

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 ? :)

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

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

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

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

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.

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

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

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

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

{^_^}

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

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

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

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

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

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

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

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 ?

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

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.

{^_^}
{^_^}

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?

{^_^}

On 2014-11-30 15:00, Benny Pedersen wrote:
> 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 ?
>

The "if perl_version...." line must be at least partially parsed so that the
endif parsing works.

{^_^}

On Sun, 30 Nov 2014, Bob Proulx wrote:

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

Oh, it won't do that.

It's just embarrassing as all hell to publicly step on my sword in this
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
-----------------------------------------------------------------------
Men by their constitutions are naturally divided in to two parties:
1. Those who fear and distrust the people and wish to draw all
powers from them into the hands of the higher classes. 2. Those who
identify themselves with the people, have confidence in them,
cherish and consider them as the most honest and safe, although not
the most wise, depository of the public interests.
-- Thomas Jefferson
-----------------------------------------------------------------------
15 days until Bill of Rights day

On Sun, 30 Nov 2014, jdow wrote:

> 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

The SA if() conditional only supports a very limited subset of the perl
syntax, otherwise the perl_version change wouldn't have been needed in the
first place, we could just check $] or $^V directly.

So, that doesn't work:

Nov 30 17:14:09.267 [18334] warn: config: error in if - ( ( "ref" (
"fnord_var" ) == "SCALAR" ) && ( "fnord_var" >= 5.010000 ) ) : syntax
error at (eval 2556) line 1, near ""ref" ( "


--
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
-----------------------------------------------------------------------
Men by their constitutions are naturally divided in to two parties:
1. Those who fear and distrust the people and wish to draw all
powers from them into the hands of the higher classes. 2. Those who
identify themselves with the people, have confidence in them,
cherish and consider them as the most honest and safe, although not
the most wise, depository of the public interests.
-- Thomas Jefferson
-----------------------------------------------------------------------
15 days until Bill of Rights day

On Sun, 30 Nov 2014, Reindl Harald wrote:

>> On Sun, 30 Nov 2014, jdow wrote:
>> >
>> > if version > 3.004001 && perl_version >= 5.010000
>> > body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
>> > endif
>
> exactly that's what i menat with "from my knowledge the 'if perl_version'
> should not get touched in that case at all"

I was assuming you were referring to the version that everyone had been
discussing up to the point jdow made her suggestion, namely:

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

Apologies if you were not, you didn't make that clear.

--
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
-----------------------------------------------------------------------
Men by their constitutions are naturally divided in to two parties:
1. Those who fear and distrust the people and wish to draw all
powers from them into the hands of the higher classes. 2. Those who
identify themselves with the people, have confidence in them,
cherish and consider them as the most honest and safe, although not
the most wise, depository of the public interests.
-- Thomas Jefferson
-----------------------------------------------------------------------
15 days until Bill of Rights day

On 2014-11-30 17:12, John Hardin wrote:
> On Sun, 30 Nov 2014, Bob Proulx wrote:
>
>> 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.
>
> Oh, it won't do that.
>
> It's just embarrassing as all hell to publicly step on my sword in this manner.

Stepped in a "richard", you did. (Read Terry Pratchett's "Dodger" if you must to
get the term's meaning and origin.)

{^_-} Joanne

On 2014-11-30 17:16, John Hardin wrote:
> On Sun, 30 Nov 2014, jdow wrote:
>
>> 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
>
> The SA if() conditional only supports a very limited subset of the perl syntax,
> otherwise the perl_version change wouldn't have been needed in the first place,
> we could just check $] or $^V directly.
>
> So, that doesn't work:
>
> Nov 30 17:14:09.267 [18334] warn: config: error in if - ( ( "ref" ( "fnord_var"
> ) == "SCALAR" ) && ( "fnord_var" >= 5.010000 ) ) : syntax error at (eval 2556)
> line 1, near ""ref" ( "

OK, would this work? Use the fact that the thing defaults to a string. I would
"guess" the value would be "perl_version".

if (( perl_version != "perl_version" ) && ( perl_version >= 5.010000 ))
bad stuff
endif

{^_^}

On Sun, 30 Nov 2014, jdow wrote:

> OK, would this work? Use the fact that the thing defaults to a string. I
> would "guess" the value would be "perl_version".
>
> if (( perl_version != "perl_version" ) && ( perl_version >= 5.010000 ))
> bad stuff
> endif

Nope. != is also a numeric comparison so you gain no ground. And "ne"
isn't included in the perl subset that SA conditionals use.

--
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
-----------------------------------------------------------------------
...intellectuals have no interest in what _creates_ wealth, and
what _inhibits_ the creation of wealth. They are very concerned
about the _distribution_ of it, but they act as if wealth just
exists somehow. It's like manna from heaven, it's only a
question of how we split it up. -- Thomas Sowell
-----------------------------------------------------------------------
15 days until Bill of Rights day

On 2014-11-30 18:46, John Hardin wrote:
> On Sun, 30 Nov 2014, jdow wrote:
>
>> OK, would this work? Use the fact that the thing defaults to a string. I would
>> "guess" the value would be "perl_version".
>>
>> if (( perl_version != "perl_version" ) && ( perl_version >= 5.010000 ))
>> bad stuff
>> endif
>
> Nope. != is also a numeric comparison so you gain no ground. And "ne" isn't
> included in the perl subset that SA conditionals use.

Well, I tried. I guess after being a bit trying I figured giving a good try was
called for. Whining is no fun. Finding solutions is.

{^_^}

Hello Ted,

Sunday, November 30, 2014, 7:50:49 PM, you wrote:

TM> assuming
TM> your package maintainers are following the new releases of SA

There's an assumption!

CentOS 6

spamassassin.x86_64 3.3.1-3.el6 base

CentOS 7

spamassassin-3.3.2-18.el7.x86_64.rpm

--
Best regards,
Niamh mailto:niamh@fullbore.co.uk

On 1. dec. 2014 02.06.51 jdow <jdow@earthlink.net> wrote:

> The "if perl_version...." line must be at least partially parsed so that the
> endif parsing works.

Design faults, is spamassassin really that bad ?

Am 01.12.2014 um 10:25 schrieb Benny Pedersen:
> On 1. dec. 2014 02.06.51 jdow <jdow@earthlink.net> wrote:
>
>> The "if perl_version...." line must be at least partially parsed so
>> that the
>> endif parsing works.
>
> Design faults, is spamassassin really that bad ?

don't start the same as on the dovecot list here followed by innocent
playing thread strip quting after get the deserved response!

https://www.mail-archive.com/dovecot@dovecot.org/msg55174.html
http://www.dovecot.org/list/dovecot/2013-November/093465.html

I haven’t read all this thread, since it went ballistic Sunday, too much to
read but there seems to be a misconception this is an sa-update problem from
what I have read. This is not the case the if perl_version causes problems
in sa-learn and spamassassin too.

What dose seem strange is that spamassassin --lint picks up the version
correctly "Perl 5.012004" so perl_version is doing something wrong if the
version can be picked up numerically elsewhere, surely in the next release
of spamassassin this can be changed and it can play nicely with older
versions of perl.

On 11/30/2014 11:29 PM, John Hardin 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
>
> Yes. That *does* work.
>
> Thank you! I think you just solved it.


Define work...

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

# spamassassin --lint
Dec 1 15:03:50.365 [28224] warn: Argument "perl_version" isn't numeric
in numeric ge (>=) at (eval 2520) line 2.
----------

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

# spamassassin --lint
Dec 1 15:04:29.115 [28226] warn: Argument "perl_version" isn't numeric
in numeric ge (>=) at (eval 2521) line 2.
-----------

(SA 3.3.1 / perl 5.8.8)


But I was thinking another solution to the problem;

Since there already are quite a few changes to 3.4(+) (quite a few
checking for version >= 3.004000 in the rulesets)

How difficult would it be to split 3.4.1(+) rulesets from pre-3.4.1
rulesets? Older SA/sa-update would then fetch rulesets without the
new checks, and new sa-update would benefit from the new checks...


just my $.02

--
Bernt 'Burnie' Pettersen /// DoD#2345
<E-mail:burnie@dod.no> /// <URL:http://burnie.sh/>
- Creative brains need creative workhours! -

On 12/1/2014 9:21 AM, Burnie wrote:
> On 11/30/2014 11:29 PM, John Hardin 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
>>
>> Yes. That *does* work.
>>
>> Thank you! I think you just solved it.
>
>
> Define work...
OK, looks like we need to add a single has/can function for perl
5.010000 for this issue since we can't pass a parameter or use
perl_version without hitting errors. It's not scalable but will solve
the immediate issue.

> But I was thinking another solution to the problem;
>
> Since there already are quite a few changes to 3.4(+) (quite a few
> checking for version >= 3.004000 in the rulesets)
>
> How difficult would it be to split 3.4.1(+) rulesets from pre-3.4.1
> rulesets? Older SA/sa-update would then fetch rulesets without the
> new checks, and new sa-update would benefit from the new checks...
That's a decent amount of work AND a dangerous path to tread because
only 3.4.X is supported by the project currently so if we invested a lot
of time on that path, it would lead to dropping 3.3.X support. But it's
a good thought because it is a solution no one else mentioned.

Regards,
KAM

On 12/1/2014 10:11 AM, Kevin A. McGrail wrote:
> On 12/1/2014 9:21 AM, Burnie wrote:
>> On 11/30/2014 11:29 PM, John Hardin 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
>>>
>>> Yes. That *does* work.
>>>
>>> Thank you! I think you just solved it.
>>
>>
>> Define work...
> OK, looks like we need to add a single has/can function for perl
> 5.010000 for this issue since we can't pass a parameter or use
> perl_version without hitting errors. It's not scalable but will solve
> the immediate issue.
>
>> But I was thinking another solution to the problem;
>>
>> Since there already are quite a few changes to 3.4(+) (quite a few
>> checking for version >= 3.004000 in the rulesets)
>>
>> How difficult would it be to split 3.4.1(+) rulesets from pre-3.4.1
>> rulesets? Older SA/sa-update would then fetch rulesets without the
>> new checks, and new sa-update would benefit from the new checks...
> That's a decent amount of work AND a dangerous path to tread because
> only 3.4.X is supported by the project currently so if we invested a
> lot of time on that path, it would lead to dropping 3.3.X support. But
> it's a good thought because it is a solution no one else mentioned.
>
> Regards,
> KAM
This module may be of some help as well:

On 12/1/2014 10:24 AM, Joe Quinn wrote:
> On 12/1/2014 10:11 AM, Kevin A. McGrail wrote:
>> On 12/1/2014 9:21 AM, Burnie wrote:
>>> On 11/30/2014 11:29 PM, John Hardin 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
>>>>
>>>> Yes. That *does* work.
>>>>
>>>> Thank you! I think you just solved it.
>>>
>>>
>>> Define work...
>> OK, looks like we need to add a single has/can function for perl
>> 5.010000 for this issue since we can't pass a parameter or use
>> perl_version without hitting errors. It's not scalable but will solve
>> the immediate issue.
>>
>>> But I was thinking another solution to the problem;
>>>
>>> Since there already are quite a few changes to 3.4(+) (quite a few
>>> checking for version >= 3.004000 in the rulesets)
>>>
>>> How difficult would it be to split 3.4.1(+) rulesets from pre-3.4.1
>>> rulesets? Older SA/sa-update would then fetch rulesets without the
>>> new checks, and new sa-update would benefit from the new checks...
>> That's a decent amount of work AND a dangerous path to tread because
>> only 3.4.X is supported by the project currently so if we invested a
>> lot of time on that path, it would lead to dropping 3.3.X support.
>> But it's a good thought because it is a solution no one else mentioned.
>>
>> Regards,
>> KAM
> This module may be of some help as well:
http://search.cpan.org/~bdfoy/Perl-Version/lib/Perl/Version.pm

(Sorry for fat-fingering ctrl+enter)

On 12/1/2014 10:25 AM, Joe Quinn wrote:
> http://search.cpan.org/~bdfoy/Perl-Version/lib/Perl/Version.pm
Not really because we want to make the check in a config file delivered
by SA-UPDATE without any changes to SA that will ripple to older SA
installations. And I don't think we have an issue identifying the
version of perl. We have an issue writing a config file logic that can
identify the version of perl that works with SA trunk and doesn't throw
a warn in older versions of SA.

regards,
KAM

On Mon, 1 Dec 2014, Burnie wrote:

> On 11/30/2014 11:29 PM, John Hardin 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
>>
>> Yes. That *does* work.
>>
>> Thank you! I think you just solved it.
>
>
> Define work...
>
> -----------
> if version > 3.004001 && perl_version >= 5.010000
> body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
> endif
>
> # spamassassin --lint
> Dec 1 15:03:50.365 [28224] warn: Argument "perl_version" isn't numeric in
> numeric ge (>=) at (eval 2520) line 2.

Dammit. I ran it (against trunk) here (with a different pseudo-var name,
and using version > 9) and did *not* get a type warning!

if version > 1 && fnord_should_be_skipped >= 5.010000
body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
endif

gives:

Dec 1 09:08:36.622 [22970] warn: Argument "fnord_should_be_skipped" isn't
numeric in numeric ge (>=) at (eval 2555) line 1.
Dec 1 09:08:37.481 [22970] dbg: message: main message type: text/plain


if version > 4 && fnord_should_be_skipped >= 5.010000
body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
endif

gives:

Dec 1 09:09:49.486 [22988] dbg: message: main message type: text/plain


> But I was thinking another solution to the problem;
>
> Since there already are quite a few changes to 3.4(+) (quite a few
> checking for version >= 3.004000 in the rulesets)
>
> How difficult would it be to split 3.4.1(+) rulesets from pre-3.4.1
> rulesets? Older SA/sa-update would then fetch rulesets without the
> new checks, and new sa-update would benefit from the new checks...

That may need to be what happens.

--
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
-----------------------------------------------------------------------
There is no better measure of the unthinking contempt of the
environmentalist movement for civilization than their call to
turn off the lights and sit in the dark. -- Sultan Knish
-----------------------------------------------------------------------
14 days until Bill of Rights day

On Mon, 1 Dec 2014, Kevin A. McGrail wrote:

> On 12/1/2014 9:21 AM, Burnie wrote:
>> On 11/30/2014 11:29 PM, John Hardin 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
>> >
>> > Yes. That *does* work.
>> >
>> > Thank you! I think you just solved it.
>>
>>
>> Define work...
>
> OK, looks like we need to add a single has/can function for perl 5.010000 for
> this issue since we can't pass a parameter or use perl_version without
> hitting errors. It's not scalable but will solve the immediate issue.
>
>> But I was thinking another solution to the problem;
>>
>> Since there already are quite a few changes to 3.4(+) (quite a few
>> checking for version >= 3.004000 in the rulesets)
>>
>> How difficult would it be to split 3.4.1(+) rulesets from pre-3.4.1
>> rulesets? Older SA/sa-update would then fetch rulesets without the
>> new checks, and new sa-update would benefit from the new checks...
>
> That's a decent amount of work AND a dangerous path to tread because only
> 3.4.X is supported by the project currently so if we invested a lot of time
> on that path, it would lead to dropping 3.3.X support. But it's a good
> thought because it is a solution no one else mentioned.

Before we go that route, I have not tested whether a require_version at
the beginning of a separate rules file will bypass this issue.

--
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
-----------------------------------------------------------------------
There is no better measure of the unthinking contempt of the
environmentalist movement for civilization than their call to
turn off the lights and sit in the dark. -- Sultan Knish
-----------------------------------------------------------------------
14 days until Bill of Rights day

John Hardin wrote:
> Burnie wrote:
> >John Hardin wrote:
> >> 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
> >>
> >> Yes. That *does* work.
> >>
> >> Thank you! I think you just solved it.
> >
> >Define work...
> >
> >if version > 3.004001 && perl_version >= 5.010000
> > body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
> >endif
> >
> ># spamassassin --lint
> >Dec 1 15:03:50.365 [28224] warn: Argument "perl_version" isn't numeric in
> >numeric ge (>=) at (eval 2520) line 2.
>
> Dammit. I ran it (against trunk) here (with a different pseudo-var name, and
> using version > 9) and did *not* get a type warning!

First, thank you for the fix in the latest updates. I no longer saw
any warnings from cron with last nights release cycle.

Regarding this syntax I just ran a test here with exactly that
syntax in Debian Wheezy Stable.

$ spamassassin --version
SpamAssassin version 3.3.2
running on Perl version 5.14.2

if version > 3.004001 && perl_version >= 5.010000
meta PDS_FROM_2_EMAILS __PDS_FROM_2_EMAILS && !__VIA_ML && !__VIA_RESIGNER
endif

if version > 3.004001 && perl_version >= 5.010000
header __PDS_FROM_2_EMAILS From =~ /^\W+([\w+.-]+\@[\w.-]+\.\w\w++)(?:[^\n\w<]{0,80})?<(?!\1)[^\n\s]*\@/i
endif

This produced no lint warnings with the above combination. I am
missing why it is causing problems in Burnie's configuration. Is
3.3.1 really that different here from 3.3.2 which is silent?

Bob

On Mon, 1 Dec 2014, John Hardin wrote:
> On Mon, 1 Dec 2014, Kevin A. McGrail wrote:
>> On 12/1/2014 9:21 AM, Burnie wrote:
>>
>> > But I was thinking another solution to the problem;
>> >
>> > Since there already are quite a few changes to 3.4(+) (quite a few
>> > checking for version >= 3.004000 in the rulesets)
>> >
>> > How difficult would it be to split 3.4.1(+) rulesets from pre-3.4.1
>> > rulesets? Older SA/sa-update would then fetch rulesets without the
>> > new checks, and new sa-update would benefit from the new checks...
>>
>> That's a decent amount of work AND a dangerous path to tread because only
>> 3.4.X is supported by the project currently so if we invested a lot of
>> time on that path, it would lead to dropping 3.3.X support. But it's a
>> good thought because it is a solution no one else mentioned.
>
> Before we go that route, I have not tested whether a require_version at the
> beginning of a separate rules file will bypass this issue.

Ugh, that's actually worse:

Dec 1 10:57:50.092 [23879] warn: config: configuration file "/home/jhardin/develop/spamassassin/testing/require_version.cf" requires version 5.003000 of SpamAssassin, but this is code version 3.004001. Maybe you need to use the -C switch, or remove the old config files? Skipping this file at lib/Mail/SpamAssassin/Conf/Parser.pm line 406.
Dec 1 10:57:50.092 [23879] info: config: configuration file "/home/jhardin/develop/spamassassin/testing/require_version.cf" requires version 5.003000 of SpamAssassin, but this is code version 3.004001. Maybe you need to use the -C switch, or remove the old config files? Skipping this file
Dec 1 10:57:50.092 [23879] warn: Argument "fnord_should_be_skipped" isn't numeric in numeric ge (>=) at (eval 2526) line 1.

It emits *more* warnings, and *doesn't* actually skip parsing the
conditional in that file. :(

I suppose the only option is can(Mail::SpamAssassin::Conf::perl_min_version_5010000) after all.

That's *so* ugly.

--
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
-----------------------------------------------------------------------
We have to realize that people who run the government can and do
change. Our society and laws must assume that bad people -
criminals even - will run the government, at least part of the
time. -- John Gilmore
-----------------------------------------------------------------------
14 days until Bill of Rights day

On Mon, 1 Dec 2014, Bob Proulx wrote:

> John Hardin wrote:
>> Burnie wrote:
>>> John Hardin wrote:
>>>> 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
>>>>
>>>> Yes. That *does* work.
>>>>
>>>> Thank you! I think you just solved it.
>>>
>>> Define work...
>>>
>>> if version > 3.004001 && perl_version >= 5.010000
>>> body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
>>> endif
>>>
>>> # spamassassin --lint
>>> Dec 1 15:03:50.365 [28224] warn: Argument "perl_version" isn't numeric in
>>> numeric ge (>=) at (eval 2520) line 2.
>>
>> Dammit. I ran it (against trunk) here (with a different pseudo-var name, and
>> using version > 9) and did *not* get a type warning!
>
> Regarding this syntax I just ran a test here with exactly that
> syntax in Debian Wheezy Stable.
>
> $ spamassassin --version
> SpamAssassin version 3.3.2
> running on Perl version 5.14.2
>
> if version > 3.004001 && perl_version >= 5.010000
> meta PDS_FROM_2_EMAILS __PDS_FROM_2_EMAILS && !__VIA_ML && !__VIA_RESIGNER
> endif
>
> if version > 3.004001 && perl_version >= 5.010000
> header __PDS_FROM_2_EMAILS From =~ /^\W+([\w+.-]+\@[\w.-]+\.\w\w++)(?:[^\n\w<]{0,80})?<(?!\1)[^\n\s]*\@/i
> endif
>
> This produced no lint warnings with the above combination. I am
> missing why it is causing problems in Burnie's configuration. Is
> 3.3.1 really that different here from 3.3.2 which is silent?

I did a quick troll through the SVN history but nothing leapt out at me.
However, I'm not that familiar with the parser.

I can confirm 3.2.5 *does* generate a lint warning with that syntax (an
old VM I have).

Could somebody else running 3.3.1 confirm Burnie's results?

--
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 good of having the government prohibited from doing harm
far outweighs the harm of having it obstructed from doing good.
-- Mike@mike-istan
-----------------------------------------------------------------------
14 days until Bill of Rights day

On 12/01/2014 08:50 PM, John Hardin wrote:
> On Mon, 1 Dec 2014, Bob Proulx wrote:
>
>> $ spamassassin --version
>> SpamAssassin version 3.3.2
>> running on Perl version 5.14.2
>>
>> if version > 3.004001 && perl_version >= 5.010000
>> meta PDS_FROM_2_EMAILS __PDS_FROM_2_EMAILS && !__VIA_ML &&
>> !__VIA_RESIGNER
>> endif
>>
>> if version > 3.004001 && perl_version >= 5.010000
>> header __PDS_FROM_2_EMAILS From =~
>> /^\W+([\w+.-]+\@[\w.-]+\.\w\w++)(?:[^\n\w<]{0,80})?<(?!\1)[^\n\s]*\@/i
>> endif
>>
>> This produced no lint warnings with the above combination. I am
>> missing why it is causing problems in Burnie's configuration. Is
>> 3.3.1 really that different here from 3.3.2 which is silent?
>
> I did a quick troll through the SVN history but nothing leapt out at me.
> However, I'm not that familiar with the parser.
>
> I can confirm 3.2.5 *does* generate a lint warning with that syntax (an
> old VM I have).
>
> Could somebody else running 3.3.1 confirm Burnie's results?


A "preliminary" test here - on Perl 5.8.8 - gives the same warning in
3.3.1, 3.3.2 and 3.4.0. So it might have to do with the Perl version.


# (cd Mail-SpamAssassin-3.3.1 && ./spamassassin --lint)
Dec 1 21:15:12.602 [21690] warn: Argument "perl_version" isn't numeric
in numeric ge (>=) at (eval 313) line 2.

# (cd Mail-SpamAssassin-3.3.2 && ./spamassassin --lint)
Dec 1 21:15:20.617 [21696] warn: Argument "perl_version" isn't numeric
in numeric ge (>=) at (eval 313) line 2.

# (cd Mail-SpamAssassin-3.4.0 && ./spamassassin --lint)
Dec 1 21:15:30.946 [21706] warn: Argument "perl_version" isn't numeric
in numeric ge (>=) at (eval 314) line 2.



--
Bernt 'Burnie' Pettersen /// DoD#2345
<E-mail:burnie@dod.no> /// <URL:http://burnie.sh/>
- Creative brains need creative workhours! -

On Mon, 1 Dec 2014, John Hardin wrote:

> On Mon, 1 Dec 2014, Bob Proulx wrote:
>
>> John Hardin wrote:
>>> Burnie wrote:
>>>> John Hardin wrote:
>>>>> 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
>>>>>
>>>>> Yes. That *does* work.
>>>>>
>>>>> Thank you! I think you just solved it.
>>>>
>>>> Define work...
>>>>
>>>> if version > 3.004001 && perl_version >= 5.010000
>>>> body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
>>>> endif
>>>>
>>>> # spamassassin --lint
>>>> Dec 1 15:03:50.365 [28224] warn: Argument "perl_version" isn't numeric
>>>> in
>>>> numeric ge (>=) at (eval 2520) line 2.
>>>
>>> Dammit. I ran it (against trunk) here (with a different pseudo-var name,
>>> and
>>> using version > 9) and did *not* get a type warning!
>>
>> Regarding this syntax I just ran a test here with exactly that
>> syntax in Debian Wheezy Stable.
>>
>> $ spamassassin --version
>> SpamAssassin version 3.3.2
>> running on Perl version 5.14.2
>>
>> if version > 3.004001 && perl_version >= 5.010000
>> meta PDS_FROM_2_EMAILS __PDS_FROM_2_EMAILS && !__VIA_ML &&
>> !__VIA_RESIGNER
>> endif
>>
>> if version > 3.004001 && perl_version >= 5.010000
>> header __PDS_FROM_2_EMAILS From =~
>> /^\W+([\w+.-]+\@[\w.-]+\.\w\w++)(?:[^\n\w<]{0,80})?<(?!\1)[^\n\s]*\@/i
>> endif
>>
>> This produced no lint warnings with the above combination. I am
>> missing why it is causing problems in Burnie's configuration. Is
>> 3.3.1 really that different here from 3.3.2 which is silent?
>
> I did a quick troll through the SVN history but nothing leapt out at me.
> However, I'm not that familiar with the parser.
>
> I can confirm 3.2.5 *does* generate a lint warning with that syntax (an old
> VM I have).
>
> Could somebody else running 3.3.1 confirm Burnie's results?

# spamassassin --version
SpamAssassin version 3.3.1
running on Perl version 5.10.0


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

is silent (no errors, no warnings in a --lint)

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

throws a warning on --lint
Dec 1 16:44:30.000 [29399] warn: Argument "perl_version" isn't numeric in numeric ge (>=) at (eval 2681) line 1.

So it looks like it's perl version dependent.


--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{

On 2014-12-01 12:18, Burnie wrote:
> On 12/01/2014 08:50 PM, John Hardin wrote:
>> On Mon, 1 Dec 2014, Bob Proulx wrote:
>>
>>> $ spamassassin --version
>>> SpamAssassin version 3.3.2
>>> running on Perl version 5.14.2
>>>
>>> if version > 3.004001 && perl_version >= 5.010000
>>> meta PDS_FROM_2_EMAILS __PDS_FROM_2_EMAILS && !__VIA_ML &&
>>> !__VIA_RESIGNER
>>> endif
>>>
>>> if version > 3.004001 && perl_version >= 5.010000
>>> header __PDS_FROM_2_EMAILS From =~
>>> /^\W+([\w+.-]+\@[\w.-]+\.\w\w++)(?:[^\n\w<]{0,80})?<(?!\1)[^\n\s]*\@/i
>>> endif
>>>
>>> This produced no lint warnings with the above combination. I am
>>> missing why it is causing problems in Burnie's configuration. Is
>>> 3.3.1 really that different here from 3.3.2 which is silent?
>>
>> I did a quick troll through the SVN history but nothing leapt out at me.
>> However, I'm not that familiar with the parser.
>>
>> I can confirm 3.2.5 *does* generate a lint warning with that syntax (an
>> old VM I have).
>>
>> Could somebody else running 3.3.1 confirm Burnie's results?
>
>
> A "preliminary" test here - on Perl 5.8.8 - gives the same warning in
> 3.3.1, 3.3.2 and 3.4.0. So it might have to do with the Perl version.
>
>
> # (cd Mail-SpamAssassin-3.3.1 && ./spamassassin --lint)
> Dec 1 21:15:12.602 [21690] warn: Argument "perl_version" isn't numeric in
> numeric ge (>=) at (eval 313) line 2.
>
> # (cd Mail-SpamAssassin-3.3.2 && ./spamassassin --lint)
> Dec 1 21:15:20.617 [21696] warn: Argument "perl_version" isn't numeric in
> numeric ge (>=) at (eval 313) line 2.
>
> # (cd Mail-SpamAssassin-3.4.0 && ./spamassassin --lint)
> Dec 1 21:15:30.946 [21706] warn: Argument "perl_version" isn't numeric in
> numeric ge (>=) at (eval 314) line 2.

I just added the following to my user-prefs file:
if version > 3.004001 && perl_version >= 5.010000
meta PDS_FROM_2_EMAILS __PDS_FROM_2_EMAILS && !__VIA_ML &&
!__VIA_RESIGNER
endif

No error here SL6.6, perl 5.10.1 and SA 3.3.1.

{^_^}

On Mon, 1 Dec 2014, David B Funk wrote:

> # spamassassin --version
> SpamAssassin version 3.3.1
> running on Perl version 5.10.0
>
>
> if version > 3.004001 && perl_version >= 5.010000
> body NON_588_COMPATIBLE_RE_SYNTAX /\w++/
> endif
>
> is silent (no errors, no warnings in a --lint)
>
> So it looks like it's perl version dependent.

Which doesn't help.

It looks like as long as we support perl < 5.10.0 then the only clean
solution is can(Mail::SpamAssassin::Conf::perl_min_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
-----------------------------------------------------------------------
We have to realize that people who run the government can and do
change. Our society and laws must assume that bad people -
criminals even - will run the government, at least part of the
time. -- John Gilmore
-----------------------------------------------------------------------
14 days until Bill of Rights day

On 12/01/2014 09:18 PM, Burnie wrote:
> On 12/01/2014 08:50 PM, John Hardin wrote:
>> On Mon, 1 Dec 2014, Bob Proulx wrote:
>>
>>> $ spamassassin --version
>>> SpamAssassin version 3.3.2
>>> running on Perl version 5.14.2
>>>
>>> if version > 3.004001 && perl_version >= 5.010000
>>> meta PDS_FROM_2_EMAILS __PDS_FROM_2_EMAILS && !__VIA_ML &&
>>> !__VIA_RESIGNER
>>> endif

> A "preliminary" test here - on Perl 5.8.8 - gives the same warning in
> 3.3.1, 3.3.2 and 3.4.0. So it might have to do with the Perl version.


just a quick followup after a bit more testing here
- by just upgrading perl on a vm
- perl 5.8.8 gives the warning in 3.3.1 - 3.4.0
- perl 5.10.1 doesn't


--
Bernt 'Burnie' Pettersen /// DoD#2345
<E-mail:burnie@dod.no> /// <URL:http://burnie.sh/>
- Creative brains need creative workhours! -

On 12/1/2014 6:06 PM, John Hardin wrote:
>
> It looks like as long as we support perl < 5.10.0 then the only clean
> solution is can(Mail::SpamAssassin::Conf::perl_min_version_5010000)
With perl versions so low in so many distros, I think we have to
implement the perl_min_version function. Do you want me to take a stab
at it?
Regards,
KAM

On Mon, 1 Dec 2014, Kevin A. McGrail wrote:

> On 12/1/2014 6:06 PM, John Hardin wrote:
>>
>> It looks like as long as we support perl < 5.10.0 then the only clean
>> solution is can(Mail::SpamAssassin::Conf::perl_min_version_5010000)
>
> With perl versions so low in so many distros, I think we have to implement
> the perl_min_version function. Do you want me to take a stab at it?

Nah, it's in my head, I'll do it tonight.

--
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
-----------------------------------------------------------------------
14 days until Bill of Rights day

On Mon, 1 Dec 2014, Kevin A. McGrail wrote:

> On 12/1/2014 6:06 PM, John Hardin wrote:
>>
>> It looks like as long as we support perl < 5.10.0 then the only clean
>> solution is can(Mail::SpamAssassin::Conf::perl_min_version_5010000)
>
> With perl versions so low in so many distros, I think we have to implement
> the perl_min_version function. Do you want me to take a stab at it?

Do we want to be able to check every major perl version (i.e., define
perl_min_version_5010000, perl_min_version_5011000,
perl_min_version_5012000, perl_min_version_5013000,
perl_min_version_5014000, perl_min_version_5015000,
perl_min_version_5016000, etc.) ?


--
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
-----------------------------------------------------------------------
"They will be slaughtered as result of England's anti-gun laws
that concentrates power to the Government."
-- Shifty Powers (101 abn) observing British
subjects training to repel a German invasion
using rakes, hoes and pitchforks
-----------------------------------------------------------------------
14 days until Bill of Rights day

On 12/1/2014 8:03 PM, John Hardin wrote:
> On Mon, 1 Dec 2014, Kevin A. McGrail wrote:
>
>> On 12/1/2014 6:06 PM, John Hardin wrote:
>>>
>>> It looks like as long as we support perl < 5.10.0 then the only clean
>>> solution is can(Mail::SpamAssassin::Conf::perl_min_version_5010000)
>>
>> With perl versions so low in so many distros, I think we have to
>> implement the perl_min_version function. Do you want me to take a
>> stab at it?
>
> Do we want to be able to check every major perl version (i.e., define
> perl_min_version_5010000, perl_min_version_5011000,
> perl_min_version_5012000, perl_min_version_5013000,
> perl_min_version_5014000, perl_min_version_5015000,
> perl_min_version_5016000, etc.) ?
>
>
For now, the only issue that has ever arisen in years is the 5010000
test so I would stick with just that for now.

Regards,
KAM

On Mon, 1 Dec 2014, Kevin A. McGrail wrote:

> On 12/1/2014 8:03 PM, John Hardin wrote:
>> On Mon, 1 Dec 2014, Kevin A. McGrail wrote:
>>
>> > On 12/1/2014 6:06 PM, John Hardin wrote:
>> > >
>> > > It looks like as long as we support perl < 5.10.0 then the only clean
>> > > solution is can(Mail::SpamAssassin::Conf::perl_min_version_5010000)
>> >
>> > With perl versions so low in so many distros, I think we have to
>> > implement the perl_min_version function. Do you want me to take a stab
>> > at it?
>>
>> Do we want to be able to check every major perl version (i.e., define
>> perl_min_version_5010000, perl_min_version_5011000,
>> perl_min_version_5012000, perl_min_version_5013000,
>> perl_min_version_5014000, perl_min_version_5015000,
>> perl_min_version_5016000, etc.) ?
>
> For now, the only issue that has ever arisen in years is the 5010000 test so
> I would stick with just that for now.

Ok.

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7107

--
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
-----------------------------------------------------------------------
Our government should bear in mind the fact that the American
Revolution was touched off by the then-current government
attempting to confiscate firearms from the people.
-----------------------------------------------------------------------
14 days until Bill of Rights day

On 12/02/2014 03:12 AM, John Hardin wrote:
> On Mon, 1 Dec 2014, Kevin A. McGrail wrote:
>
>> On 12/1/2014 8:03 PM, John Hardin wrote:
>>
>> For now, the only issue that has ever arisen in years is the 5010000
>> test so I would stick with just that for now.
>
> Ok.
>
> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7107


Just FYI: The nested if example in the patch/doc will still
give a lint warning for perl < 5.10

if can(Mail::SpamAssassin::Conf::perl_min_version_5010000)
if version > 3.004001 && perl_version >= 5.018000
body INVALID_RE_SYNTAX_IN_PERL_BEFORE_5_18 /(?[ \p{Thai} &
\p{Digit} ])/
endif
endif

Dec 2 03:53:48.550 [30251] warn: Argument "perl_version" isn't numeric
in numeric ge (>=) at (eval 2521) line 2.



- IMHO, that single '+' character may be the single most annoying
character in SA for years? :-\

--
Bernt 'Burnie' Pettersen /// DoD#2345
<E-mail:burnie@dod.no> /// <URL:http://burnie.sh/>
- Creative brains need creative workhours! -

On 02/12/2014 10:24, Kevin A. McGrail wrote:

> On 12/1/2014 6:06 PM, John Hardin wrote:
>
>> It looks like as long as we support perl < 5.10.0 then the only clean solution is can(Mail::SpamAssassin::Conf::perl_min_version_5010000)
>
> With perl versions so low in so many distros, I think we have to implement the perl_min_version function. Do you want me to take a stab at it?
> Regards,
> KAM

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)

On 12/1/2014 11:57 PM, Noel Butler wrote:
>
> On 02/12/2014 10:24, Kevin A. McGrail wrote:
>
>> On 12/1/2014 6:06 PM, John Hardin wrote:
>>> It looks like as long as we support perl < 5.10.0 then the only
>>> clean solution is
>>> can(Mail::SpamAssassin::Conf::perl_min_version_5010000)
>> With perl versions so low in so many distros, I think we have to implement the perl_min_version function. Do you want me to take a stab at it?
>> Regards,
>> KAM
>
> 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.

Regards,
KAM

Hello Noel,

Tuesday, December 2, 2014, 4:57:08 AM, you wrote:

NB> 5.10 is only what, six years old? Surely anyone running anything older have far greater issues

CentOS 5.11 doesn't go EOL until 2017 and it has 5.8.8

--
Best regards,
Niamh mailto:niamh@fullbore.co.uk

jdow skrev den 2014-12-01 23:56:

> I just added the following to my user-prefs file:
> if version > 3.004001 && perl_version >= 5.010000
> meta PDS_FROM_2_EMAILS __PDS_FROM_2_EMAILS && !__VIA_ML &&
> !__VIA_RESIGNER
> endif
>
> No error here SL6.6, perl 5.10.1 and SA 3.3.1.

good, but 3.4.2 does not exists yet :)

On Tue, 2 Dec 2014, Burnie wrote:

> On 12/02/2014 03:12 AM, John Hardin wrote:
>> On Mon, 1 Dec 2014, Kevin A. McGrail wrote:
>>
>> > On 12/1/2014 8:03 PM, John Hardin wrote:
>> >
>> > For now, the only issue that has ever arisen in years is the 5010000
>> > test so I would stick with just that for now.
>>
>> Ok.
>>
>> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7107
>
> Just FYI: The nested if example in the patch/doc will still
> give a lint warning for perl < 5.10
>
> if can(Mail::SpamAssassin::Conf::perl_min_version_5010000)
> if version > 3.004001 && perl_version >= 5.018000
> body INVALID_RE_SYNTAX_IN_PERL_BEFORE_5_18 /(?[ \p{Thai} & \p{Digit}
> ])/
> endif
> endif
>
> Dec 2 03:53:48.550 [30251] warn: Argument "perl_version" isn't numeric in
> numeric ge (>=) at (eval 2521) line 2.

ARGH!

Well, I suppose we're back to hoping the distro maintainers accept the
perl_version patch for their LTR release versions of older SA releases.

> - IMHO, that single '+' character may be the single most annoying character
> in SA for years? :-\

indeed.

--
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
-----------------------------------------------------------------------
Men by their constitutions are naturally divided in to two parties:
1. Those who fear and distrust the people and wish to draw all
powers from them into the hands of the higher classes. 2. Those who
identify themselves with the people, have confidence in them,
cherish and consider them as the most honest and safe, although not
the most wise, depository of the public interests.
-- Thomas Jefferson
-----------------------------------------------------------------------
13 days until Bill of Rights day

On 2014-12-02 10:10, John Hardin wrote:
> On Tue, 2 Dec 2014, Burnie wrote:
>
>> On 12/02/2014 03:12 AM, John Hardin wrote:
>>> On Mon, 1 Dec 2014, Kevin A. McGrail wrote:
>>>
>>> > On 12/1/2014 8:03 PM, John Hardin wrote:
>>> > > For now, the only issue that has ever arisen in years is the 5010000
>>> > test so I would stick with just that for now.
>>>
>>> Ok.
>>>
>>> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7107
>>
>> Just FYI: The nested if example in the patch/doc will still
>> give a lint warning for perl < 5.10
>>
>> if can(Mail::SpamAssassin::Conf::perl_min_version_5010000)
>> if version > 3.004001 && perl_version >= 5.018000
>> body INVALID_RE_SYNTAX_IN_PERL_BEFORE_5_18 /(?[ \p{Thai} & \p{Digit} ])/
>> endif
>> endif
>>
>> Dec 2 03:53:48.550 [30251] warn: Argument "perl_version" isn't numeric in
>> numeric ge (>=) at (eval 2521) line 2.
>
> ARGH!
>
> Well, I suppose we're back to hoping the distro maintainers accept the
> perl_version patch for their LTR release versions of older SA releases.
>
>> - IMHO, that single '+' character may be the single most annoying character in
>> SA for years? :-\
>
> indeed.

Does this show the error?

if can(Mail::SpamAssassin::Conf::perl_min_version_5010000)
&& version > 3.004001 && perl_version >= 5.018000
body INVALID_RE_SYNTAX_IN_PERL_BEFORE_5_18 /(?[ \p{Thai} & \p{Digit} ])/
endif

Perhaps the same trick can (almost) work again.

{^_^}

> -----Original Message-----
> From: Niamh Holding [mailto:niamh@fullbore.co.uk]
> Sent: Tuesday, December 02, 2014 7:27 AM
> To: users@spamassassin.apache.org
> Subject: Re: Argument "perl_version" isn't numeric
>
>
> Hello Noel,
>
> Tuesday, December 2, 2014, 4:57:08 AM, you wrote:
>
> NB> 5.10 is only what, six years old? Surely anyone running anything
> older have far greater issues
>
> CentOS 5.11 doesn't go EOL until 2017 and it has 5.8.8
>
> --
> Best regards,
> Niamh mailto:niamh@fullbore.co.uk

Which brings up the question, what is spamassassin being developed on? I like long term releases for obvious reasons - upgrading servers every year or two gets old. But it's nice to match the tool to the job, so it might be instructive to know what the development environment looks like so when upgrading or installing a new server one can match it, more or less...

...Kevin
--
Kevin Miller
Network/email Administrator, CBJ MIS Dept.
155 South Seward Street
Juneau, Alaska 99801
Phone: (907) 586-0242, Fax: (907) 586-4500
Registered Linux User No: 307357

On 12/2/2014 3:10 PM, jdow wrote:
> On 2014-12-02 10:10, John Hardin wrote:
>> On Tue, 2 Dec 2014, Burnie wrote:
>>
>>> On 12/02/2014 03:12 AM, John Hardin wrote:
>>>> On Mon, 1 Dec 2014, Kevin A. McGrail wrote:
>>>>
>>>> > On 12/1/2014 8:03 PM, John Hardin wrote:
>>>> > > For now, the only issue that has ever arisen in years is the
>>>> 5010000
>>>> > test so I would stick with just that for now.
>>>>
>>>> Ok.
>>>>
>>>> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7107
>>>
>>> Just FYI: The nested if example in the patch/doc will still
>>> give a lint warning for perl < 5.10
>>>
>>> if can(Mail::SpamAssassin::Conf::perl_min_version_5010000)
>>> if version > 3.004001 && perl_version >= 5.018000
>>> body INVALID_RE_SYNTAX_IN_PERL_BEFORE_5_18 /(?[ \p{Thai} &
>>> \p{Digit} ])/
>>> endif
>>> endif
>>>
>>> Dec 2 03:53:48.550 [30251] warn: Argument "perl_version" isn't
>>> numeric in
>>> numeric ge (>=) at (eval 2521) line 2.
>>
>> ARGH!
>>
>> Well, I suppose we're back to hoping the distro maintainers accept the
>> perl_version patch for their LTR release versions of older SA releases.
>>
>>> - IMHO, that single '+' character may be the single most annoying
>>> character in
>>> SA for years? :-\
>>
>> indeed.
>
> Does this show the error?
>
> if can(Mail::SpamAssassin::Conf::perl_min_version_5010000)
> && version > 3.004001 && perl_version >= 5.018000
> body INVALID_RE_SYNTAX_IN_PERL_BEFORE_5_18 /(?[ \p{Thai} &
> \p{Digit} ])/
> endif
>
> Perhaps the same trick can (almost) work again.
>
> {^_^}

There is no need for the other checks.

if can(Mail::SpamAssassin::Conf::perl_min_version_5010000) is enough
since it doesn't exist until 3.4.1.

If you are locally using SA trunk and writing your own rules that
require certain perl_versions, you can use the if perl_version >= XYZ
logic without concern.

regards,
KAM

--
*Kevin A. McGrail*
President

Peregrine Computer Consultants Corporation
3927 Old Lee Highway, Suite 102-C
Fairfax, VA 22030-2422

http://www.pccc.com/

703-359-9700 x50 / 800-823-8402 (Toll-Free)
703-798-0171 (wireless)
KMcGrail@PCCC.com <mailto:kmcgrail@pccc.com>

On 2014-12-02 12:15, Kevin A. McGrail wrote:
> On 12/2/2014 3:10 PM, jdow wrote:
>> On 2014-12-02 10:10, John Hardin wrote:
>>> On Tue, 2 Dec 2014, Burnie wrote:
>>>
>>>> On 12/02/2014 03:12 AM, John Hardin wrote:
>>>>> On Mon, 1 Dec 2014, Kevin A. McGrail wrote:
>>>>>
>>>>> > On 12/1/2014 8:03 PM, John Hardin wrote:
>>>>> > > For now, the only issue that has ever arisen in years is the 5010000
>>>>> > test so I would stick with just that for now.
>>>>>
>>>>> Ok.
>>>>>
>>>>> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7107
>>>>
>>>> Just FYI: The nested if example in the patch/doc will still
>>>> give a lint warning for perl < 5.10
>>>>
>>>> if can(Mail::SpamAssassin::Conf::perl_min_version_5010000)
>>>> if version > 3.004001 && perl_version >= 5.018000
>>>> body INVALID_RE_SYNTAX_IN_PERL_BEFORE_5_18 /(?[ \p{Thai} & \p{Digit} ])/
>>>> endif
>>>> endif
>>>>
>>>> Dec 2 03:53:48.550 [30251] warn: Argument "perl_version" isn't numeric in
>>>> numeric ge (>=) at (eval 2521) line 2.
>>>
>>> ARGH!
>>>
>>> Well, I suppose we're back to hoping the distro maintainers accept the
>>> perl_version patch for their LTR release versions of older SA releases.
>>>
>>>> - IMHO, that single '+' character may be the single most annoying character in
>>>> SA for years? :-\
>>>
>>> indeed.
>>
>> Does this show the error?
>>
>> if can(Mail::SpamAssassin::Conf::perl_min_version_5010000)
>> && version > 3.004001 && perl_version >= 5.018000
>> body INVALID_RE_SYNTAX_IN_PERL_BEFORE_5_18 /(?[ \p{Thai} & \p{Digit} ])/
>> endif
>>
>> Perhaps the same trick can (almost) work again.
>>
>> {^_^}
>
> There is no need for the other checks.
>
> if can(Mail::SpamAssassin::Conf::perl_min_version_5010000) is enough since it
> doesn't exist until 3.4.1.
>
> If you are locally using SA trunk and writing your own rules that require
> certain perl_versions, you can use the if perl_version >= XYZ logic without concern.
>
> regards,
> KAM
>
> --
> *Kevin A. McGrail*
> President
>
> Peregrine Computer Consultants Corporation
> 3927 Old Lee Highway, Suite 102-C
> Fairfax, VA 22030-2422
>
> http://www.pccc.com/
>
> 703-359-9700 x50 / 800-823-8402 (Toll-Free)
> 703-798-0171 (wireless)
> KMcGrail@PCCC.com <mailto:kmcgrail@pccc.com>
>

Perhaps test it just the same to see if the basic technique works? I suspect it
should. That way it may be a messy way to handle the problem without falling
into even nastier messes.

{o.o}

On 12/02/2014 09:10 PM, jdow wrote:
> Does this show the error?
>
> if can(Mail::SpamAssassin::Conf::perl_min_version_5010000)
> && version > 3.004001 && perl_version >= 5.018000
> body INVALID_RE_SYNTAX_IN_PERL_BEFORE_5_18 /(?[ \p{Thai} & \p{Digit} ])/
> endif

It doesn't show the warning.

But the line starting with '&&' will generate a more severe warning
when the first line is 'true'. (SA lint exits with code 1)


Testing perl 5.16 / SA 3.4.0:

if version >= 3.003001
&& version >= 3.004000 && perl_version >= 5.018000
body INVALID_RE_SYNTAX_IN_PERL_BEFORE_5_10 /\w++/
endif

Dec 2 22:14:35.776 [31075] warn: config: failed to parse line,
skipping, in "/etc/mail/spamassassin/local.cf": && version > 3.004000 &&
perl_version >= 5.018000
Dec 2 22:14:35.801 [31075] warn: lint: 1 issues detected, please rerun
with debug enabled for more information


- And if you put it all in one line with perl < 5.10, SA lint will
complain about perl_version

--
Bernt 'Burnie' Pettersen /// DoD#2345
<E-mail:burnie@dod.no> /// <URL:http://burnie.sh/>
- Creative brains need creative workhours! -

jdow wrote:
> John Hardin wrote:
> > Bob Proulx wrote:
> > > 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.
> >
> > Oh, it won't do that.
> >
> > It's just embarrassing as all hell to publicly step on my sword in
> > this manner.
>
> Stepped in a "richard", you did. (Read Terry Pratchett's "Dodger" if you
> must to get the term's meaning and origin.)

I don't want to pour salt on the wound but if you can laugh at it then
all is good. Laughter is the best medicine! I keep thinking of this
classic Dilbert. I have been there myself too many times. :-)

http://dilbert.com/strips/comic/1995-08-18/

Bob

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

On Tue, 2 Dec 2014, jdow wrote:

> On 2014-12-02 12:15, Kevin A. McGrail wrote:
>> On 12/2/2014 3:10 PM, jdow wrote:
>> > On 2014-12-02 10:10, John Hardin wrote:
>> > > On Tue, 2 Dec 2014, Burnie wrote:
>> > >
>> > > > On 12/02/2014 03:12 AM, John Hardin wrote:
>> > > > > On Mon, 1 Dec 2014, Kevin A. McGrail wrote:
>> > > > >
>> > > > > > On 12/1/2014 8:03 PM, John Hardin wrote:
>> > > > > > > For now, the only issue that has ever arisen in years is the
>> > > > > > > 5010000
>> > > > > > test so I would stick with just that for now.
>> > > > >
>> > > > > Ok.
>> > > > >
>> > > > > https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7107
>> > > >
>> > > > Just FYI: The nested if example in the patch/doc will still
>> > > > give a lint warning for perl < 5.10
>> > > >
>> > > > if can(Mail::SpamAssassin::Conf::perl_min_version_5010000)
>> > > > if version > 3.004001 && perl_version >= 5.018000
>> > > > body INVALID_RE_SYNTAX_IN_PERL_BEFORE_5_18 /(?[ \p{Thai} &
>> > > > \p{Digit} ])/
>> > > > endif
>> > > > endif
>> > > >
>> > > > Dec 2 03:53:48.550 [30251] warn: Argument "perl_version" isn't
>> > > > numeric in
>> > > > numeric ge (>=) at (eval 2521) line 2.
>> > >
>> > > ARGH!
>> > >
>> > > Well, I suppose we're back to hoping the distro maintainers accept the
>> > > perl_version patch for their LTR release versions of older SA
>> > > releases.
>> > >
>> > > > - IMHO, that single '+' character may be the single most annoying
>> > > > character in
>> > > > SA for years? :-\
>> > >
>> > > indeed.
>> >
>> > Does this show the error?
>> >
>> > if can(Mail::SpamAssassin::Conf::perl_min_version_5010000)
>> > && version > 3.004001 && perl_version >= 5.018000
>> > body INVALID_RE_SYNTAX_IN_PERL_BEFORE_5_18 /(?[ \p{Thai} &
>> > \p{Digit} ])/
>> > endif
>> >
>> > Perhaps the same trick can (almost) work again.
>> >
>> > {^_^}
>>
>> There is no need for the other checks.
>>
>> if can(Mail::SpamAssassin::Conf::perl_min_version_5010000) is enough since
>> it
>> doesn't exist until 3.4.1.
>>
>> If you are locally using SA trunk and writing your own rules that require
>> certain perl_versions, you can use the if perl_version >= XYZ logic
>> without concern.
>>
>> regards,
>> KAM
>
> Perhaps test it just the same to see if the basic technique works? I suspect
> it should. That way it may be a messy way to handle the problem without
> falling into even nastier messes.

I suspect it will fail just the same. I think it's something related to
shortcut logic in evals in 5.8.x, but I couldn't find anything in the
various perl release notes that looked relevant to that.

--
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
-----------------------------------------------------------------------
Running away is the coward's way out of a war;
appeasement is the coward's way into a war. -- Thorax
-----------------------------------------------------------------------
13 days until Bill of Rights day

On 12/2/2014 5:50 PM, Noel Butler wrote:
>
> 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 :)
>
Well, I also can't justify requiring a newer version of Perl just for
one regexp.

Regards,
KAM

On 03/12/2014 12:10, Kevin A. McGrail wrote:

>> 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 :)
> Well, I also can't justify requiring a newer version of Perl just for one regexp.
>
> Regards,
> KAM

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.

On 12/2/2014 10:59 PM, Noel Butler wrote:
>
> On 03/12/2014 12:10, Kevin A. McGrail wrote:
>
>>> 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 :)
>>>
>> Well, I also can't justify requiring a newer version of Perl just for
>> one regexp.
>
> 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

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.

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

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

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

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

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

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

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