ps: patch contains more comments and description

> i'm sorry to write you directly, but as pecl site is broken (again!? no 
> wonder!), there's no way to report bugs :(

Pardon? bugs.php.net is the place where pecl's issues are reported. Just like what 
you just did.

I moved this to a non secure related issue as none of rand or mt_rand are security 
related anyway.

btw, could you attach the patch to this issue please?

you're missing the fact that it WAS BROKEN, Ferenc fixed it today:


On Thu, Aug 16, 2012 at 10:04 AM, Elan Ruusamäe <glen@delfi.ee> wrote:

    http://pecl.php.net/bugs/search.php?
cmd=display&package_name[]=solr&status=Open

    says to contact here

    link came from this page http://pecl.php.net/package/solr
     


Hi Elan,

We merged the pecl bugtracker into the main bugtracker on bugs.php.net.
That package had his bugtracker url still set to the old url, I've just fixed 
it, thanks for reporting it.

I've checked the database, and we have two other package(ncurses and funcall) 
having the same issue(having bug_link explicitly set to 
http://pec.php.net/bugs/), I also fixed those.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

you should really get to understand how your infra works before blaming or 
requesting impossible stuff

it is not possible to attach any file to private bugs

and i don't understand why you can't take the patch from url:
http://cvs.pld-linux.org/cgi-bin/viewvc.cgi/cvs/packages/php-pecl-solr/do-not-
screw-with-random-seed.patch

> I moved this to a non secure related issue as none of rand or mt_rand are 
security related anyway.

regarding security: i explained if someone's security defense is based on 
randomizer (generates login cookie based on rand(), for example), and if 
randomizer is predictable, then the security defense is broken as well. so this 
is security *related*

@glen at delfi dot ee

With all respects, if an app is still using rand (or mt_rand) for any security 
related area, then the app has big troubles, no matter what solr does or not.

As it is clearly a bug (somehow security), it is not critical to be marked as 
private or to be discussed only in security@


Btw, look here too:

http://lxr.php.net/search?q=&defs=&refs=srand&path=&hist=&project=PECL

I did not check all of them :)

couldn't agree more that apps relaying only on rand() have poor security :)

indeed, those lxr refs initializing with time(), time(NULL), time(thisTime), and 
even time(seed) from mysqlng (seed is microseconds from gettimeofday there) are 
evil as well and should be fixed, or at least commented why exactly that code 
changes something so global as randomizer state.

that srand(0) there is at least on purpose:
470#if defined(DEBUG)
471  /* To make it random number generator repeatable to ease testing. */
472  srand(0);
473#endif

php_bloomy.c doing srand based on GENERATE_SEED() does not seem well either, as 
php engine provides initial randomizer setup, perhaps that GENERATE_SEED macro 
should be made private so extensions can't (ab)use it...

uploaded patch to bugtracker. duplicating patch header as probably nobody 
bothers to read it (from patch itself) :)

---
Do not initialize the seed with srand or mt_srand, it is already initialized
since PHP 4.2.0 (See the docs). And if you initialize it with time or microtime
you make it only more worse (predictable).

And initializing random seed with predictable value is extremely stupid.

I had situation that three machines simulatenously produced temporary directory
names based on random generator, and they all got same results, this is utterly
screwed up up the application!

Jul  6 10:37:26 segusilm php.fcgi: PHP Fatal error:  Uncaught exception 
'Exception' with message 'Can't mkdir '/tmp/foo_UZNHCMUDWZ/archive': mkdir(): 
File exists' in /usr/share/foo/lib/plugins/Plugin.php:127
Jul  6 10:37:26 lordi php.fcgi: PHP Warning:  
unlink(/tmp/foo_UZNHCMUDWZ/archive/title.inc): No such file or directory in 
/usr/share/foo/lib/helper/OutputHelper.php on line 68

it is strongly recommended for PHP application developers to keep their fingers
away from srand() or mt_srand() and to never ever use rand() or mt_rand() for
cryptographic secrets:
http://www.suspekt.org/2008/08/17/mt_srand-and-not-so-random-numbers/

PING?!

any progress with this?