http://bugzilla.spamassassin.org/show_bug.cgi?id=3084
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WORKSFORME
------- Additional Comments From [EMAIL PROTECTED] 2004-03-01 23:42 -------
well, the key thing is to know when tok_pack is called, and what related token
is getting the value. from a quick check of the code, there are 3 places:
lib/Mail/SpamAssassin/BayesStore.pm:376: $new_toks{$tok} = $self->tok_pack
($ts, $th, $newatime);
lib/Mail/SpamAssassin/BayesStore.pm:664: $new_toks{$tok} = $self->tok_pack
($ts, $th, $atime); $kept++;
lib/Mail/SpamAssassin/BayesStore.pm:1257: $self->{db_toks}->{$tok} =
$self->tok_pack ($ts, $th, $atime);
376 is in upgrade_db. 664 is in expire_old_tokens_trapped. 1257 is in tok_put.
664 and 1257 will guarantee that the db is in v2 format (the db's have to be
writable before these functions get called otherwise the writes would fail, and
tie_db_writable() does an upgrade if necessary before letting anything else
touch the db.) 376 shouldn't be possible unless you _just_ upgraded from 2.5x
to 2.6x, and this was the first time you tried writing to the db. the other
two
very specifically check that the token in question is not a magic token in v2
format, 376 looks for magic tokens in whatever version is being upgraded.
or in short, the 2.6x code can't allow a magic token to get packed in and of
itself.
the only 3 possible scenarios I can see are:
1) switching between 2.5x and 2.6x with the same db and having 2.5x do an
expire. if you "sa-learn --dump data | egrep ' \*\*[A-Z]+$'", you can see if
you have any v0 magic tokens in the db. (just because it returns something
doesn't mean it's a magic token, but if they are things like OLDESTAGE, NHAM,
NSPAM, NTOKENS, etc, they are. which doesn't guarantee anything, v0 tokens in
v2 dbs are perfectly valid if they showed up in mails that you learned. but it
would tell me to see if I have 2.5x code anywhere that could possibly even look
at my bayes dbs in a strange or otherwise funny manner.)
2) a v0 DB with valid v2 magic tokens (I don't know how they'd get in there,
but...) gets upgraded to v2. we don't protect against this in the upgrade
code,
but there shouldn't be any way to get the ^M^A^G^I^C string in via SA 2.5x so
it
should never happen.
3) the database got modified through non-SA methods. this either corrupted the
DB or confused SA into corrupting the DB. for instance, some people out there
have written scripts to load a '--dump' output into a new DB. but the script
I've heard about actually only makes a v0 DB, but with v2 tokens -- which leads
directly to #2 above.
#1 and #3, frankly, aren't our problem if they're the cause. if #2 can be
caused by just using standard 2.5x and 2.6x code, not related to #1 or #3, then
that's something to fix.
if you want to keep poking at things and find a problem in the 2.6x code, we
can
reopen the ticket. for now I'm closing as wfm.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
