On Fri, 27 Apr 2001, Andi Gutmans wrote:
Oh OK now I understand. The problem is that MINIT is called before Apache
forks and then all children start from the same number. However, calling it
during each request init is also a bit of an overkill and slows down each
request. Calling it once should
How did you arrive to the conclusion that the current crypt() salts are not
random?
At 11:27 29/4/2001, Jani Taskinen wrote:
Well, what's the deal with this? Sascha?
--Jani
-- Forwarded message --
Date: Sat, 28 Apr 2001 15:05:08 +0200
From: Andi Gutmans [EMAIL PROTECTED]
On Sun, 29 Apr 2001, Zeev Suraski wrote:
How did you arrive to the conclusion that the current crypt() salts are not
random?
Uhm..how do you think? :)
If I get same salt after 5 page reloads it obviously isn't random?
(when I have 5 max apache childs..)
--Jani
--
PHP Development Mailing
The seed was initialized in MINIT before the children forked. So what
happened was that the children started returning the same random numbers.
Andi
At 12:52 PM 4/29/2001 +0300, Zeev Suraski wrote:
How did you arrive to the conclusion that the current crypt() salts are
not random?
At 11:27
At 13:58 29/4/2001, Andi Gutmans wrote:
The seed was initialized in MINIT before the children forked. So what
happened was that the children started returning the same random numbers.
It doesn't really matter where it was initialized, but rather, when it was
initialized...
Jani - are you
At 01:55 PM 4/29/2001 +0300, Zeev Suraski wrote:
At 13:58 29/4/2001, Andi Gutmans wrote:
The seed was initialized in MINIT before the children forked. So what
happened was that the children started returning the same random numbers.
It doesn't really matter where it was initialized, but rather,
At 14:57 29/4/2001, Andi Gutmans wrote:
At 01:55 PM 4/29/2001 +0300, Zeev Suraski wrote:
At 13:58 29/4/2001, Andi Gutmans wrote:
The seed was initialized in MINIT before the children forked. So what
happened was that the children started returning the same random numbers.
It doesn't really
At 02:05 PM 4/29/2001 +0300, Zeev Suraski wrote:
At 14:57 29/4/2001, Andi Gutmans wrote:
At 01:55 PM 4/29/2001 +0300, Zeev Suraski wrote:
At 13:58 29/4/2001, Andi Gutmans wrote:
The seed was initialized in MINIT before the children forked. So what
happened was that the children started returning
At 15:27 29/4/2001, Andi Gutmans wrote:
Jani has already moved it to RINIT which is a good beginning.
It may be a good beginning functionality wise, but it might not be a very
good beginning performance-wise. We should probably do it JIT.
Adding the pid is a good idea. Is there a function
At 02:35 PM 4/29/2001 +0300, Zeev Suraski wrote:
At 15:27 29/4/2001, Andi Gutmans wrote:
Jani has already moved it to RINIT which is a good beginning.
It may be a good beginning functionality wise, but it might not be a very
good beginning performance-wise. We should probably do it JIT.
Well
So it's probably not a lot more random than it was before...
Zeev
At 15:44 29/4/2001, Andi Gutmans wrote:
At 02:35 PM 4/29/2001 +0300, Zeev Suraski wrote:
At 15:27 29/4/2001, Andi Gutmans wrote:
Jani has already moved it to RINIT which is a good beginning.
It may be a good beginning
At 02:50 PM 4/29/2001 +0300, Zeev Suraski wrote:
So it's probably not a lot more random than it was before...
I think it is because the time of the rinit()'s are different now (unless
some of them run at exactly the same time).
Andi
Zeev
At 15:44 29/4/2001, Andi Gutmans wrote:
At 02:35 PM
Since it only occurs on the first time, chances are that (on a reasonably
loaded web site), most rinits will happen at the same second.
Zeev
At 15:54 29/4/2001, Andi Gutmans wrote:
At 02:50 PM 4/29/2001 +0300, Zeev Suraski wrote:
So it's probably not a lot more random than it was before...
I
On Sun, 29 Apr 2001, Zeev Suraski wrote:
In order to avoid this you actually have to call it at completely different
times, something you can't really guarantee. We should probably not use
the timestamp as the seed (at least not alone), but also take the pid into
account.
Zeev
That
In order to avoid this you actually have to call it at completely
different
times, something you can't really guarantee. We should
probably not use
the timestamp as the seed (at least not alone), but also take
the pid into
account.
Zeev
That only really works for
On Sun, 29 Apr 2001, James Moore wrote:
In order to avoid this you actually have to call it at completely
different
times, something you can't really guarantee. We should
probably not use
the timestamp as the seed (at least not alone), but also take
the pid into
account.
This is the line in question:
php_srand(time(0) * getpid() * (php_combined_lcg() * 1.0));
This is now (in my patch) in RINIT and thus it is a different pid
it doesn't matter if the RINIT happens the same second..
Or did I misunderstood something? And I know it works now. :)
And it didn't
At 09:42 PM 4/29/2001 +0200, Jani Taskinen wrote:
This is the line in question:
php_srand(time(0) * getpid() * (php_combined_lcg() * 1.0));
This is now (in my patch) in RINIT and thus it is a different pid
it doesn't matter if the RINIT happens the same second..
Or did I misunderstood
On Sun, 29 Apr 2001, Andi Gutmans wrote:
At 09:42 PM 4/29/2001 +0200, Jani Taskinen wrote:
This is the line in question:
php_srand(time(0) * getpid() * (php_combined_lcg() * 1.0));
This is now (in my patch) in RINIT and thus it is a different pid
it doesn't matter if the RINIT happens the
At 10:01 PM 4/29/2001 +0200, Jani Taskinen wrote:
On Sun, 29 Apr 2001, Andi Gutmans wrote:
At 09:42 PM 4/29/2001 +0200, Jani Taskinen wrote:
This is the line in question:
php_srand(time(0) * getpid() * (php_combined_lcg() * 1.0));
This is now (in my patch) in RINIT and thus it is a
On Sun, 29 Apr 2001, Andi Gutmans wrote:
At 09:42 PM 4/29/2001 +0200, Jani Taskinen wrote:
This is the line in question:
php_srand(time(0) * getpid() * (php_combined_lcg() * 1.0));
This is now (in my patch) in RINIT and thus it is a different pid
it doesn't matter if the RINIT happens the
hi,
That only really works for forking webservers, does it not? Another
alternative
would be to use microseconds...
Yeah we could use microseconds but are they available on all platforms?
In any case, on non-forking servers we can use thread id.
if it is a threading server then why not
22 matches
Mail list logo
