spamassassin-dev November 2011 archive
Main Archive Page > Month Archives  > spamassassin-dev archives
spamassassin-dev: [Bug 6690] New: Give a caller a choice to call

[Bug 6690] New: Give a caller a choice to call srand() by itself or let a SpamAssassin library do it

From: <bugzilla-daemon_at_nospam>
Date: Thu Nov 03 2011 - 17:39:14 GMT
To: dev@spamassassin.apache.org

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6690

             Bug #: 6690
           Summary: Give a caller a choice to call srand() by itself or
                    let a SpamAssassin library do it
           Product: Spamassassin
           Version: SVN Trunk (Latest Devel Version)
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Libraries
        AssignedTo: dev@spamassassin.apache.org
        ReportedBy: Mark.Martinec@ijs.si
    Classification: Unclassified

Created attachment 5006
  --> https://issues.apache.org/SpamAssassin/attachment.cgi?id=5006
suggested change

Here is a rather straightforward small change (two lines of code, plus docs)
which allows a caller (like spamd or amavisd) to call srand() soon after
forking, or let the library do it automatically as before. The change
retains compatibility with existing code and third party tools.

Here is a docs change, adding an option "skip_prng_reseeding" to a
list of options in a Mail::SpamAssassin->new() call:

+=item skip_prng_reseeding
+
+Mostly a compatibility measure. If this boolean setting is true, the
+SpamAssassin library will B<not> call srand() to reseed a pseudorandom
+number generator (PRNG). The srand() Perl function should be called during
+initialization of each child process, soon after forking. This can be done
+either by a caller (like spamd, or third party tools), or by the SpamAssassin
+library when it notices that its process id has changed. With versions 3.3.*
+and earlier the srand() was called unconditionally by the library - which may
+be undesired when a caller has already done it and wants to cherishly preserve
+entropy of a PRNG. Starting with 3.4.0 the caller has a choice. The default
+value of false (undef) maintains compatibility with former behaviour. This
+option should be set by a caller if it is calling srand() by itself on
spawning
+child processes.

These are the two code changes in brief:

lib/Mail/SpamAssassin.pm:
- srand;
+ srand if !$self->{skip_prng_reseeding};

spamd/spamd.raw:
+ skip_prng_reseeding => 1, # let us do the reseeding by ourselves
[...]
+ srand; # reseed pseudorandom number generator soon for each child process

The suggested change was prompted when I noticed that SpamAssassin.pm is
needlessly reshuffling the already shuffled perl random number generator,
which amavisd has already carefully reseeded by delegating it some of the
entropy it is maintaining.

The change also benefits spamd by calling srand() earlier, right after
forking. Previously the early initialization phases of a spamd child
process were all working with the same prng seed: a call to plugins
"spamd_child_init", reading use preferences, initializing bayes learner
object, (possibly more).

-- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.