Mailing List Archive

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

--- Comment #2 from AXB <axb.lists@gmail.com> ---
(In reply to Kevin A. McGrail from comment #0)
> and slave will be changed to child.

"killing child" sounds socially acceptable...

--
You are receiving this mail because:
You are the assignee for the bug.

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

macosx10.4.11@gmail.com changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |macosx10.4.11@gmail.com

--- Comment #3 from macosx10.4.11@gmail.com ---
Is this a joke?

--
You are receiving this mail because:
You are the assignee for the bug.

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

--- Comment #4 from Bill Cole <billcole@apache.org> ---
(In reply to macosx10.4.11 from comment #3)
> Is this a joke?

No.

Using colors as a good/bad metaphorical idiom is inaccurate for how SA uses
such lists and has the added problem of colliding with the intractable
idiomatic use of "Black" and "White" for arbitrary classes of people. Naming
collisions are inherently bad, and we can't fix the larger side of this one.
Switching to allow/block better reflects what SA does without requiring a
subtle understanding of any English metaphorical idiom.

The use of master/slave in SA is limited to tools in the build directory, which
are of interest primarily to active members of the SA development, project
sysadmin, and masscheck submitter communities. There *may* be some sites with
independent automc and rule QA rigs, but there's no evidence of that. The usage
includes scripts for Jenkins, which dropped 'slave' terminology in v2.0 (2016.)
I am not entirely conversant with the automc & buildbot architecture where
'slave' is used, but a cursory examination leads me to believe that 'child' or
perhaps 'worker' or 'robot' is a more apt metaphor for the tasks where 'slave'
is currently used.

In spamd, 'child' is already used consistently.

(In reply to AXB from comment #2)
> "killing child" sounds socially acceptable...

Moot point: there are no references in any SA code or comments to killing
slaves.

We already announce that we are "killing failed child" in
lib/Mail/SpamAssassin/SpamdForkScaling.pm which does seem to fall short of the
modern norms of good parenting. However, the standard terminology of the
Unix/Linux/POSIX process model makes it unwieldy to avoid references to killing
children.

--
You are receiving this mail because:
You are the assignee for the bug.

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

Bill Cole <billcole@apache.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Version|4.0.0 |unspecified
Target Milestone|Undefined |4.0.0
OS|Windows NT |All
Hardware|PC |All

--
You are receiving this mail because:
You are the assignee for the bug.

Hi Loren, yes, I did notice that and sorry it broke. Are you using trunk
on a production system? If so, you might consider downgrading to 3.4.4
released or 3.4.5-pre1 for a little while.
Regards,
KAM
--
Kevin A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171


On Fri, Jul 10, 2020 at 2:08 AM <bugzilla-daemon@spamassassin.apache.org>
wrote:

> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826
>
> --- Comment #33 from Loren Wilton <lwilton@earthlink.net> ---
> Kevin, did you notice bug 7836, linked as a duplicate of this?
>
> Reporter: jidanni@jidanni.org
> Target Milestone: Undefined
>
> Updating spamassassin makes it unusable.
>
> sa-update shows several
>
> rules: failed to run __FROM_ADDRLIST_BANKS test, skipping:
> (Can't locate object method "_check_whitelist" via package
> "Mail::SpamAssassin::Plugin::WLBLEval" at
>
> /home/jidanni/.spamassassin-tree/share/perl/5.30.3/Mail/SpamAssassin/Plugin/WLBLEval.pm
> line 119.
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.

On Fri, Jul 10, 2020 at 2:12 AM <bugzilla-daemon@spamassassin.apache.org>
wrote:

> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826
>
> --- Comment #34 from Henrik Krohns <apache@hege.li> ---
> (In reply to Kevin A. McGrail from comment #32)
> >
> > Please remember with votes being made on this thread, you should be
> waiting
> > 72 hours for people to weigh in.
>
> People have weighted in.
>

Which is why I have started working again. :-)


> Again, who is "we"? Why would _trunk_ have any effect in your "two
> systems"?
> Use a branch as suggested, so no other change in trunk will bother your
> testings etc. And people will actually have something to weight in, before
> things break!!
>

We is myself and my staff. The changes others made on this bug to trunk
had an effect because we already had fixes ready to commit but we had to
backtrack them.

A branch is a bad suggestion due to the number of testers we need and it
doesn't test ruleqa/masscheck.

From the way this bug started, I have little faith in the way you are
> going on

about it. Is there even a plan?? Where is it?


Of course there is a plan. See the top of the bz 7826 for the high-level
plan which is effectively this:

Anything referencing whitelist will be welcomelist (it was originally
allowlist but the PoC led to a good recommendation to use that).
Blacklist to Blocklist, Master to Parent, Slave to Child.

backwards compatibility will work for at least a year and until at least
4.1 is released.

all backwards compatibility will be documented as deprecated

The first commit was a proof of concept for just one function
(whitelist_to) to see what would break and how it worked in the live
system. It broke worse than expected because I forgot a part of the commit
but led to the good idea of using welcomelist.

I've just committed a second version of the proof of concept for
whitelist_to. If it looks good, next up is whitelist_from. From there,
rinse and repeat until done.

I recognize that people are using trunk and were upset by this so I will be
more careful on commits.


> What things are you going to
> rename?

Anything that references the terms above.


> What things are you going to break? "I'm going to rename WLBL to
> ALBL... uhh no it's not necessary to rename it..",

It was necessary to rename it originally because Whitelist was becoming
Allowlist so ALBL made sense. The idea of Welcomelist, however, is perfect
and removes that need.


> how about actually posting
> the complete plan and waiting for people to weight in on all the renames?


Let me know if the plan above is not sufficient. Happy to give you more
insight and discuss for consensus. In my defense, I write voluminous notes
and plan things out.


> Or do
> as suggested and go on implementing the things in [ed: a branch] so we
> have review and
> test the changes easily, instead of yet again more questions in mailing
> lists
> on why there are errors and why rule updates are not working etc.
>

Sorry but no, a branch will just hide issues. We need to find bugs.
However, I really think the rough part is over and we have a repeatable
roadmap. PoC 1 had a mistake in the commit. PoC 2 looks clean and will be
mimicked for the continuation of the work.

Regards,
KAM

On Fri, Jul 10, 2020 at 02:55:34AM -0400, Kevin A. McGrail wrote:
>
> A branch is a bad suggestion due to the number of testers we need and it
> doesn't test ruleqa/masscheck.

Sorry but I still don't agree at all. First and most important tester is
_you_. Don't commit stuff that may break things in production. I consider
trunk production, since I've used it always, many people use it, and
masscheck uses it. I do my utmost not to commit stuff that breaks it or
backwards compatibility.

Renaming things is invasive and prone to break things. Especially when done
in small batches over time, which makes no sense for review purposes. I
would much rather see everything done (branch hello?) and _then_ you can
call for a large mass to test it, and do a controlled test in masscheck,
it's not rocket science. Of course it's all the SA committers duty to also
test things out, not the general public at first.


> The first commit was a proof of concept for just one function (whitelist_to) to
> see what would break and how it?worked in?the live system.? It broke worse than
> expected because I forgot a part of the commit but led to the good idea of
> using welcomelist.

"part of the commit"? That's downplaying it, you didn't seem to even
consider leaving old eval functions in..


> Sorry but no, a branch will just hide issues.? We need to find bugs.

So put this issue to an actual vote and wait for all the votes, instead of
sounding like a dictator.

But anyway, I'm so over this.. I will not be a part of this and not reply
anymore. But if you break my trunk installation, I will be angry.

On Fri, Jul 10, 2020 at 3:10 AM Henrik K <hege@hege.li> wrote:

> Sorry but I still don't agree at all. First and most important tester is
> _you_. Don't commit stuff that may break things in production.


I thought active.list might break but otherwise thought it was a good
patch. I forgot about eval rules.


> Especially when done
>
in small batches over time, which makes no sense for review purposes.

We will agree to disagree. I wanted a roadmap to how to do the rest of the
work so I didn't have to redo thousands of lines of changes. So picking
one small change makes sense to me.


>
> Sorry but no, a branch will just hide issues. We need to find bugs.
>
> So put this issue to an actual vote and wait for all the votes, instead of
> sounding like a dictator.
>

Never my intent to be a dictator and I did get votes on the work I did. If
you want a vote on a branch, just call one. I respected the discussion in
the bugzilla and considered it a vote, did I note? Disagreeing is not the
same as being a dictator and I voted just like everyone else.

Technically, I don't think a branch would help because rules are only in
trunk, masscheck/ruleqa only runs on trunk, and hence, changes would be
needed there even with a branch. But I'll +1 a vote to move active
development to a 4.0 branch and changing only rules on trunk so trunk stays
as stable as it can while 4.0 branch can be able to be more of a normal
development branch with the risk inherent therein. I think that will risk
trunk getting out of sync and stale but that might be a benefit if
stability is a desire.

>
> But anyway, I'm so over this.. I will not be a part of this and not reply
> anymore. But if you break my trunk installation, I will be angry.
>

No one is trying to break anyone's trunk installation and I don't want to
see you angry.

Regards,
KAM

On 7/10/2020 2:30 PM, ??? Dan Jacobson wrote:
> KAM> Are you using trunk on a production system?
>
> Let's just say that whatever you do, be sure that an email can still be
> processed. And if not, revert within five minutes. As that is when I
> will try to update again if my first update fails to process emails. Thanks.

How does a change on the svn trunk stop your system from processing an
email?

If you are using trunk on a production system, do so from a snapshot. 
Are you interested in routine 4.0.0-pre releases?

Regards,

KAM

--
Kevin A. McGrail
KMcGrail@Apache.org

Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171

On 7/14/20 6:50 PM, bugzilla-daemon@spamassassin.apache.org wrote:
> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826
>
> --- Comment #48 from John Hardin <jhardin@impsec.org> ---
> (In reply to Kevin A. McGrail from comment #0)
>
>> - Old configuration terms will continue to work for no less than one year
>> and will not be dropped until a version change such as 4.0 to 4.1.
>
> I also want to make it clear I *strongly* suggest that the old terms continue
> to be supported as aliases *indefinitely*, absent a strong technical reason to
> end such support. And I feel "to keep the code clean" isn't sufficiently strong
> in this case.
>
> Do we need a PMC vote on this detail?

You have my official +1 to that

On Mon, 3 Aug 2020, John Wilcock wrote:

> On 2020-08-01 21:23, bugzilla-daemon@spamassassin.apache.org wrote:
>
>> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826
>>
>> --- Comment #58 from Kevin A. McGrail <kmcgrail@apache.org> ---
>> (In reply to John Hardin from comment #57) (In reply to Kevin A. McGrail from comment #55)
>>
>> This isn't a plugin to disable features (i.e. deprecate), it's to enable them.
>> So name it "EnableDeprecatedTerminology.pm"
>>
>> I second the objection to "RaciallyCharged.pm". Doing that is essentially
>> scolding anyone who enables backwards compatibility features.
>
> The RaciallyCharged plugin doesn't enabled deprecated terminology, it
> enables the racially charged language. It's used in the rules
> specifically for this issue and the tests as well for backwards
> compatible. It won't be suitable as a generic plugin. The plugin
> describes exactly what the plugin does and I stand by the name. People
> should stop using the language.


> As you cannot fail to be aware if you read even a fraction of the list
> messages on this topic, there is absolutely no consensus that
> blacklist/whitelist etc. are racially charged terms. Some perceive them
> as such, sure, but others disagree, and indeed some disagree rather
> strongly. It would seem fitting to avoid a divisive name for re-enabling
> the terms.
>
> What is indisputable is that the project has chosen to deprecate the
> terms, regardless of the reasons for that deprecation. It is equally
> indisputable that the plugin is for backward compatibility reasons. So
> how about EnableDeprecatedTerminology or
> EnableBackwardCompatibilityTerminology, which would be accurate and far
> less divisive names. I suppose it might be argued that another plugin
> might be needed in the future for enabling terms deprecated for other
> reasons. If that is a worry, then call this one
> EnableDeprecatedBlackWhiteTerminology or
> EnableBackCompatBlackWhiteTerminology.

Or perhaps "EnableDeprecatedTerminology_bug7826.pm" to make it more
specific to the terminology in question. This provides us a pattern for
future use should other terms ever need to be deprecated for some reason.

--
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
-----------------------------------------------------------------------
If asking Hillary to disarm is a call for her assassination,
then asking the American people to disarm is calling for
their genocide. -- Jeff Ingebritson
-----------------------------------------------------------------------
Tomorrow: the 285th anniversary of John Peter Zenger's acquittal

On Tue, 29 Dec 2020, bugzilla-daemon@spamassassin.apache.org wrote:

> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826
>
> --- Comment #60 from Kevin A. McGrail <kmcgrail@apache.org> ---
> svn commit -m 'whitelist_auth to welcomelist_auth,
> unwhitelist_auth to unwelcomelist_auth,
> def_whitelist_auth to def_welcomelist_auth,
> check_forged_in_whitelist to check_forged_in_welcomelist,
> check_from_in_default_whitelist to check_from_in_default_welcomelist,
> check_uri_host_in_whitelist to check_uri_host_in_welcomelist,
> check_from_in_blacklist to check_from_in_blocklist,
> check_to_in_blacklist to check_from_in_blocklist,
> check_to_in_blacklist to check_to_in_blocklist,
> and whitelist_bounce_relays to welcomelist_bounce_relays for bug 7826'
>
> Sending MANIFEST
> Sending lib/Mail/SpamAssassin/Conf.pm
> Sending lib/Mail/SpamAssassin/Plugin/DKIM.pm
> Sending lib/Mail/SpamAssassin/Plugin/FreeMail.pm
> Sending lib/Mail/SpamAssassin/Plugin/SPF.pm
> Sending lib/Mail/SpamAssassin/Plugin/VBounce.pm
> Sending lib/Mail/SpamAssassin/Plugin/WLBLEval.pm
> Sending rules/20_vbounce.cf
> Sending rules/50_scores.cf
> Sending rules/60_whitelist.cf
> Sending rules/60_whitelist_auth.cf
> Adding t/blocklist_autolearn.t
> Sending t/data/01_test_rules.cf
> Adding t/freemail_welcome_block.t
> Adding t/spf_welcome_block.t
> Transmitting file data ...............
> Committed revision 1884922.
>
> --


I am now getting this when I run a lint test with the WLBLEval plugin
*not* loaded (which is one of the pre-commit lint tests I have scripted):

Dec 29 17:40:02.717 [25015] warn: rules: error: unknown eval 'check_from_in_default_whitelist' for USER_IN_DEF_WELCOMELIST
Dec 29 17:40:02.717 [25015] warn: rules: error: unknown eval 'check_from_in_whitelist' for USER_IN_WELCOMELIST
Dec 29 17:40:02.728 [25015] warn: rules: excluding meta test USER_IN_BLACKLIST_TO, unsolved meta dependencies: USER_IN_BLACKLIST_TO
Dec 29 17:40:02.728 [25015] warn: rules: excluding meta test USER_IN_BLACKLIST, unsolved meta dependencies: USER_IN_BLACKLIST
Dec 29 17:40:02.809 [25015] warn: rules: error: unknown eval 'check_from_in_blacklist' for USER_IN_BLOCKLIST
Dec 29 17:40:02.809 [25015] warn: rules: error: unknown eval 'check_from_in_blacklist_to' for USER_IN_BLOCKLIST_TO
Dec 29 17:40:02.810 [25015] warn: rules: error: unknown eval 'check_to_in_whitelist' for USER_IN_WELCOMELIST_TO



...I think those modifications may be missing an ifplugin somewhere - or
perhaps we still have issues with nested if-else-endif in configs?


--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
213 days since the first private commercial manned orbital mission (SpaceX)

I will take a look tomorrow am but how can i re-create your error?

On Tue, Dec 29, 2020, 20:55 John Hardin <jhardin@impsec.org> wrote:

> On Tue, 29 Dec 2020, bugzilla-daemon@spamassassin.apache.org wrote:
>
> > https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826
> >
> > --- Comment #60 from Kevin A. McGrail <kmcgrail@apache.org> ---
> > svn commit -m 'whitelist_auth to welcomelist_auth,
> > unwhitelist_auth to unwelcomelist_auth,
> > def_whitelist_auth to def_welcomelist_auth,
> > check_forged_in_whitelist to check_forged_in_welcomelist,
> > check_from_in_default_whitelist to check_from_in_default_welcomelist,
> > check_uri_host_in_whitelist to check_uri_host_in_welcomelist,
> > check_from_in_blacklist to check_from_in_blocklist,
> > check_to_in_blacklist to check_from_in_blocklist,
> > check_to_in_blacklist to check_to_in_blocklist,
> > and whitelist_bounce_relays to welcomelist_bounce_relays for bug 7826'
> >
> > Sending MANIFEST
> > Sending lib/Mail/SpamAssassin/Conf.pm
> > Sending lib/Mail/SpamAssassin/Plugin/DKIM.pm
> > Sending lib/Mail/SpamAssassin/Plugin/FreeMail.pm
> > Sending lib/Mail/SpamAssassin/Plugin/SPF.pm
> > Sending lib/Mail/SpamAssassin/Plugin/VBounce.pm
> > Sending lib/Mail/SpamAssassin/Plugin/WLBLEval.pm
> > Sending rules/20_vbounce.cf
> > Sending rules/50_scores.cf
> > Sending rules/60_whitelist.cf
> > Sending rules/60_whitelist_auth.cf
> > Adding t/blocklist_autolearn.t
> > Sending t/data/01_test_rules.cf
> > Adding t/freemail_welcome_block.t
> > Adding t/spf_welcome_block.t
> > Transmitting file data ...............
> > Committed revision 1884922.
> >
> > --
>
>
> I am now getting this when I run a lint test with the WLBLEval plugin
> *not* loaded (which is one of the pre-commit lint tests I have scripted):
>
> Dec 29 17:40:02.717 [25015] warn: rules: error: unknown eval
> 'check_from_in_default_whitelist' for USER_IN_DEF_WELCOMELIST
> Dec 29 17:40:02.717 [25015] warn: rules: error: unknown eval
> 'check_from_in_whitelist' for USER_IN_WELCOMELIST
> Dec 29 17:40:02.728 [25015] warn: rules: excluding meta test
> USER_IN_BLACKLIST_TO, unsolved meta dependencies: USER_IN_BLACKLIST_TO
> Dec 29 17:40:02.728 [25015] warn: rules: excluding meta test
> USER_IN_BLACKLIST, unsolved meta dependencies: USER_IN_BLACKLIST
> Dec 29 17:40:02.809 [25015] warn: rules: error: unknown eval
> 'check_from_in_blacklist' for USER_IN_BLOCKLIST
> Dec 29 17:40:02.809 [25015] warn: rules: error: unknown eval
> 'check_from_in_blacklist_to' for USER_IN_BLOCKLIST_TO
> Dec 29 17:40:02.810 [25015] warn: rules: error: unknown eval
> 'check_to_in_whitelist' for USER_IN_WELCOMELIST_TO
>
>
>
> ...I think those modifications may be missing an ifplugin somewhere - or
> perhaps we still have issues with nested if-else-endif in configs?
>
>
> --
> John Hardin KA7OHZ http://www.impsec.org/~jhardin/
> jhardin@impsec.org pgpk -a jhardin@impsec.org
> key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
> -----------------------------------------------------------------------
> 213 days since the first private commercial manned orbital mission
> (SpaceX)
>

On Tue, 29 Dec 2020, Kevin A. McGrail wrote:

> I will take a look tomorrow am but how can i re-create your error?

Basically: set up a custom .pre file that excludes the WLBLEval plugin and
run a regular lint test.



> On Tue, Dec 29, 2020, 20:55 John Hardin <jhardin@impsec.org> wrote:
>
>> On Tue, 29 Dec 2020, bugzilla-daemon@spamassassin.apache.org wrote:
>>
>>> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826
>>>
>>> --- Comment #60 from Kevin A. McGrail <kmcgrail@apache.org> ---
>>> svn commit -m 'whitelist_auth to welcomelist_auth,
>>> unwhitelist_auth to unwelcomelist_auth,
>>> def_whitelist_auth to def_welcomelist_auth,
>>> check_forged_in_whitelist to check_forged_in_welcomelist,
>>> check_from_in_default_whitelist to check_from_in_default_welcomelist,
>>> check_uri_host_in_whitelist to check_uri_host_in_welcomelist,
>>> check_from_in_blacklist to check_from_in_blocklist,
>>> check_to_in_blacklist to check_from_in_blocklist,
>>> check_to_in_blacklist to check_to_in_blocklist,
>>> and whitelist_bounce_relays to welcomelist_bounce_relays for bug 7826'
>>>
>>> Sending MANIFEST
>>> Sending lib/Mail/SpamAssassin/Conf.pm
>>> Sending lib/Mail/SpamAssassin/Plugin/DKIM.pm
>>> Sending lib/Mail/SpamAssassin/Plugin/FreeMail.pm
>>> Sending lib/Mail/SpamAssassin/Plugin/SPF.pm
>>> Sending lib/Mail/SpamAssassin/Plugin/VBounce.pm
>>> Sending lib/Mail/SpamAssassin/Plugin/WLBLEval.pm
>>> Sending rules/20_vbounce.cf
>>> Sending rules/50_scores.cf
>>> Sending rules/60_whitelist.cf
>>> Sending rules/60_whitelist_auth.cf
>>> Adding t/blocklist_autolearn.t
>>> Sending t/data/01_test_rules.cf
>>> Adding t/freemail_welcome_block.t
>>> Adding t/spf_welcome_block.t
>>> Transmitting file data ...............
>>> Committed revision 1884922.
>>>
>>> --
>>
>>
>> I am now getting this when I run a lint test with the WLBLEval plugin
>> *not* loaded (which is one of the pre-commit lint tests I have scripted):
>>
>> Dec 29 17:40:02.717 [25015] warn: rules: error: unknown eval
>> 'check_from_in_default_whitelist' for USER_IN_DEF_WELCOMELIST
>> Dec 29 17:40:02.717 [25015] warn: rules: error: unknown eval
>> 'check_from_in_whitelist' for USER_IN_WELCOMELIST
>> Dec 29 17:40:02.728 [25015] warn: rules: excluding meta test
>> USER_IN_BLACKLIST_TO, unsolved meta dependencies: USER_IN_BLACKLIST_TO
>> Dec 29 17:40:02.728 [25015] warn: rules: excluding meta test
>> USER_IN_BLACKLIST, unsolved meta dependencies: USER_IN_BLACKLIST
>> Dec 29 17:40:02.809 [25015] warn: rules: error: unknown eval
>> 'check_from_in_blacklist' for USER_IN_BLOCKLIST
>> Dec 29 17:40:02.809 [25015] warn: rules: error: unknown eval
>> 'check_from_in_blacklist_to' for USER_IN_BLOCKLIST_TO
>> Dec 29 17:40:02.810 [25015] warn: rules: error: unknown eval
>> 'check_to_in_whitelist' for USER_IN_WELCOMELIST_TO
>>
>>
>>
>> ...I think those modifications may be missing an ifplugin somewhere - or
>> perhaps we still have issues with nested if-else-endif in configs?

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
213 days since the first private commercial manned orbital mission (SpaceX)

On Tue, Dec 29, 2020 at 05:55:02PM -0800, John Hardin wrote:
> On Tue, 29 Dec 2020, bugzilla-daemon@spamassassin.apache.org wrote:
>
> > https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826
> >
> > --- Comment #60 from Kevin A. McGrail <kmcgrail@apache.org> ---
> > svn commit -m 'whitelist_auth to welcomelist_auth,
> > unwhitelist_auth to unwelcomelist_auth,
> > def_whitelist_auth to def_welcomelist_auth,
> > check_forged_in_whitelist to check_forged_in_welcomelist,
> > check_from_in_default_whitelist to check_from_in_default_welcomelist,
> > check_uri_host_in_whitelist to check_uri_host_in_welcomelist,
> > check_from_in_blacklist to check_from_in_blocklist,
> > check_to_in_blacklist to check_from_in_blocklist,
> > check_to_in_blacklist to check_to_in_blocklist,
> > and whitelist_bounce_relays to welcomelist_bounce_relays for bug 7826'
> >
> > Sending MANIFEST
> > Sending lib/Mail/SpamAssassin/Conf.pm
> > Sending lib/Mail/SpamAssassin/Plugin/DKIM.pm
> > Sending lib/Mail/SpamAssassin/Plugin/FreeMail.pm
> > Sending lib/Mail/SpamAssassin/Plugin/SPF.pm
> > Sending lib/Mail/SpamAssassin/Plugin/VBounce.pm
> > Sending lib/Mail/SpamAssassin/Plugin/WLBLEval.pm
> > Sending rules/20_vbounce.cf
> > Sending rules/50_scores.cf
> > Sending rules/60_whitelist.cf
> > Sending rules/60_whitelist_auth.cf
> > Adding t/blocklist_autolearn.t
> > Sending t/data/01_test_rules.cf
> > Adding t/freemail_welcome_block.t
> > Adding t/spf_welcome_block.t
> > Transmitting file data ...............
> > Committed revision 1884922.
> >
> > --
>
>
> I am now getting this when I run a lint test with the WLBLEval plugin
> *not* loaded (which is one of the pre-commit lint tests I have scripted):
>
> Dec 29 17:40:02.717 [25015] warn: rules: error: unknown eval 'check_from_in_default_whitelist' for USER_IN_DEF_WELCOMELIST
> Dec 29 17:40:02.717 [25015] warn: rules: error: unknown eval 'check_from_in_whitelist' for USER_IN_WELCOMELIST
> Dec 29 17:40:02.728 [25015] warn: rules: excluding meta test USER_IN_BLACKLIST_TO, unsolved meta dependencies: USER_IN_BLACKLIST_TO
> Dec 29 17:40:02.728 [25015] warn: rules: excluding meta test USER_IN_BLACKLIST, unsolved meta dependencies: USER_IN_BLACKLIST
> Dec 29 17:40:02.809 [25015] warn: rules: error: unknown eval 'check_from_in_blacklist' for USER_IN_BLOCKLIST
> Dec 29 17:40:02.809 [25015] warn: rules: error: unknown eval 'check_from_in_blacklist_to' for USER_IN_BLOCKLIST_TO
> Dec 29 17:40:02.810 [25015] warn: rules: error: unknown eval 'check_to_in_whitelist' for USER_IN_WELCOMELIST_TO
>
>
>
> ...I think those modifications may be missing an ifplugin somewhere - or
> perhaps we still have issues with nested if-else-endif in configs?
>
some regression tests on 3.4 tree started to fail as well:

[giovanni@ 3.4]$ make test
"/usr/bin/perl" build/mkrules --exit_on_no_src --src rulesrc --out rules --manifest MANIFEST --manifestskip MANIFEST.SKIP
"/usr/bin/perl" build/preprocessor -Mvars -DVERSION="3.004005" -DPREFIX="/usr/local" -DDEF_RULES_DIR="/usr/local/share/spamassassin" -DLOCAL_RULES_DIR="/etc/mail/spamassassin" -DLOCAL_STATE_DIR="/var/lib/spamassassin" -DINSTALLSITELIB="/usr/local/share/perl5/5.32" -DCONTACT_ADDRESS="the administrator of that system" -DRE2C_BIN="re2c" -Msharpbang -Mconditional -DPERL_BIN=""/usr/bin/perl"" -DPERL_WARN="" -DPERL_TAINT="" -m755 -isa-update.raw -osa-update
cp sa-update blib/script/sa-update
"/usr/bin/perl" -MExtUtils::MY -e 'MY->fixin(shift)' -- blib/script/sa-update
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/all_modules.t ................... 1/5 Found anti-pattern: warn = warn: at t/all_modules.t line 92.

# Failed test at t/SATest.pm line 821.
Output can be examined in: log/d.all_modules/0
# Looks like you failed 1 test of 5.
t/all_modules.t ................... Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/5 subtests
t/autolearn.t ..................... Dec 30 09:25:57.450 [5837] warn: rules: error: unknown eval 'check_from_in_blacklist_to' for USER_IN_BLOCKLIST_TO
Dec 30 09:25:57.575 [5837] warn: rules: error: unknown eval 'check_welcomelist_bounce_relays' for __MY_SERVERS_FOUND
t/autolearn.t ..................... ok
t/autolearn_force.t ............... Dec 30 09:25:59.398 [5845] warn: rules: error: unknown eval 'check_from_in_blacklist_to' for USER_IN_BLOCKLIST_TO
Dec 30 09:25:59.525 [5845] warn: rules: error: unknown eval 'check_welcomelist_bounce_relays' for __MY_SERVERS_FOUND
t/autolearn_force.t ............... ok
t/autolearn_force_fail.t .......... ^Cmake: *** [Makefile:1396: test_dynamic] Interrupt

OK, looking at it now!
--
Kevin A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171


On Wed, Dec 30, 2020 at 3:30 AM Giovanni Bechis <giovanni@paclan.it> wrote:

> On Tue, Dec 29, 2020 at 05:55:02PM -0800, John Hardin wrote:
> > On Tue, 29 Dec 2020, bugzilla-daemon@spamassassin.apache.org wrote:
> >
> > > https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826
> > >
> > > --- Comment #60 from Kevin A. McGrail <kmcgrail@apache.org> ---
> > > svn commit -m 'whitelist_auth to welcomelist_auth,
> > > unwhitelist_auth to unwelcomelist_auth,
> > > def_whitelist_auth to def_welcomelist_auth,
> > > check_forged_in_whitelist to check_forged_in_welcomelist,
> > > check_from_in_default_whitelist to check_from_in_default_welcomelist,
> > > check_uri_host_in_whitelist to check_uri_host_in_welcomelist,
> > > check_from_in_blacklist to check_from_in_blocklist,
> > > check_to_in_blacklist to check_from_in_blocklist,
> > > check_to_in_blacklist to check_to_in_blocklist,
> > > and whitelist_bounce_relays to welcomelist_bounce_relays for bug 7826'
> > >
> > > Sending MANIFEST
> > > Sending lib/Mail/SpamAssassin/Conf.pm
> > > Sending lib/Mail/SpamAssassin/Plugin/DKIM.pm
> > > Sending lib/Mail/SpamAssassin/Plugin/FreeMail.pm
> > > Sending lib/Mail/SpamAssassin/Plugin/SPF.pm
> > > Sending lib/Mail/SpamAssassin/Plugin/VBounce.pm
> > > Sending lib/Mail/SpamAssassin/Plugin/WLBLEval.pm
> > > Sending rules/20_vbounce.cf
> > > Sending rules/50_scores.cf
> > > Sending rules/60_whitelist.cf
> > > Sending rules/60_whitelist_auth.cf
> > > Adding t/blocklist_autolearn.t
> > > Sending t/data/01_test_rules.cf
> > > Adding t/freemail_welcome_block.t
> > > Adding t/spf_welcome_block.t
> > > Transmitting file data ...............
> > > Committed revision 1884922.
> > >
> > > --
> >
> >
> > I am now getting this when I run a lint test with the WLBLEval plugin
> > *not* loaded (which is one of the pre-commit lint tests I have scripted):
> >
> > Dec 29 17:40:02.717 [25015] warn: rules: error: unknown eval
> 'check_from_in_default_whitelist' for USER_IN_DEF_WELCOMELIST
> > Dec 29 17:40:02.717 [25015] warn: rules: error: unknown eval
> 'check_from_in_whitelist' for USER_IN_WELCOMELIST
> > Dec 29 17:40:02.728 [25015] warn: rules: excluding meta test
> USER_IN_BLACKLIST_TO, unsolved meta dependencies: USER_IN_BLACKLIST_TO
> > Dec 29 17:40:02.728 [25015] warn: rules: excluding meta test
> USER_IN_BLACKLIST, unsolved meta dependencies: USER_IN_BLACKLIST
> > Dec 29 17:40:02.809 [25015] warn: rules: error: unknown eval
> 'check_from_in_blacklist' for USER_IN_BLOCKLIST
> > Dec 29 17:40:02.809 [25015] warn: rules: error: unknown eval
> 'check_from_in_blacklist_to' for USER_IN_BLOCKLIST_TO
> > Dec 29 17:40:02.810 [25015] warn: rules: error: unknown eval
> 'check_to_in_whitelist' for USER_IN_WELCOMELIST_TO
> >
> >
> >
> > ...I think those modifications may be missing an ifplugin somewhere - or
> > perhaps we still have issues with nested if-else-endif in configs?
> >
> some regression tests on 3.4 tree started to fail as well:
>
> [giovanni@ 3.4]$ make test
> "/usr/bin/perl" build/mkrules --exit_on_no_src --src rulesrc --out rules
> --manifest MANIFEST --manifestskip MANIFEST.SKIP
> "/usr/bin/perl" build/preprocessor -Mvars -DVERSION="3.004005"
> -DPREFIX="/usr/local" -DDEF_RULES_DIR="/usr/local/share/spamassassin"
> -DLOCAL_RULES_DIR="/etc/mail/spamassassin"
> -DLOCAL_STATE_DIR="/var/lib/spamassassin"
> -DINSTALLSITELIB="/usr/local/share/perl5/5.32" -DCONTACT_ADDRESS="the
> administrator of that system" -DRE2C_BIN="re2c" -Msharpbang -Mconditional
> -DPERL_BIN=""/usr/bin/perl"" -DPERL_WARN="" -DPERL_TAINT="" -m755
> -isa-update.raw -osa-update
> cp sa-update blib/script/sa-update
> "/usr/bin/perl" -MExtUtils::MY -e 'MY->fixin(shift)' --
> blib/script/sa-update
> PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM"
> "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0,
> 'blib/lib', 'blib/arch')" t/*.t
> t/all_modules.t ................... 1/5 Found anti-pattern: warn
> = warn: at t/all_modules.t line 92.
>
> # Failed test at t/SATest.pm line 821.
> Output can be examined in: log/d.all_modules/0
> # Looks like you failed 1 test of 5.
> t/all_modules.t ................... Dubious, test returned 1 (wstat 256,
> 0x100)
> Failed 1/5 subtests
> t/autolearn.t ..................... Dec 30 09:25:57.450 [5837] warn:
> rules: error: unknown eval 'check_from_in_blacklist_to' for
> USER_IN_BLOCKLIST_TO
> Dec 30 09:25:57.575 [5837] warn: rules: error: unknown eval
> 'check_welcomelist_bounce_relays' for __MY_SERVERS_FOUND
> t/autolearn.t ..................... ok
> t/autolearn_force.t ............... Dec 30 09:25:59.398 [5845] warn:
> rules: error: unknown eval 'check_from_in_blacklist_to' for
> USER_IN_BLOCKLIST_TO
> Dec 30 09:25:59.525 [5845] warn: rules: error: unknown eval
> 'check_welcomelist_bounce_relays' for __MY_SERVERS_FOUND
> t/autolearn_force.t ............... ok
> t/autolearn_force_fail.t .......... ^Cmake: *** [Makefile:1396:
> test_dynamic] Interrupt
>

On Wed, 30 Dec 2020, bugzilla-daemon@spamassassin.apache.org wrote:

> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826
>
> --- Comment #61 from Kevin A. McGrail <kmcgrail@apache.org> ---
> svn commit -m 'Found missing rule eval registration in VBounce.pm for
> check_whitelist_bounce_relays and changed 60_whitelist.cf hierarchy to handle
> ifplugin/if/else/endif problems'
> Sending lib/Mail/SpamAssassin/Plugin/VBounce.pm
> Sending rules/60_whitelist.cf
> Transmitting file data ..done
> Committing transaction...
> Committed revision 1884961.

My scripted lint tests now pass again. Thanks, Kevin.

I did not run a full test, so I don't know about the regression tests
Giovanni reported.


--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
214 days since the first private commercial manned orbital mission (SpaceX)

Thanks for the trouble report John and Giovanni.

Found missing rule eval registration in VBounce.pm for
check_whitelist_bounce_relays

And yes, the WLBLEval.pm plugin being disabled raises the issues due to our
logic for ifplugin/if/else/endif that isn't perfect. I have added more
nested plugin checks so that this collision is avoided.

This fixes these issues:
Dec 30 16:42:42.035 [2012449] warn: rules: error: unknown eval
'check_from_in_whitelist' for USER_IN_WELCOMELIST
Dec 30 16:42:42.097 [2012449] warn: rules: error: unknown eval
'check_to_in_whitelist' for USER_IN_WELCOMELIST_TO

SpamAssassin 4.0 now passes lint cleanly with and without WLBLEval Plugin
enabled.

SA 3.4.5 also passes lint cleanly with the new, yet to be published
60_whitelist.cf

However autolearn.t had two warnings:

Dec 30 18:11:09.626 [2018884] warn: rules: error: unknown eval
'check_from_in_blacklist_to' for USER_IN_BLOCKLIST_TO
Dec 30 18:11:09.844 [2018884] warn: rules: error: unknown eval
'check_welcomelist_bounce_relays' for __MY_SERVERS_FOUND

One was a misspelling of check_from_in_blacklist_to instead of
check_to_in_blacklist which passed tests for 4.0.

The second was 20_vbounce.cf missing logic for 3.4 vs 4.0 which was
surprisingly uncomplicated because it's an eval function change only.

This fixed the regression tests for 3.4 with all modules.t as well

The basic_lint was a meta rule misspelling in two places that had block vs
black wrong which passed for the 4.0 path but not 3.4.

In short, I believe we have resolved everything from the most recent
omnibus patch. Will add a make test for both 4.0 and 3.4 branch as well as
lints looking for warnings in the future because those steps unearthed some
extra issues hidden when only make test for 4.0 was run to test the patch.

Regards,
KAM
--
Kevin A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171


On Wed, Dec 30, 2020 at 6:56 PM John Hardin <jhardin@impsec.org> wrote:

> On Wed, 30 Dec 2020, bugzilla-daemon@spamassassin.apache.org wrote:
>
> > https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826
> >
> > --- Comment #61 from Kevin A. McGrail <kmcgrail@apache.org> ---
> > svn commit -m 'Found missing rule eval registration in VBounce.pm for
> > check_whitelist_bounce_relays and changed 60_whitelist.cf hierarchy to
> handle
> > ifplugin/if/else/endif problems'
> > Sending lib/Mail/SpamAssassin/Plugin/VBounce.pm
> > Sending rules/60_whitelist.cf
> > Transmitting file data ..done
> > Committing transaction...
> > Committed revision 1884961.
>
> My scripted lint tests now pass again. Thanks, Kevin.
>
> I did not run a full test, so I don't know about the regression tests
> Giovanni reported.
>
>
> --
> John Hardin KA7OHZ http://www.impsec.org/~jhardin/
> jhardin@impsec.org pgpk -a jhardin@impsec.org
> key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
> -----------------------------------------------------------------------
> 214 days since the first private commercial manned orbital mission
> (SpaceX)
>

On 4/16/22 19:23, bugzilla-daemon@spamassassin.apache.org wrote:
> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826
>
> --- Comment #72 from Henrik Krohns <apache@hege.li> ---
> (In reply to Henrik Krohns from comment #69)
>>
>> Dunno if we can call things for vote again, but I'd suggest either of these:
>>
>> - Completely roll back all the changes and forget this whole debacle
>> - Massive rush to rename all the stuff, do it this time in a branch and test
>> properly before committing to trunk. I will pledge to waste^H^H^H^H^Hdonate
>> one day of my life to do this.
>
> I'll also add this for voting table:
>
> - Roll back all the changes from trunk, and work on them in the just created
> trunk-whitelist branch. This would mean actually getting 4.0 out now and not
> spending eternity here debating. Racial stuff can be in 4.1 or any other
> imaginary version, if we ever have resources to do it properly, that's up to
> anyone that wants to actually work on it..
>
> This is my preferred way, would vote +1
>

you have my +1

Axb

On Sun, 17 Apr 2022, Axb wrote:

> On 4/16/22 19:23, bugzilla-daemon@spamassassin.apache.org wrote:
>> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826
>>
>> --- Comment #72 from Henrik Krohns <apache@hege.li> ---
>> (In reply to Henrik Krohns from comment #69)
...
>> - Roll back all the changes from trunk, and work on them in the just
>> created trunk-whitelist branch. This would mean actually getting 4.0
>> out now and not spending eternity here debating. Racial stuff can be
>> in 4.1 or any other imaginary version, if we ever have resources to
>> do it properly, that's up to anyone that wants to actually work on
>> it..
>>
>> This is my preferred way, would vote +1
>
> you have my +1
>
> Axb

My +1 as well.

My initial acceptance vote for these changes was predicated on them being
low-impact. That hasn't turned out to be the case.

This work should be happening on a branch.


--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Our politicians 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.
-----------------------------------------------------------------------
2 days until the 247th anniversary of The Shot Heard 'Round The World