You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@issues.apache.org on 2011/03/20 16:56:53 UTC
[Bug 6558] New: __PILL_PRICE rules (having "tflags multiple") cause
infinite loop only when compiled on ia32
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
Summary: __PILL_PRICE rules (having "tflags multiple") cause
infinite loop only when compiled on ia32
Product: Spamassassin
Version: 3.3.1
Platform: PC
OS/Version: Linux
Status: NEW
Severity: major
Priority: P2
Component: sa-compile
AssignedTo: dev@spamassassin.apache.org
ReportedBy: jhardin@impsec.org
__PILL_PRICE subrules with "tflags multiple" cause infinite loop on matching
message text when compiled on ia32. Removing the "tflags multiple" corrects the
problem. No issues when not compiled.
http://mail-archives.apache.org/mod_mbox/spamassassin-users/201103.mbox/ajax/%3C4D85D121.5020704@fastmail.net%3E
I'm disabling those rules until what I assume is is a bug in sa-compile or re2c
is fixed.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6558] [review] __PILL_PRICE rules (having "tflags multiple")
cause infinite loop when compiled
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
--- Comment #14 from Mark Martinec <Ma...@ijs.si> 2011-03-23 09:03:25 EDT ---
> Seems to be a perl bug, affecting 5.8, 5.10, 5.12, but not 5.13.10.
> I have reported the perl bug as [perl #86784]:
> http://rt.perl.org/rt3/Ticket/Display.html?id=86784
I didn't realize this perl bug was reported before - so the #86784
is a duplicate of:
* #8262: //g loops infinitely on tainted data
* #27344: pos() does not get updated when running in taint mode
* #5475: Bug in taint+regex+hash/arrays
The #8262 brings the fix:
Now fixed by commit fd69380d5d5b95ef16e2521cf4251b34ee0ce151
in branch davem/post-5.12, which should be merged back into blead
once 5.12 has been released, and thus appear in 5.13 onwards.
So yes, perl 5.13 is no longer affected.
According to explanations there, using an array element or a hash
element with magic as an operand of /.../g triggers the issue
(the pos gets assigned to a temporary copy and is then lost).
Both proposed solutions by Matt avoid the bug. The magic may be
a taint, but can be other, like substr magic. In this regard we
now know that we have avoided the bug with the proposed patch
or a similar change.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6558] [review] body rules having "tflags multiple" may cause
infinite loop when compiled
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
Mark Martinec <Ma...@ijs.si> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #24 from Mark Martinec <Ma...@ijs.si> 2011-05-05 23:46:52 UTC ---
branch 3.3:
Bug 6558: body rules having "tflags multiple" may cause infinite loop
when compiled - a workaround
Sending lib/Mail/SpamAssassin/Conf.pm
Sending lib/Mail/SpamAssassin/Plugin/BodyRuleBaseExtractor.pm
Sending lib/Mail/SpamAssassin/Plugin/OneLineBodyRuleType.pm
Committed revision 1100002.
Note this provides a workaround for the perl bug, a feature_bug6558_free
function, a small debugging improvement - but does not issue a warning
about possible problems with older versions, as this does not belong
to a 3.3.2 package.
Closing.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6558] __PILL_PRICE rules (having "tflags multiple") cause
infinite loop when compiled
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
--- Comment #12 from Mark Martinec <Ma...@ijs.si> 2011-03-22 16:13:00 EDT ---
Matt Elson wrote on the mailing list a valuable description of the
program flow - valuable for posteriority, so I'm including it here:
Hey all,
I've been doing some investigation of Bug 6558 (__PILL_PRICE_[1-3] +
Compiled Rulesets == endless loop_ on my end and want to share the
results - I'm not super familiar with SpamAssassin's code base, so
apologies if I misread anything or am totally off.
Long story short since this email has gotten a little bit lengthy, I
think the problem lies in a function being created around line 97 in
OneLineBodyRuleType that Rule2XSBody later uses in some cases.
Lengthy analysis below:
At this point, I have a test machine (x64) where I have removed *all
rules* except the rules I'm testing and disabled every plugin except
Rule2XSBody.pm and Check.pm.
First, I've played around with the regexes and found that something as
simple as:
body LOCAL_TEST pill
tflags LOCAL_TEST multiple
will cause the problem (when run on the short artificial email attached
to the bugzilla).
Interestingly enough, if I make this case insensitive
body LOCAL_TEST /pill/i
tflags LOCAL_TEST multiple
The problem goes away.
So at that point I started poking around the code for Rule2XSBody
because I was curious... and this is where I'm probably a bit out of my
depth. But, it looks like the reason the case insensitive rule does
not hit the problem is because the results of the CompiledRegexps scan
is flagged as "non lossy" (l=0) and gets hits by the if statement around
line 243 in Rule2XSBody.pm. Case sensitive rules are flagged as lossy
(l=1) by the CompiledRegexps and have to move on. They get up to the
stanza at line 261 - if (!&{$fn} ($scanner, $line) && $do_dbg).. and
this is where things are getting stuck for me. This is where it got
interesting - when I added in my debugging and ran through the original
__PILL_PRICE_[1-3] rules that created it - they're all flagged as lossy.
$fn seems to be a dynamically created function that Rule2XSBody (by way
of OneLineBodyRuleType.pm) creates - unfortunately I can't quite
decipher the code - line 142 in OneLineBodyRuleType.pm is where it's
made. While I can't make out what the function's supposed to do, it is
worth noting that when the rule it's being created for has a tflag of
"multiple", the function has a while condition: i.e.
while ($_[1] =~ '.$pat.'g) {
Whereas if the tflag is NOT multiple, it's just an if condition
if ($_[1] =~ '.$pat.') {
I'm not quite sure what's supposed to break out of the while loop, but
I'm fairly sure it's not getting correctly broken and is where
everything's getting stuck. I changed the "while" to an if just to test
this theory and once I do this.. the problem goes away for me,
completely on all regexes, both my simple pill and the more elaborate
original ones (and rewrites). I'd imagine not a real solution, but good
for testing. (simple patch attached in case I was unclear about the
change).
This doesn't quite explain why the problem doesn't emerge for everyone
using compiled rules (though maybe the difference is whether or not the
CompiledRegexpsModule is flagging the rules as lossy; that might differ
from architecture to architecture and environment to environment and
when the rules are NOT lossy, they don't get to the bit of code that
seems to be causing the problem).
For further information, here's what the dynamic function function looks
like when I spit it out with some debugging.
sub JUST_PILLS_one_line_body_test { {
pos $_[1] = 0;
#line 1 "/var/lib/spamassassin/3.003001/local.cf, rule JUST_PILLS,"
while ($_[1] =~ /pill/g) {
my $self = $_[0];
$self->got_hit(q{JUST_PILLS}, "BODY: ", ruletype =>
"one_line_body");
dbg("rules: ran one_line_body rule JUST_PILLS ======> got hit:
\"" . ($&|| "negative match") . "\"");
}
} }
(notice that that's the debug statement that you see repeated over and
over; the comments before ${fn} is called suggest that this is running
the real regex).
Like I said, I'm having trouble making sense of it ($_ was never a
friend of mine) and for the life of me I don't know how the loop is
supposed to end.
Another little hack I did that seems to fix it (though goodness knows at
what cost) is to add an s at front
(i.e. making it while $_[1] =~ s/pill/g).
Again, not suggesting that as a real solution since modifying variables
arbitrarily seems.. unwise, but maybe it will help troubleshoot/debug
further.
Anyway, hope this helps out!
Matt
[...] would something like this
help with any performance degradation caused by my initial patch:
my $line = \$_[1];
while ($$line =~ '.$pat.'g) {
Or does it amount to more or less the same thing as my original patch?
I'm not completely clear in how perl handles references and didn't
really do anything more than a cursory test on it (which worked).
Matt
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6558] __PILL_PRICE rules (having "tflags multiple") cause
infinite loop when compiled
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
melson+sa@fastmail.net changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |melson+sa@fastmail.net
--- Comment #11 from melson+sa@fastmail.net 2011-03-22 09:50:01 EDT ---
Oop sorry for that - meant to leave an actual useful comment (not too familiar
with bugzilla).
Don't want to clutter the bugzilla up with too much noise, but that patch seems
to fix the loop issue for me in my environment, though I'm sure there are still
outstanding questions. I sent a full(er) analysis of the issue to the dev list
as well.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Re: [Bug 6558] [review] __PILL_PRICE rules (having "tflags multiple")
cause infinite loop when compiled
Posted by John Hardin <jh...@impsec.org>.
On Thu, 24 Mar 2011, Karsten Br�ckelmann wrote:
> On Thu, 2011-03-24 at 01:48 +0100, Mark Martinec wrote:
>>> It'd be nice if I could see these warnings in the make+make test+masscheck
>>> I (try to) do before commits...
>>
>> I agree.
>>
>> Currently what is necessary is to ditch a sa-compile.cache
>> directory, e.g.
>>
>> rm -rf /root/.spamassassin/sa-compile.cache
>>
>> before a sa-compile, otherwise results are fetched from
>> previous runs and rules with their regexps are not
>> re-assessed - no warnings would be issued for rules
>> cached from previous runs.
>
> Maybe it's just me being terribly confused, but... Something that
> changed, never should be fetched from a cache.
>
> If this is referring to a cache pre-change, that would be easy to
> overcome.
Apply this patch and not change any rules, and the lint won't be run. The
cache will be used until a rule changes.
--
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
-----------------------------------------------------------------------
Gun Control laws aren't enacted to control guns, they are enacted
to control people: catholics (1500s), japanese peasants (1600s),
blacks (1860s), italian immigrants (1911), the irish (1920s),
jews (1930s), blacks (1960s), the poor (always)
-----------------------------------------------------------------------
6 days until the M1911 is 100 years old - and still going strong!
Re: [Bug 6558] [review] __PILL_PRICE rules (having "tflags
multiple") cause infinite loop when compiled
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Thu, 2011-03-24 at 01:48 +0100, Mark Martinec wrote:
> > It'd be nice if I could see these warnings in the make+make test+masscheck
> > I (try to) do before commits...
>
> I agree.
>
> Currently what is necessary is to ditch a sa-compile.cache
> directory, e.g.
>
> rm -rf /root/.spamassassin/sa-compile.cache
>
> before a sa-compile, otherwise results are fetched from
> previous runs and rules with their regexps are not
> re-assessed - no warnings would be issued for rules
> cached from previous runs.
Maybe it's just me being terribly confused, but... Something that
changed, never should be fetched from a cache.
If this is referring to a cache pre-change, that would be easy to
overcome.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: [Bug 6558] [review] __PILL_PRICE rules (having "tflags multiple") cause infinite loop when compiled
Posted by Mark Martinec <Ma...@ijs.si>.
> > https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
> > Attached is a patch to BodyRuleBaseExtractor.pm which will
> > make sa-compile report a warning when hitting a rule with
> > tflag=multiple and a lossy match. Appropriate for Jenkins runs.
John Hardin wrote:
> Would this be run automatically as part of a make or make test? Or would
> a separate explicit sa-compile step be needed to run this lint check?
Don't know, sorry. I just added a minimalistic test to where it
would fit with least disruption. Remains to be investigated,
most likely Jenkins setup would need to be adjusted.
> It'd be nice if I could see these warnings in the make+make test+masscheck
> I (try to) do before commits...
I agree.
Currently what is necessary is to ditch a sa-compile.cache
directory, e.g.
rm -rf /root/.spamassassin/sa-compile.cache
before a sa-compile, otherwise results are fetched from
previous runs and rules with their regexps are not
re-assessed - no warnings would be issued for rules
cached from previous runs.
Mark
Re: [Bug 6558] [review] __PILL_PRICE rules (having "tflags multiple")
cause infinite loop when compiled
Posted by John Hardin <jh...@impsec.org>.
On Wed, 23 Mar 2011, bugzilla-daemon@issues.apache.org wrote:
> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
>
> Attached is a patch to BodyRuleBaseExtractor.pm which will
> make sa-compile report a warning when hitting a rule with
> tflag=multiple and a lossy match. Appropriate for Jenkins runs.
Would this be run automatically as part of a make or make test? Or would
a separate explicit sa-compile step be needed to run this lint check?
It'd be nice if I could see these warnings in the make+make test+masscheck
I (try to) do before commits...
--
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
-----------------------------------------------------------------------
False is the idea of utility that sacrifices a thousand real
advantages for one imaginary or trifling inconvenience; that would
take fire from men because it burns, and water because one may drown
in it; that has no remedy for evils except destruction. The laws
that forbid the carrying of arms are laws of such a nature. They
disarm only those who are neither inclined nor determined to commit
crime. -- Cesare Beccaria, quoted by Thomas Jefferson
-----------------------------------------------------------------------
6 days until the M1911 is 100 years old - and still going strong!
[Bug 6558] [review] __PILL_PRICE rules (having "tflags multiple")
cause infinite loop when compiled
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
--- Comment #15 from Mark Martinec <Ma...@ijs.si> 2011-03-23 16:33:38 EDT ---
Created an attachment (id=4859)
--> (https://issues.apache.org/SpamAssassin/attachment.cgi?id=4859)
let sa-update issue a warning when stumbling across a rule which could hit bug
6558
Guenther wrote on the ML:
> Can we come up with some (brief) instructions, and a test rule that
> should trigger the bug? So we can have those previously effected verify
> it, and more importantly, verify the (tiny) patch to fix the issue for
> them? A test case to be sure, whether or not future rule updates even
> would include what's just broken the compile?
> Also, while this Perl bug is out there (which undoubtful will exists for
> a long time on production machines), should we refrain from tflags
> multiple body rules?
I guess so.
> Though yeah, agreed, a lint check at least for Jenkins to catch
> inappropriate tflags multiple for body rules and version <3.3.2 sounds
> like a good precaution. Might back-fire, though, due to generated
> scores. In the worst case, this is scorched earth until 3.4. :(
Attached is a patch to BodyRuleBaseExtractor.pm which will
make sa-compile report a warning when hitting a rule with
tflag=multiple and a lossy match. Appropriate for Jenkins runs.
E.g. (hand wrapped and cleansed):
# sa-compile
Mar 23 21:19:07.288 [9363] info: generic: base extraction starting....
Mar 23 21:19:07.288 [9363] info: generic: extracting from rules of ...
zoom: rule __PILL_PRICE_3 will loop on SpamAssassin older that 3.3.2
running under Perl 5.12 or older, Bug 6558
zoom: rule __PILL_PRICE_1 will loop on SpamAssassin older that 3.3.2
running under Perl 5.12 or older, Bug 6558
zoom: rule __PILL_PRICE_2 will loop on SpamAssassin older that 3.3.2
running under Perl 5.12 or older, Bug 6558
trunk:
Bug 6558: let sa-update issue a warning when stumbling across a rule
which could hit this bug
Sending lib/Mail/SpamAssassin/Plugin/BodyRuleBaseExtractor.pm
Committed revision 1084721.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Re: Emergency Rule Updates
Posted by John Hardin <jh...@impsec.org>.
On Mon, 21 Mar 2011, Daryl C. W. O'Shea wrote:
> On 21/03/2011 10:37 PM, John Hardin wrote:
>> On Mon, 21 Mar 2011, Daryl C. W. O'Shea wrote:
>>
>> > On 20/03/2011 5:00 PM, Karsten Bräckelmann wrote:
>> > > > https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
>> > > Not sure though, if I even can perform all steps necessary. :/
>> > >
>> > > Anyone up for this? Guess this highlights the point we *do* need a way
>> > > to push some sort of emergency rule updates, as mentioned by Daryl in
>> > > that post...
>> >
>> > Does a manually update need to be pushed?
>>
>> I think if you can push the one that's in the pipe already (1083702)
>> we'll be okay.
>
> I don't have a commit email for that revision, so I guess you're referring to
> something else.
By "in the pipe" I meant that's the commit which the latest completed
masscheck is based upon.
>> > If somebody provides me a patch(es) against whatever current updates
>> > need to be patched, I'll patch them and push the update(s).
>>
>> Remove anything containing PILL_PRICE.
>
> I don't really have time to test stuff... if you can provide a patch that's
> tested against 3.1, I'll try to get it pushed.
Not quickly, sorry. Anybody else?
--
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 someone has a gun and is trying to kill you, it would be
reasonable to shoot back with your own gun.
-- the Dalai Lama, May 15, 2001
-----------------------------------------------------------------------
8 days until the M1911 is 100 years old - and still going strong!
Re: Emergency Rule Updates
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
On 21/03/2011 10:37 PM, John Hardin wrote:
> On Mon, 21 Mar 2011, Daryl C. W. O'Shea wrote:
>
>> On 20/03/2011 5:00 PM, Karsten Bräckelmann wrote:
>>> > https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
>>> Not sure though, if I even can perform all steps necessary. :/
>>>
>>> Anyone up for this? Guess this highlights the point we *do* need a way
>>> to push some sort of emergency rule updates, as mentioned by Daryl in
>>> that post...
>>
>> Does a manually update need to be pushed?
>
> I think if you can push the one that's in the pipe already (1083702)
> we'll be okay.
I don't have a commit email for that revision, so I guess you're
referring to something else.
>> If somebody provides me a patch(es) against whatever current updates
>> need to be patched, I'll patch them and push the update(s).
>
> Remove anything containing PILL_PRICE.
I don't really have time to test stuff... if you can provide a patch
that's tested against 3.1, I'll try to get it pushed.
Daryl
Re: Emergency Rule Updates
Posted by John Hardin <jh...@impsec.org>.
On Mon, 21 Mar 2011, Daryl C. W. O'Shea wrote:
> On 20/03/2011 5:00 PM, Karsten Bräckelmann wrote:
>> > https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
>> Not sure though, if I even can perform all steps necessary. :/
>>
>> Anyone up for this? Guess this highlights the point we *do* need a way
>> to push some sort of emergency rule updates, as mentioned by Daryl in
>> that post...
>
> Does a manually update need to be pushed?
I think if you can push the one that's in the pipe already (1083702) we'll
be okay.
> If somebody provides me a patch(es) against whatever current updates need to
> be patched, I'll patch them and push the update(s).
Remove anything containing PILL_PRICE.
--
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 someone has a gun and is trying to kill you, it would be
reasonable to shoot back with your own gun.
-- the Dalai Lama, May 15, 2001
-----------------------------------------------------------------------
8 days until the M1911 is 100 years old - and still going strong!
Re: Emergency Rule Updates
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Mon, 2011-03-21 at 22:04 -0400, Daryl C. W. O'Shea wrote:
> On 20/03/2011 5:00 PM, Karsten Bräckelmann wrote:
> > > https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
> > Not sure though, if I even can perform all steps necessary. :/
> >
> > Anyone up for this? Guess this highlights the point we *do* need a way
> > to push some sort of emergency rule updates, as mentioned by Daryl in
> > that post...
>
> Does a manually update need to be pushed?
>
> If somebody provides me a patch(es) against whatever current updates
> need to be patched, I'll patch them and push the update(s).
See the bug above, comment 3. Just get the hell rid of... I mean, meta
out the __PILL_PRICE_x rules, which are currently causing endless loops
when compiled. In some obscure circumstances.
Not removing these rules, but make them always return 0, will not break
dependencies of other rules.
Still digging deeper with a tremendous amount of help by Matt Elson, the
original reporter. And trying him to post his excellent analysis
here. :)
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Emergency Rule Updates
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
On 20/03/2011 5:00 PM, Karsten Bräckelmann wrote:
>> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
> Not sure though, if I even can perform all steps necessary. :/
>
> Anyone up for this? Guess this highlights the point we *do* need a way
> to push some sort of emergency rule updates, as mentioned by Daryl in
> that post...
Does a manually update need to be pushed?
If somebody provides me a patch(es) against whatever current updates
need to be patched, I'll patch them and push the update(s).
Daryl
Re: Emergency Rule Updates (was: Bug 6558)
Posted by John Hardin <jh...@impsec.org>.
On Sun, 20 Mar 2011, Karsten Br�ckelmann wrote:
>> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
>>
>> Karsten Bräckelmann <gu...@rudersport.de> changed:
>
>> I guess this warrants a manually triggered rules update release, with the
>> affected rules' tflags removed. Just minor surgery to the current tarball.
>>
>> How again can we do this? Time to dig through my archive...
>
> Found the bare-bones instructions posted to this list by Daryl on Jan
> 27, thread "Update Mirror Issues" [1].
>
> Not sure though, if I even can perform all steps necessary. :/
>
> Anyone up for this? Guess this highlights the point we *do* need a way
> to push some sort of emergency rule updates, as mentioned by Daryl in
> that post...
>
>
> [1] http://markmail.org/message/bd3qyedr5y3u2oxw
Did you see this?
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6365
--
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
-----------------------------------------------------------------------
A well educated Electorate, being necessary to the liberty of a
free State, the Right of the People to Keep and Read Books,
shall not be infringed.
-----------------------------------------------------------------------
9 days until the M1911 is 100 years old - and still going strong!
Re: Emergency Rule Updates
Posted by "Warren Togami Jr." <wt...@gmail.com>.
On 3/21/2011 1:10 PM, Karsten Bräckelmann wrote:
> On Sun, 2011-03-20 at 22:53 -1000, Warren Togami Jr. wrote:
>> If an emergency rule update does go out, please be sure Bug #6533 is
>> part of that push.
>
> See, that's why I told you back those days what RESOLVED FIXED in
> bugzilla means. It means fixed in SVN, and does not require a new update
> or release.
>
> See comment 2 and 3, where Doc already fixed this bug. You then
> re-opened it, waiting for a rules update release.
>
> Warren, you do realize, the current issue with re2c and compiling rules
> in some obscure cases got noticed by the users BECAUSE a new rules
> update finally has been generated automatically, do you? There is no
> need for manual intervention regarding bug 6533, it already is out. (And
> yes, I just grepped the latest rules tarball.)
>
> Closing that bug. Again.
>
>
6533 went out as an automatic push? I thought automatic was broken for
a long time due to the lack of sufficient corpora.
Warren
Re: Emergency Rule Updates
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Sun, 2011-03-20 at 22:53 -1000, Warren Togami Jr. wrote:
> If an emergency rule update does go out, please be sure Bug #6533 is
> part of that push.
See, that's why I told you back those days what RESOLVED FIXED in
bugzilla means. It means fixed in SVN, and does not require a new update
or release.
See comment 2 and 3, where Doc already fixed this bug. You then
re-opened it, waiting for a rules update release.
Warren, you do realize, the current issue with re2c and compiling rules
in some obscure cases got noticed by the users BECAUSE a new rules
update finally has been generated automatically, do you? There is no
need for manual intervention regarding bug 6533, it already is out. (And
yes, I just grepped the latest rules tarball.)
Closing that bug. Again.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Emergency Rule Updates
Posted by "Warren Togami Jr." <wt...@gmail.com>.
On 3/20/2011 11:00 AM, Karsten Bräckelmann wrote:
>> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
>>
>> Karsten Bräckelmann<gu...@rudersport.de> changed:
>
>> I guess this warrants a manually triggered rules update release, with the
>> affected rules' tflags removed. Just minor surgery to the current tarball.
>>
>> How again can we do this? Time to dig through my archive...
>
> Found the bare-bones instructions posted to this list by Daryl on Jan
> 27, thread "Update Mirror Issues" [1].
>
> Not sure though, if I even can perform all steps necessary. :/
>
> Anyone up for this? Guess this highlights the point we *do* need a way
> to push some sort of emergency rule updates, as mentioned by Daryl in
> that post...
>
>
> [1] http://markmail.org/message/bd3qyedr5y3u2oxw
>
If an emergency rule update does go out, please be sure Bug #6533 is
part of that push.
Warren
Emergency Rule Updates (was: Bug 6558)
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
>
> Karsten Bräckelmann <gu...@rudersport.de> changed:
> I guess this warrants a manually triggered rules update release, with the
> affected rules' tflags removed. Just minor surgery to the current tarball.
>
> How again can we do this? Time to dig through my archive...
Found the bare-bones instructions posted to this list by Daryl on Jan
27, thread "Update Mirror Issues" [1].
Not sure though, if I even can perform all steps necessary. :/
Anyone up for this? Guess this highlights the point we *do* need a way
to push some sort of emergency rule updates, as mentioned by Daryl in
that post...
[1] http://markmail.org/message/bd3qyedr5y3u2oxw
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
[Bug 6558] __PILL_PRICE rules (having "tflags multiple") cause
infinite loop only when compiled on ia32
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
Karsten Bräckelmann <gu...@rudersport.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P2 |P1
--- Comment #2 from Karsten Bräckelmann <gu...@rudersport.de> 2011-03-20 16:33:43 EDT ---
Raising Priority.
I guess this warrants a manually triggered rules update release, with the
affected rules' tflags removed. Just minor surgery to the current tarball.
How again can we do this? Time to dig through my archive...
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6558] [review] body rules having "tflags multiple" may cause
infinite loop when compiled
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
--- Comment #22 from John Hardin <jh...@impsec.org> 2011-05-05 20:04:21 UTC ---
One caveat: sa-compile appears to stop issuing the warning when perl hits a
version that no longer has the bug, so if your test platform is 5.12.3 (on
Gentoo, at least) or higher you won't get warned about rules that may be
problematic on older production installs.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6558] [review] body rules having "tflags multiple" may cause
infinite loop when compiled
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
--- Comment #20 from John Hardin <jh...@impsec.org> 2011-03-27 12:43:33 EDT ---
(In reply to comment #19)
> (In reply to comment #15)
> > Created an attachment (id=4859)
--> (https://issues.apache.org/SpamAssassin/attachment.cgi?id=4859) [details]
[details]
> >
> > Attached is a patch to BodyRuleBaseExtractor.pm which will
> > make sa-compile report a warning when hitting a rule with
> > tflag=multiple and a lossy match.
>
> I restored the original problematic PILL_PRICE rules in my sandbox and ran
> this, and they did _not_ generate warnings. Some other unpromoted rules
> currently in my sandbox do generate warnings.
...that must have been a fluke. I ran sa-compile again and _1 and _2 are
flagged, but _3 is not.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6558] __PILL_PRICE rules (having "tflags multiple") cause
infinite loop when compiled
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
--- Comment #9 from Florian Hinzmann <ma...@fhinzmann.de> 2011-03-22 04:29:45 EDT ---
Created an attachment (id=4854)
--> (https://issues.apache.org/SpamAssassin/attachment.cgi?id=4854)
Debug log entering the endless loop, spamassassin -D
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6558] __PILL_PRICE rules (having "tflags multiple") cause
infinite loop when compiled
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
--- Comment #10 from melson+sa@fastmail.net 2011-03-22 09:45:59 EDT ---
Created an attachment (id=4855)
--> (https://issues.apache.org/SpamAssassin/attachment.cgi?id=4855)
Patch that fixes loop issue.
Meant more to aid in debugging than an actual fix.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6558] [review] body rules having "tflags multiple" may cause
infinite loop when compiled
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
--- Comment #23 from Mark Martinec <Ma...@ijs.si> 2011-05-05 23:41:58 UTC ---
Created attachment 4875
--> https://issues.apache.org/SpamAssassin/attachment.cgi?id=4875
A combo patch of what will go into the 3.3.2
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6558] __PILL_PRICE rules (having "tflags multiple") cause
infinite loop when compiled
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
John Hardin <jh...@impsec.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|__PILL_PRICE rules (having |__PILL_PRICE rules (having
|"tflags multiple") cause |"tflags multiple") cause
|infinite loop |infinite loop when compiled
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6558] [review] body rules having "tflags multiple" may cause
infinite loop when compiled
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
Arnaud Launay <as...@launay.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |asl-bugzilla-sa@launay.org
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6558] [review] __PILL_PRICE rules (having "tflags multiple")
cause infinite loop when compiled
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
Mark Martinec <Ma...@ijs.si> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|Undefined |3.3.2
Summary|__PILL_PRICE rules (having |[review] __PILL_PRICE rules
|"tflags multiple") cause |(having "tflags multiple")
|infinite loop when compiled |cause infinite loop when
| |compiled
Status Whiteboard| |needs 2 votes
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6558] [review] body rules having "tflags multiple" may cause
infinite loop when compiled
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
Kevin A. McGrail <km...@pccc.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status Whiteboard|needs 1 votes |rtc
--- Comment #21 from Kevin A. McGrail <km...@pccc.com> 2011-05-05 19:50:32 UTC ---
This has a patch from Mark and a vote from me and John. This is ready to
commit. I do not believe it needs more votes.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6558] __PILL_PRICE rules (having "tflags multiple") cause
infinite loop when compiled
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
Florian Hinzmann <ma...@fhinzmann.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mail@fhinzmann.de
--- Comment #7 from Florian Hinzmann <ma...@fhinzmann.de> 2011-03-22 04:27:10 EDT ---
Just to confirm this: It does affect 64bit, too.
celduin:~# uname -a
Linux celduin 2.6.32-5-amd64 #1 SMP Wed Jan 12 03:40:32 UTC 2011 x86_64
GNU/Linux
celduin:~# spamassassin --version
SpamAssassin version 3.3.1
running on Perl version 5.10.1
celduin:~# re2c --version
re2c 0.13.5
I will attach a spamassassin debug log and a very short mail I used
to trigger this bug.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6558] __PILL_PRICE rules (having "tflags multiple") cause
infinite loop when compiled
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
--- Comment #8 from Florian Hinzmann <ma...@fhinzmann.de> 2011-03-22 04:28:48 EDT ---
Created an attachment (id=4853)
--> (https://issues.apache.org/SpamAssassin/attachment.cgi?id=4853)
Short artificial email to trigger this bug
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6558] __PILL_PRICE rules (having "tflags multiple") cause
infinite loop only when compiled on ia32
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
John Hardin <jh...@impsec.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jhardin@impsec.org
--- Comment #1 from John Hardin <jh...@impsec.org> 2011-03-20 12:03:41 EDT ---
Oops. This one works better:
http://mail-archives.apache.org/mod_mbox/spamassassin-users/201103.mbox/%3C4D85D121.5020704@fastmail.net%3E
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6558] __PILL_PRICE rules (having "tflags multiple") cause
infinite loop only when compiled on ia32
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
--- Comment #6 from Karsten Bräckelmann <gu...@rudersport.de> 2011-03-20 20:39:05 EDT ---
Also, there are reports that one system was affected by this issue, though an
almost identical system (same OS, same packages, both Xeons, different speeds)
was not.
That might hint, that this is a really obscure bug with re2c, triggered in some
very specific cases only.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6558] __PILL_PRICE rules (having "tflags multiple") cause
infinite loop
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
John Hardin <jh...@impsec.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|__PILL_PRICE rules (having |__PILL_PRICE rules (having
|"tflags multiple") cause |"tflags multiple") cause
|infinite loop only when |infinite loop
|compiled on ia32 |
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6558] [review] body rules having "tflags multiple" may cause
infinite loop when compiled
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
John Hardin <jh...@impsec.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[review] __PILL_PRICE rules |[review] body rules having
|(having "tflags multiple") |"tflags multiple" may cause
|cause infinite loop when |infinite loop when compiled
|compiled |
--- Comment #18 from John Hardin <jh...@impsec.org> 2011-03-24 11:22:08 EDT ---
(In reply to comment #17)
>
> I thought this was an elegantly simple solution. +1 KAM
Agreed. +1 JDH
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6558] [review] __PILL_PRICE rules (having "tflags multiple")
cause infinite loop when compiled
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
--- Comment #16 from Mark Martinec <Ma...@ijs.si> 2011-03-23 18:38:55 EDT ---
trunk:
add a dummy function feature_bug6558_free() to allow
conditionalizing problematic rules;
a "feature" function must return a true to be considered'
Sending lib/Mail/SpamAssassin/Conf/Parser.pm
Sending lib/Mail/SpamAssassin/Conf.pm
Committed revision 1084790.
So something like this can be used to safely have problematic
rules in the ruleset (regardless of SA version):
if can(Mail::SpamAssassin::Conf::feature_bug6558_free)
meta MANY_PILL_PRICE ...
endif
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6558] __PILL_PRICE rules (having "tflags multiple") cause
infinite loop only when compiled on ia32
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
--- Comment #4 from John Hardin <jh...@impsec.org> 2011-03-20 20:21:56 EDT ---
Problem does also seem to affect x86_64
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6558] __PILL_PRICE rules (having "tflags multiple") cause
infinite loop only when compiled on ia32
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
--- Comment #3 from John Hardin <jh...@impsec.org> 2011-03-20 20:19:39 EDT ---
To spare people wading through the mail archive, if these rules are causing you
problems disable them by putting this in your local site config:
meta __PILL_PRICE_1 (0)
meta __PILL_PRICE_2 (0)
meta __PILL_PRICE_3 (0)
Thanks, Karsten!
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6558] [review] body rules having "tflags multiple" may cause
infinite loop when compiled
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
--- Comment #19 from John Hardin <jh...@impsec.org> 2011-03-26 19:48:46 EDT ---
(In reply to comment #15)
> Created an attachment (id=4859)
--> (https://issues.apache.org/SpamAssassin/attachment.cgi?id=4859) [details]
>
> Attached is a patch to BodyRuleBaseExtractor.pm which will
> make sa-compile report a warning when hitting a rule with
> tflag=multiple and a lossy match.
I restored the original problematic PILL_PRICE rules in my sandbox and ran
this, and they did _not_ generate warnings. Some other unpromoted rules
currently in my sandbox do generate warnings.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6558] __PILL_PRICE rules (having "tflags multiple") cause
infinite loop when compiled
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
--- Comment #13 from Mark Martinec <Ma...@ijs.si> 2011-03-22 16:26:34 EDT ---
Created an attachment (id=4856)
--> (https://issues.apache.org/SpamAssassin/attachment.cgi?id=4856)
Avoids [perl #86784] bug
Seems to be a perl bug, affecting 5.8, 5.10, 5.12, but not 5.13.10.
I have reported the perl bug as [perl #86784]:
http://rt.perl.org/rt3/Ticket/Display.html?id=86784
For a workaround I'm attaching the patch, which is essentially
Matt Elson's last suggested patch. It avoids copying the
string (Justin Mason's concern), while also working around
the perl bug. As noted above the perl 5.14 will no longer
exhibit this bug.
trunk:
fix to Bug 6558: __PILL_PRICE rules (having "tflags multiple")
cause infinite loop when compiled
Sending lib/Mail/SpamAssassin/Plugin/OneLineBodyRuleType.pm
Committed revision 1084340.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6558] [review] __PILL_PRICE rules (having "tflags multiple")
cause infinite loop when compiled
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
Kevin A. McGrail <km...@pccc.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kmcgrail@pccc.com
Status Whiteboard|needs 2 votes |needs 1 votes
--- Comment #17 from Kevin A. McGrail <km...@pccc.com> 2011-03-24 11:03:56 EDT ---
(In reply to comment #16)
> trunk:
> add a dummy function feature_bug6558_free() to allow
> conditionalizing problematic rules;
> a "feature" function must return a true to be considered'
> Sending lib/Mail/SpamAssassin/Conf/Parser.pm
> Sending lib/Mail/SpamAssassin/Conf.pm
> Committed revision 1084790.
>
> So something like this can be used to safely have problematic
> rules in the ruleset (regardless of SA version):
>
> if can(Mail::SpamAssassin::Conf::feature_bug6558_free)
> meta MANY_PILL_PRICE ...
> endif
I thought this was an elegantly simple solution. +1 KAM
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6558] __PILL_PRICE rules (having "tflags multiple") cause
infinite loop only when compiled on ia32
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
--- Comment #5 from Karsten Bräckelmann <gu...@rudersport.de> 2011-03-20 20:31:12 EDT ---
Heh, awesome -- I was just about to add the same note here, after reading
confirmation by a user, that my untested fix of disabling the sub-rules without
breaking dependencies worked.
The fix of commenting out tflags multiple for the affected rules (comment 0)
requires messing with the sa-update channel. The fix in comment 3 does not,
though it will require being reverted at a later point.
As another note, IIRC there are now two reports on the users list, that this
does not only affect 32 bit architecture.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.