Created attachment 5006 [details]
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).