Justin Mason wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
"Daryl C. W. O'Shea" writes:
Theo Van Dinter wrote:
I think I found a third bug btw:
3) mkrules tries to make sure that loadplugin lines go into the same
file as ifplugin sections, which won't work if the ifplugin sections
span multiple files.
I think this is a minor issue since we can just specify by policy that
in the sandbox, the plugin rules have to be in a single file.
Why aren't the loadplugin lines just loaded into a sandbox.pre file?
Would that be distributed in the make_install, tarball, and sa_update
build states (per http://wiki.apache.org/spamassassin/RuleLifeCycle )?
- - If not, it's the same thing as writing the loadplugin lines to the
"rules/70_sandbox.cf" file, so we haven't won anything there; the file
would still be nonexistent in those states, and the plugins not loaded.
- - If it *was* distributed in those states, there'd be a whole other can of
worms opened: we'd wind up distributing sandbox .pm files in "make
install", updates, etc. This is definitely something to avoid, in my
opinion, given that we don't have a good idea what code would be in
those .pm files and rogue perl code could conceivably cause a released
build of SpamAssassin running an 'sa-update' ruleset, to fall over.
Brain fart. No need for a sandbox.pre file now that the loadplugin
lines are sorted to the top of the .cf file.
My preferred fix, by the way, is:
- rules that are "ifplugin" for a sandbox plugin, are always forced into
the "experimental" rule state and therefore written to
"rules/70_sandbox.cf", even if they'd normally be good enough to go
into s_good.
- their "loadplugin" lines go into "rules/70_sandbox.cf" too; no need to
add a new sandbox.pre.
- we fix bug 4785 so that mkrules copies over the .pm's into the "rules"
dir, even if they're not listed in MANIFEST. Note that the
install states are free to ignore those files though.
The major side-effect of this would be that .pm files in a
"rulesrc/sandbox/*" dir have to be moved into the "rulesrc/core" dir
before their rules can become active (and in 'make install' et al).
I can't see any similarly coherent alternative.
That all sounds good to me.
Daryl