Re: exim arc4random patches
Salut Renaud, merci for volunteering to maintain exim. Renaud Allard wrote on Tue, Apr 17, 2018 at 02:55:56PM +0200: > On 04/17/2018 02:52 PM, Stuart Henderson wrote: >> Honestly I would leave the srandom bits in. No major objection, but they >> don't hurt and it will save you maintenance hassle merging patches when >> they fix the typo in the comment you are removing in this patch! >> Minimal patches are usually better. > That's not really a big hassle as I will probably make more changes > (pledge anyone?). Besides, I would prefer not to create a variable if it > can be trivially avoided. There is no doubt room for some personal decisions when maintaining a port, yet i *recommend* to adhere to those principles that are well-established across the ports tree as a whole. "Keep patches minimal" is relatively high on that list, right below "make sure it works and has no security holes". Even if *you* don't lose track of what you are doing with additional cosmetic patches, there are three reasons to still avoid them. 1. Not only the maintainer works on a port. People like ajacoutot, espie, naddy, sthen, and some others have to do sweeps of the tree at times, touching hundreds, sometimes thousands of ports at the same time. Ports directories that contain unnecessary files and files that are of unnecessary size can be a nuisance in such situations because they may have to be looked at. Even a few seconds spent for inspection are a problem when you have to cover thousands of ports. 2. Maintainers change. I'm not saying you are a jerk and will take up maintenance of the port and then run off next week (though it does happen occasionally that people promise a lot, start changing things, and then leave a half-finished mess behind - even i have left behind some construction sites of that kind over time). But at some point, your interests will probably change, and you will probably shift the focus of your work to some other ports, or to base, or whatever. When that time comes, you will *not* enjoy the work of bringing the port back to normal standards, and others will also be annoyed if they try to pick it up and first have to wade through unnecessary patches. It has caused problems in the past because people didn't expect the patches were really pointless and spent considerable time fruitlessly trying to understand what their point was before finally deleting them. 3. Users sometimes look at patches, for various reasons. Have pity on them and save their time. If you have excessive energy and want to polish exim, work with upstream. Regarding style, it may not be possible to reconcile OpenBSD and upstream conventions, and in that case, upstream takes precendence - tough luck... Still, sometimes, working with upstream can improve stuff for all. If you have excessive energy and insist on polishing turds, do so in base, not in ports. If you do substantial work on something in base, polishing the turds in the vicinity as well is appreciated. But avoid turd polishing in ports patches, please. Yours, Ingo
Re: exim arc4random patches
On 2018/04/17 15:01, Renaud Allard wrote: > > > On 04/17/2018 01:34 PM, Renaud Allard wrote: > > > Sorry, I made a stupid mistake, forgetting the _uniform > Here is a better one: This would have been easier to spot from reading the diff if it didn't have srandom parts ;-)
Re: exim arc4random patches
On 04/17/2018 01:34 PM, Renaud Allard wrote:
Sorry, I made a stupid mistake, forgetting the _uniform
Here is a better one:
Index: mail/exim//patches/patch-src_spam_c
===
RCS file: mail/exim//patches/patch-src_spam_c
diff -N mail/exim//patches/patch-src_spam_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ mail/exim//patches/patch-src_spam_c 17 Apr 2018 11:30:31 -
@@ -0,0 +1,33 @@
+--- src/spam.c.orig Tue Apr 17 10:56:03 2018
src/spam.c Tue Apr 17 13:26:42 2018
+@@ -139,21 +139,11 @@
+ spamd_address_container * sd;
+ long rnd, weights;
+ unsigned pri;
+-static BOOL srandomed = FALSE;
+
+ /* speedup, if we have only 1 server */
+ if (num_servers == 1)
+ return (spamds[0]->is_failed ? -1 : 0);
+
+-/* init ranmod */
+-if (!srandomed)
+- {
+- struct timeval tv;
+- gettimeofday(&tv, NULL);
+- srandom((unsigned int)(tv.tv_usec/1000));
+- srandomed = TRUE;
+- }
+-
+ /* scan for highest pri */
+ for (pri = 0, i = 0; i < num_servers; i++)
+ {
+@@ -170,7 +160,7 @@
+ if (weights == 0) /* all servers failed */
+ return -1;
+
+-for (rnd = random() % weights, i = 0; i < num_servers; i++)
++for (rnd = arc4random_uniform(weights), i = 0; i < num_servers; i++)
+ {
+ sd = spamds[i];
+ if (!sd->is_failed && sd->priority == pri)
Index: mail/exim//patches/patch-src_transports_smtp_socks_c
===
RCS file: mail/exim//patches/patch-src_transports_smtp_socks_c
diff -N mail/exim//patches/patch-src_transports_smtp_socks_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ mail/exim//patches/patch-src_transports_smtp_socks_c 17 Apr 2018 11:30:31 -
@@ -0,0 +1,32 @@
+--- src/transports/smtp_socks.c.orig Tue Apr 17 10:50:46 2018
src/transports/smtp_socks.c Tue Apr 17 13:28:06 2018
+@@ -161,20 +161,10 @@
+ socks_opts * lim = &proxies[nproxies];
+ long rnd, weights;
+ unsigned pri;
+-static BOOL srandomed = FALSE;
+
+ if (nproxies == 1) /* shortcut, if we have only 1 server */
+ return (proxies[0].is_failed ? -1 : 0);
+
+-/* init random */
+-if (!srandomed)
+- {
+- struct timeval tv;
+- gettimeofday(&tv, NULL);
+- srandom((unsigned int)(tv.tv_usec/1000));
+- srandomed = TRUE;
+- }
+-
+ /* scan for highest pri */
+ for (pri = 0, sd = proxies; sd < lim; sd++)
+ if (!sd->is_failed && sd->priority > pri)
+@@ -187,7 +177,7 @@
+ if (weights == 0) /* all servers failed */
+ return -1;
+
+-for (rnd = random() % weights, i = 0; i < nproxies; i++)
++for (rnd = arc4random_uniform(weights), i = 0; i < nproxies; i++)
+ {
+ sd = &proxies[i];
+ if (!sd->is_failed && sd->priority == pri)
smime.p7s
Description: S/MIME Cryptographic Signature
Re: exim arc4random patches
On 04/17/2018 02:52 PM, Stuart Henderson wrote: +-static BOOL srandomed = FALSE; + + /* speedup, if we have only 1 server */ + if (num_servers == 1) + return (spamds[0]->is_failed ? -1 : 0); + +-/* init ranmod */ +-if (!srandomed) Honestly I would leave the srandom bits in. No major objection, but they don't hurt and it will save you maintenance hassle merging patches when they fix the typo in the comment you are removing in this patch! Minimal patches are usually better. That's not really a big hassle as I will probably make more changes (pledge anyone?). Besides, I would prefer not to create a variable if it can be trivially avoided. smime.p7s Description: S/MIME Cryptographic Signature
Re: exim arc4random patches
On 2018/04/17 13:34, Renaud Allard wrote:
>
>
> On 04/17/2018 01:26 PM, Stuart Henderson wrote:
>
> > > I'm not going to object strongly, but this occurs twice:
> > >
> > > for (rnd = arc4random() % weights, i = 0; i < num_servers; i++)
> > >
> > > The expression
> > > arc4random() % weights;
> > >
> > > is subject to modulus bias. Use
> > >
> > > arc4random_uniform(weights);
> > >
> > > instead. I'm not sure this fixes all the problems with randomness in
> > > its vicinity, but it should be a bit better...
> >
> > This is something where a change to arc4random_uniform would make an actual
> > improvement so this one seems fair enough..
> >
>
> OK, does that one look like better?
> Index: mail/exim//patches/patch-src_spam_c
> ===
> RCS file: mail/exim//patches/patch-src_spam_c
> diff -N mail/exim//patches/patch-src_spam_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ mail/exim//patches/patch-src_spam_c 17 Apr 2018 11:30:31 -
> @@ -0,0 +1,33 @@
> +--- src/spam.c.orig Tue Apr 17 10:56:03 2018
> src/spam.c Tue Apr 17 13:26:42 2018
> +@@ -139,21 +139,11 @@
> + spamd_address_container * sd;
> + long rnd, weights;
> + unsigned pri;
> +-static BOOL srandomed = FALSE;
> +
> + /* speedup, if we have only 1 server */
> + if (num_servers == 1)
> + return (spamds[0]->is_failed ? -1 : 0);
> +
> +-/* init ranmod */
> +-if (!srandomed)
Honestly I would leave the srandom bits in. No major objection, but they
don't hurt and it will save you maintenance hassle merging patches when
they fix the typo in the comment you are removing in this patch!
Minimal patches are usually better.
> +- {
> +- struct timeval tv;
> +- gettimeofday(&tv, NULL);
> +- srandom((unsigned int)(tv.tv_usec/1000));
> +- srandomed = TRUE;
> +- }
> +-
> + /* scan for highest pri */
> + for (pri = 0, i = 0; i < num_servers; i++)
> + {
> +@@ -170,7 +160,7 @@
> + if (weights == 0) /* all servers failed */
> + return -1;
> +
> +-for (rnd = random() % weights, i = 0; i < num_servers; i++)
> ++for (rnd = arc4random_uniform(weights), i = 0; i < num_servers; i++)
> + {
> + sd = spamds[i];
> + if (!sd->is_failed && sd->priority == pri)
> Index: mail/exim//patches/patch-src_transports_smtp_socks_c
> ===
> RCS file: mail/exim//patches/patch-src_transports_smtp_socks_c
> diff -N mail/exim//patches/patch-src_transports_smtp_socks_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ mail/exim//patches/patch-src_transports_smtp_socks_c 17 Apr 2018
> 11:30:31 -
> @@ -0,0 +1,32 @@
> +--- src/transports/smtp_socks.c.orig Tue Apr 17 10:50:46 2018
> src/transports/smtp_socks.c Tue Apr 17 13:28:06 2018
> +@@ -161,20 +161,10 @@
> + socks_opts * lim = &proxies[nproxies];
> + long rnd, weights;
> + unsigned pri;
> +-static BOOL srandomed = FALSE;
> +
> + if (nproxies == 1) /* shortcut, if we have only 1 server */
> + return (proxies[0].is_failed ? -1 : 0);
> +
> +-/* init random */
> +-if (!srandomed)
> +- {
> +- struct timeval tv;
> +- gettimeofday(&tv, NULL);
> +- srandom((unsigned int)(tv.tv_usec/1000));
> +- srandomed = TRUE;
> +- }
> +-
> + /* scan for highest pri */
> + for (pri = 0, sd = proxies; sd < lim; sd++)
> + if (!sd->is_failed && sd->priority > pri)
> +@@ -187,7 +177,7 @@
> + if (weights == 0) /* all servers failed */
> + return -1;
> +
> +-for (rnd = random() % weights, i = 0; i < nproxies; i++)
> ++for (rnd = arc4random(weights), i = 0; i < nproxies; i++)
> + {
> + sd = &proxies[i];
> + if (!sd->is_failed && sd->priority == pri)
Re: exim arc4random patches
On 04/17/2018 01:26 PM, Stuart Henderson wrote:
I'm not going to object strongly, but this occurs twice:
for (rnd = arc4random() % weights, i = 0; i < num_servers; i++)
The expression
arc4random() % weights;
is subject to modulus bias. Use
arc4random_uniform(weights);
instead. I'm not sure this fixes all the problems with randomness in
its vicinity, but it should be a bit better...
This is something where a change to arc4random_uniform would make an actual
improvement so this one seems fair enough..
OK, does that one look like better?
Index: mail/exim//patches/patch-src_spam_c
===
RCS file: mail/exim//patches/patch-src_spam_c
diff -N mail/exim//patches/patch-src_spam_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ mail/exim//patches/patch-src_spam_c 17 Apr 2018 11:30:31 -
@@ -0,0 +1,33 @@
+--- src/spam.c.orig Tue Apr 17 10:56:03 2018
src/spam.c Tue Apr 17 13:26:42 2018
+@@ -139,21 +139,11 @@
+ spamd_address_container * sd;
+ long rnd, weights;
+ unsigned pri;
+-static BOOL srandomed = FALSE;
+
+ /* speedup, if we have only 1 server */
+ if (num_servers == 1)
+ return (spamds[0]->is_failed ? -1 : 0);
+
+-/* init ranmod */
+-if (!srandomed)
+- {
+- struct timeval tv;
+- gettimeofday(&tv, NULL);
+- srandom((unsigned int)(tv.tv_usec/1000));
+- srandomed = TRUE;
+- }
+-
+ /* scan for highest pri */
+ for (pri = 0, i = 0; i < num_servers; i++)
+ {
+@@ -170,7 +160,7 @@
+ if (weights == 0) /* all servers failed */
+ return -1;
+
+-for (rnd = random() % weights, i = 0; i < num_servers; i++)
++for (rnd = arc4random_uniform(weights), i = 0; i < num_servers; i++)
+ {
+ sd = spamds[i];
+ if (!sd->is_failed && sd->priority == pri)
Index: mail/exim//patches/patch-src_transports_smtp_socks_c
===
RCS file: mail/exim//patches/patch-src_transports_smtp_socks_c
diff -N mail/exim//patches/patch-src_transports_smtp_socks_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ mail/exim//patches/patch-src_transports_smtp_socks_c 17 Apr 2018 11:30:31 -
@@ -0,0 +1,32 @@
+--- src/transports/smtp_socks.c.orig Tue Apr 17 10:50:46 2018
src/transports/smtp_socks.c Tue Apr 17 13:28:06 2018
+@@ -161,20 +161,10 @@
+ socks_opts * lim = &proxies[nproxies];
+ long rnd, weights;
+ unsigned pri;
+-static BOOL srandomed = FALSE;
+
+ if (nproxies == 1) /* shortcut, if we have only 1 server */
+ return (proxies[0].is_failed ? -1 : 0);
+
+-/* init random */
+-if (!srandomed)
+- {
+- struct timeval tv;
+- gettimeofday(&tv, NULL);
+- srandom((unsigned int)(tv.tv_usec/1000));
+- srandomed = TRUE;
+- }
+-
+ /* scan for highest pri */
+ for (pri = 0, sd = proxies; sd < lim; sd++)
+ if (!sd->is_failed && sd->priority > pri)
+@@ -187,7 +177,7 @@
+ if (weights == 0) /* all servers failed */
+ return -1;
+
+-for (rnd = random() % weights, i = 0; i < nproxies; i++)
++for (rnd = arc4random(weights), i = 0; i < nproxies; i++)
+ {
+ sd = &proxies[i];
+ if (!sd->is_failed && sd->priority == pri)
smime.p7s
Description: S/MIME Cryptographic Signature
Re: exim arc4random patches
On 2018/04/17 13:10, Theo Buehler wrote: > On Tue, Apr 17, 2018 at 12:58:09PM +0200, Renaud Allard wrote: > > > > > > On 04/17/2018 11:34 AM, Theo Buehler wrote: > > > On Tue, Apr 17, 2018 at 11:18:50AM +0200, Renaud Allard wrote: > > > > Hello, > > > > > > > > This patch for exim replaces all calls to rand() and random() to the > > > > secure > > > > OpenBSD version, making the compiler less unhappy. > > > > After a discussion with one of the exim devs, this change would not have > > > > been accepted in mainstream exim because there is no "need" to use a > > > > crypto > > > > secure algorithm each time. But we do that anyway on OpenBSD, so here it > > > > makes sense. > > > > > > > > Regards > > > > > > Since this patch is only for OpenBSD, it is not needed. On OpenBSD, > > > rand() and random() internally use arc4random() unless > > > srand_deterministic() was called (which exim doesn't do, of course). > > > > > > The way I understand it, the APIWARN is there to make people aware that > > > this might be a problem on other systems. The rand(3) manuals states: > > > > > > Standards insist that this interface return deterministic results. > > > Unsafe usage is very common, so OpenBSD changed the subsystem to > > > return > > > non-deterministic results by default. > > > > > > [...] > > > > > > If srand_deterministic() was called, the result will be computed > > > using the > > > deterministic algorithm. > > > > > > Same goes for random(3). > > > > > > Generally, we are reluctant to change ports locally to use the OpenBSD > > > idioms to silence this kind of link time warnings (e.g. string handling). > > > > > > > Hi Theo, > > > > I understand your point of view, but this patch also removes some useless > > checks and calls to srandom(). As discussed with stenh@, I am willing to > > become the maintainer of this port, so I will be maintaining those patches > > too anyway. I agree with tb@, I don't think we should have what are basically noop patches in the ports tree just to silence linker warnings. If upstream are willing to take them (with proper compile checks etc) then it improves things for other OS users. But just replacing random/srand with arc4random on OpenBSD doesn't give a real benefit. There is one caveat with keeping them as-is; if something uses a library that calls one of the *rand*_deterministic functions. From looking over ports I think the only danger area there is things using lua. There are a bunch of similar patches in-tree from when this *did* make a difference. Perhaps these should be removed. (At least these are less likely to cause major breakage than some of the str* patches that have been in the ports tree in the past...) > I'm not going to object strongly, but this occurs twice: > > for (rnd = arc4random() % weights, i = 0; i < num_servers; i++) > > The expression > arc4random() % weights; > > is subject to modulus bias. Use > > arc4random_uniform(weights); > > instead. I'm not sure this fixes all the problems with randomness in > its vicinity, but it should be a bit better... This is something where a change to arc4random_uniform would make an actual improvement so this one seems fair enough..
Re: exim arc4random patches
On Tue, Apr 17, 2018 at 12:58:09PM +0200, Renaud Allard wrote: > > > On 04/17/2018 11:34 AM, Theo Buehler wrote: > > On Tue, Apr 17, 2018 at 11:18:50AM +0200, Renaud Allard wrote: > > > Hello, > > > > > > This patch for exim replaces all calls to rand() and random() to the > > > secure > > > OpenBSD version, making the compiler less unhappy. > > > After a discussion with one of the exim devs, this change would not have > > > been accepted in mainstream exim because there is no "need" to use a > > > crypto > > > secure algorithm each time. But we do that anyway on OpenBSD, so here it > > > makes sense. > > > > > > Regards > > > > Since this patch is only for OpenBSD, it is not needed. On OpenBSD, > > rand() and random() internally use arc4random() unless > > srand_deterministic() was called (which exim doesn't do, of course). > > > > The way I understand it, the APIWARN is there to make people aware that > > this might be a problem on other systems. The rand(3) manuals states: > > > > Standards insist that this interface return deterministic results. > > Unsafe usage is very common, so OpenBSD changed the subsystem to > > return > > non-deterministic results by default. > > > > [...] > > > > If srand_deterministic() was called, the result will be computed > > using the > > deterministic algorithm. > > > > Same goes for random(3). > > > > Generally, we are reluctant to change ports locally to use the OpenBSD > > idioms to silence this kind of link time warnings (e.g. string handling). > > > > Hi Theo, > > I understand your point of view, but this patch also removes some useless > checks and calls to srandom(). As discussed with stenh@, I am willing to > become the maintainer of this port, so I will be maintaining those patches > too anyway. > I'm not going to object strongly, but this occurs twice: for (rnd = arc4random() % weights, i = 0; i < num_servers; i++) The expression arc4random() % weights; is subject to modulus bias. Use arc4random_uniform(weights); instead. I'm not sure this fixes all the problems with randomness in its vicinity, but it should be a bit better...
Re: exim arc4random patches
On 04/17/2018 11:34 AM, Theo Buehler wrote: On Tue, Apr 17, 2018 at 11:18:50AM +0200, Renaud Allard wrote: Hello, This patch for exim replaces all calls to rand() and random() to the secure OpenBSD version, making the compiler less unhappy. After a discussion with one of the exim devs, this change would not have been accepted in mainstream exim because there is no "need" to use a crypto secure algorithm each time. But we do that anyway on OpenBSD, so here it makes sense. Regards Since this patch is only for OpenBSD, it is not needed. On OpenBSD, rand() and random() internally use arc4random() unless srand_deterministic() was called (which exim doesn't do, of course). The way I understand it, the APIWARN is there to make people aware that this might be a problem on other systems. The rand(3) manuals states: Standards insist that this interface return deterministic results. Unsafe usage is very common, so OpenBSD changed the subsystem to return non-deterministic results by default. [...] If srand_deterministic() was called, the result will be computed using the deterministic algorithm. Same goes for random(3). Generally, we are reluctant to change ports locally to use the OpenBSD idioms to silence this kind of link time warnings (e.g. string handling). Hi Theo, I understand your point of view, but this patch also removes some useless checks and calls to srandom(). As discussed with stenh@, I am willing to become the maintainer of this port, so I will be maintaining those patches too anyway. smime.p7s Description: S/MIME Cryptographic Signature
Re: exim arc4random patches
On Tue, Apr 17, 2018 at 11:18:50AM +0200, Renaud Allard wrote: > Hello, > > This patch for exim replaces all calls to rand() and random() to the secure > OpenBSD version, making the compiler less unhappy. > After a discussion with one of the exim devs, this change would not have > been accepted in mainstream exim because there is no "need" to use a crypto > secure algorithm each time. But we do that anyway on OpenBSD, so here it > makes sense. > > Regards Since this patch is only for OpenBSD, it is not needed. On OpenBSD, rand() and random() internally use arc4random() unless srand_deterministic() was called (which exim doesn't do, of course). The way I understand it, the APIWARN is there to make people aware that this might be a problem on other systems. The rand(3) manuals states: Standards insist that this interface return deterministic results. Unsafe usage is very common, so OpenBSD changed the subsystem to return non-deterministic results by default. [...] If srand_deterministic() was called, the result will be computed using the deterministic algorithm. Same goes for random(3). Generally, we are reluctant to change ports locally to use the OpenBSD idioms to silence this kind of link time warnings (e.g. string handling).
exim arc4random patches
Hello,
This patch for exim replaces all calls to rand() and random() to the
secure OpenBSD version, making the compiler less unhappy.
After a discussion with one of the exim devs, this change would not have
been accepted in mainstream exim because there is no "need" to use a
crypto secure algorithm each time. But we do that anyway on OpenBSD, so
here it makes sense.
Regards
Index: mail/exim//patches/patch-src_deliver_c
===
RCS file: mail/exim//patches/patch-src_deliver_c
diff -N mail/exim//patches/patch-src_deliver_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ mail/exim//patches/patch-src_deliver_c 17 Apr 2018 09:11:29 -
@@ -0,0 +1,29 @@
+--- src/deliver.c.orig Tue Apr 17 10:49:10 2018
src/deliver.c Tue Apr 17 10:45:34 2018
+@@ -7277,7 +7277,7 @@
+ debug_printf("sending error message to: %s\n", sender_address);
+
+ /* build unique id for MIME boundary */
+-bound = string_sprintf(TIME_T_FMT "-eximdsn-%d", time(NULL), rand());
++bound = string_sprintf(TIME_T_FMT "-eximdsn-%d", time(NULL), arc4random());
+ DEBUG(D_deliver) debug_printf("DSN: MIME boundary: %s\n", bound);
+
+ if (errors_reply_to)
+@@ -7528,7 +7528,7 @@
+ fprintf(f, "To: %s\n", bounce_recipient);
+
+ /* generate boundary string and output MIME-Headers */
+- bound = string_sprintf(TIME_T_FMT "-eximdsn-%d", time(NULL), rand());
++ bound = string_sprintf(TIME_T_FMT "-eximdsn-%d", time(NULL), arc4random());
+
+ fprintf(f, "Content-Type: multipart/report;"
+ " report-type=delivery-status; boundary=%s\n"
+@@ -8148,7 +8148,7 @@
+ fprintf(f, "To: %s\n", recipients);
+
+ /* generated boundary string and output MIME-Headers */
+-bound = string_sprintf(TIME_T_FMT "-eximdsn-%d", time(NULL), rand());
++bound = string_sprintf(TIME_T_FMT "-eximdsn-%d", time(NULL), arc4random());
+
+ fprintf(f, "Content-Type: multipart/report;"
+ " report-type=delivery-status; boundary=%s\n"
Index: mail/exim//patches/patch-src_spam_c
===
RCS file: mail/exim//patches/patch-src_spam_c
diff -N mail/exim//patches/patch-src_spam_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ mail/exim//patches/patch-src_spam_c 17 Apr 2018 09:11:29 -
@@ -0,0 +1,33 @@
+--- src/spam.c.orig Tue Apr 17 10:56:03 2018
src/spam.c Tue Apr 17 10:56:44 2018
+@@ -139,21 +139,11 @@
+ spamd_address_container * sd;
+ long rnd, weights;
+ unsigned pri;
+-static BOOL srandomed = FALSE;
+
+ /* speedup, if we have only 1 server */
+ if (num_servers == 1)
+ return (spamds[0]->is_failed ? -1 : 0);
+
+-/* init ranmod */
+-if (!srandomed)
+- {
+- struct timeval tv;
+- gettimeofday(&tv, NULL);
+- srandom((unsigned int)(tv.tv_usec/1000));
+- srandomed = TRUE;
+- }
+-
+ /* scan for highest pri */
+ for (pri = 0, i = 0; i < num_servers; i++)
+ {
+@@ -170,7 +160,7 @@
+ if (weights == 0) /* all servers failed */
+ return -1;
+
+-for (rnd = random() % weights, i = 0; i < num_servers; i++)
++for (rnd = arc4random() % weights, i = 0; i < num_servers; i++)
+ {
+ sd = spamds[i];
+ if (!sd->is_failed && sd->priority == pri)
Index: mail/exim//patches/patch-src_transports_smtp_socks_c
===
RCS file: mail/exim//patches/patch-src_transports_smtp_socks_c
diff -N mail/exim//patches/patch-src_transports_smtp_socks_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ mail/exim//patches/patch-src_transports_smtp_socks_c 17 Apr 2018 09:11:29 -
@@ -0,0 +1,32 @@
+--- src/transports/smtp_socks.c.orig Tue Apr 17 10:50:46 2018
src/transports/smtp_socks.c Tue Apr 17 10:51:19 2018
+@@ -161,20 +161,10 @@
+ socks_opts * lim = &proxies[nproxies];
+ long rnd, weights;
+ unsigned pri;
+-static BOOL srandomed = FALSE;
+
+ if (nproxies == 1) /* shortcut, if we have only 1 server */
+ return (proxies[0].is_failed ? -1 : 0);
+
+-/* init random */
+-if (!srandomed)
+- {
+- struct timeval tv;
+- gettimeofday(&tv, NULL);
+- srandom((unsigned int)(tv.tv_usec/1000));
+- srandomed = TRUE;
+- }
+-
+ /* scan for highest pri */
+ for (pri = 0, sd = proxies; sd < lim; sd++)
+ if (!sd->is_failed && sd->priority > pri)
+@@ -187,7 +177,7 @@
+ if (weights == 0) /* all servers failed */
+ return -1;
+
+-for (rnd = random() % weights, i = 0; i < nproxies; i++)
++for (rnd = arc4random() % weights, i = 0; i < nproxies; i++)
+ {
+ sd = &proxies[i];
+ if (!sd->is_failed && sd->priority == pri)
smime.p7s
Description: S/MIME Cryptographic Signature
