------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=722
--- Comment #8 from Phil Pennock <exim-dev@spodhuis.org> 2008-08-14 10:24:44 ---
Created an attachment (id=264)
--> (http://bugs.exim.org/attachment.cgi?id=264)
Patch to add ${randint:...} expansion operator
This provides ${randint:...} which expects a positive decimal number parameter
and returns a randomish number with a value between (inclusive) 0 and param-1.
I'm tired and the GNUTLS functions did not look amenable.
If SUPPORT_TLS is defined and HAVE_GNUTLS is not, then OpenSSL RAND_* will be
used to get randomness.
Otherwise, hope that one of HAVE_ARC4RANDOM, HAVE_SRANDOMDEV or HAVE_SRANDOM is
defined, because otherwise you're going to get the 16-bit poor randomness
provided by host.c random_number() which seemed a decent fallback. Those are
defined in preferential order.
Defining those HAVE_* definitions is more interesting and not included in this
patch.
OS/os.h-Linux should be able to define HAVE_SRANDOM
OS/os.h-<BSDs> should be able to define all 3; that's FreeBSD, OpenBSD,
DragonFly and I suspect all three NetBSD variants. My MacOS box has arc4random
even.
srandom is part of SUSv3; I'm looking at issue 6, which notes "First released
in Issue 4, Version 2". I've confirmed srandom in man-pages for Solaris, all
the way back to SunOS 4.1.3 days (and probably earlier but that's the oldest
set of man-pages I keep for that family). Also HP-UX 10 & 11; ULTRIX 4.2;
I don't have man-pages for AIX.
I'm tempted to define HAVE_SRANDOM by default in EDITME and just define
HAVE_SRANDOMDEV and HAVE_ARC4RANDOM in the BSD OS/os.h<foo> files and have a
small block mentioning all three in EDITME. The link errors if srandom() isn't
available will let us know quickly enough if it's less portable and this will
provide an easy way for people to unset it.
Without writing 10x the amount of code with checks for EGD for something which
is only being made as strong as it is because I *know* that in the future
people will invent home-grown crypto for anti-spam and then whine when it
doesn't work, I think this is the reasonable limit.
--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email
--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=722
--- Comment #8 from Phil Pennock <exim-dev@spodhuis.org> 2008-08-14 10:24:44 ---
Created an attachment (id=264)
--> (http://bugs.exim.org/attachment.cgi?id=264)
Patch to add ${randint:...} expansion operator
This provides ${randint:...} which expects a positive decimal number parameter
and returns a randomish number with a value between (inclusive) 0 and param-1.
I'm tired and the GNUTLS functions did not look amenable.
If SUPPORT_TLS is defined and HAVE_GNUTLS is not, then OpenSSL RAND_* will be
used to get randomness.
Otherwise, hope that one of HAVE_ARC4RANDOM, HAVE_SRANDOMDEV or HAVE_SRANDOM is
defined, because otherwise you're going to get the 16-bit poor randomness
provided by host.c random_number() which seemed a decent fallback. Those are
defined in preferential order.
Defining those HAVE_* definitions is more interesting and not included in this
patch.
OS/os.h-Linux should be able to define HAVE_SRANDOM
OS/os.h-<BSDs> should be able to define all 3; that's FreeBSD, OpenBSD,
DragonFly and I suspect all three NetBSD variants. My MacOS box has arc4random
even.
srandom is part of SUSv3; I'm looking at issue 6, which notes "First released
in Issue 4, Version 2". I've confirmed srandom in man-pages for Solaris, all
the way back to SunOS 4.1.3 days (and probably earlier but that's the oldest
set of man-pages I keep for that family). Also HP-UX 10 & 11; ULTRIX 4.2;
I don't have man-pages for AIX.
I'm tempted to define HAVE_SRANDOM by default in EDITME and just define
HAVE_SRANDOMDEV and HAVE_ARC4RANDOM in the BSD OS/os.h<foo> files and have a
small block mentioning all three in EDITME. The link errors if srandom() isn't
available will let us know quickly enough if it's less portable and this will
provide an easy way for people to unset it.
Without writing 10x the amount of code with checks for EGD for something which
is only being made as strong as it is because I *know* that in the future
people will invent home-grown crypto for anti-spam and then whine when it
doesn't work, I think this is the reasonable limit.
--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email
--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##