Re: sandbox loadplugins happening after rules in 70_sandbox.cf

[Justin Mason <jm...@jmason.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Theo Van Dinter writes:
> I was just noticing that my test rules which use my sandbox-felicity.pm plugin
> aren't hitting any mails.  Doing some debugging, I found that the loadplugin
> line occurs after all of the rules and their respective ifplugin areas.
> 
> I also noticed that Henry has a plugin whose loadplugin line doesn't even
> appear in the rules dir after a mkrules run, due to this error which I
> mentioned a few weeks ago:
> 
> rulesrc/sandbox/hstern/70_syndicate.cf: WARNING: 'rules/sandbox-hstern.pm' not
> listed in manifest file, line ignored: loadplugin
> Mail::SpamAssassin::Plugin::Sandbox::hstern sandbox-hstern.pm
> 
> I added it to the MANIFEST file so the line will be used, but the loadplugin
> has the same problem as mine does -- it comes after the use point.

Yeah, I think I raised this a week or two back.
In my opinion, a sandbox plugin file should *not* be listed in the
MANIFEST -- since we don't want to distribute sandbox code via:

    - "make install"
    - distributed tarballs
    - sa-update

There's no guarantee that sandbox code will be of a distributable quality,
yet.  As a result we should not distribute .pm's from the sandbox dir, and
only distribute .pm's from "rules" or "rulesrc/core".  Neither .pm should
be listed in MANIFEST, accordingly.

cf. also http://wiki.apache.org/spamassassin/RuleLifeCycle .

Let me know if that doesn't make sense, or if it's wrong. ;)

- --j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Exmh CVS

iD8DBQFD38AkMJF5cimLx9ARAi6FAJ4tJ9Q4QcsdUF/47l9C0urr5BU8bgCfS14h
64JVMpD2Bzt/CdWKoFwSr/o=
=uUn2
-----END PGP SIGNATURE-----

Re: sandbox loadplugins happening after rules in 70_sandbox.cf

[Theo Van Dinter <fe...@apache.org>]

On Mon, Feb 06, 2006 at 04:55:53PM -0800, Justin Mason wrote:
> 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.

I always figured the sandbox plugins were for testing, and eval rules that are
promoted should go into the normal Plugin dir with loadplugin in the
appropriate .pre file.

-- 
Randomly Generated Tagline:
#include <funnytag.h>

Re: sandbox loadplugins happening after rules in 70_sandbox.cf

["Daryl C. W. O'Shea" <sp...@dostech.ca>]

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?

Re: sandbox loadplugins happening after rules in 70_sandbox.cf

[Theo Van Dinter <fe...@apache.org>]

On Mon, Feb 06, 2006 at 09:40:12AM -0800, Justin Mason wrote:
> >1) right now we need to put the sandbox pm files in MANIFEST or else during
> >   the nightly runs, mkrules won't copy them over to the rules/ directory
> >   thereby not letting us test sandboxed eval rules.
> 
> ah, yes.  mkrules won't copy .pm's unless they are in the MANIFEST.
> 
> >2) the loadplugin line gets generated in the cf files after the rules
> >   that need it loaded, so the ifplugin requirement fails, and the rules
> >   aren't actually run.
> 
> And this should be easily fixable ;)
> 
> You're right, both are bugs; any chance of a bugzilla entry and I'll
> try to get them fixed RSN?

Sure, I'll open a BZ about #1.  I put in a patch for #2 earlier today, which
works though I don't like the implementation. :|
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4785

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.

-- 
Randomly Generated Tagline:
"If you're running the latest version of IIS, then you're not vulnerable to
 this [security hole], but you're vulnerable to something new." - Phil Cox

Re: sandbox loadplugins happening after rules in 70_sandbox.cf

[Theo Van Dinter <fe...@apache.org>]

On Tue, Jan 31, 2006 at 11:53:08AM -0800, Justin Mason wrote:
> There's no guarantee that sandbox code will be of a distributable quality,
> yet.  As a result we should not distribute .pm's from the sandbox dir, and
> only distribute .pm's from "rules" or "rulesrc/core".  Neither .pm should
> be listed in MANIFEST, accordingly.

Sure.  I don't mind not putting pm's in distribution (the code ought
to move to the Plugin directory (or EvalTests if we don't actually get
rid of it)), but we need to have them actually copied and used during
development.  So there's really two issues that I'm seeing at the moment:

1) right now we need to put the sandbox pm files in MANIFEST or else during
   the nightly runs, mkrules won't copy them over to the rules/ directory
   thereby not letting us test sandboxed eval rules.

2) the loadplugin line gets generated in the cf files after the rules
   that need it loaded, so the ifplugin requirement fails, and the rules
   aren't actually run.

-- 
Randomly Generated Tagline:
"Dear to the hearts of sailors and other people ... "   - Prof. Hilsinger