[PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

Hi all, On Sat, Jul 2, 2016 at 4:35 PM, Yasuo Ohgaki wrote: > Currently session module uses obsolete MD5 for session ID. With > CSPRNG, hashing is redundant and needless. It adds hash module > dependency and inefficient (There is no reason to use hash for CSPRNG > generated bytes). > > This propo

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

Hi Pierre, On Tue, Jul 5, 2016 at 12:02 PM, Pierre Joye wrote: >> Current implementation is regenerating random hash string by using >> >> - PID >> - Time (Simple random function) >> - CSPRNG when it is available > > For clarification, it is always available. Php requires a valid one to be > b

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

On Jul 5, 2016 6:14 AM, "Yasuo Ohgaki" wrote: > > Hi Stas, > > Thank you for sharing opinion. > Followings is mine. > > On Tue, Jul 5, 2016 at 7:23 AM, Stanislav Malyshev wrote: > >> Could you share the reason why against this change? > > > > 1. I'm not sure exporting raw generator state is a goo

[PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

Hi Dan, On Tue, Jul 5, 2016 at 9:36 AM, Dan Ackroyd wrote: >> Could you share the reason why against this change? > > The RFC is doing separate things: No. It simply follows best practice not to reinvent wheel and keep things simple. > > * Using a proper random number generator - which is proba

[PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

Hi Yasuo, > Could you share the reason why against this change? The RFC is doing separate things: * Using a proper random number generator - which is probably a good thing, and I probably would vote/support that change by itself. * Removing old stuff for performance reasons - probably a bad thi

[PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

Hi Stas, Thank you for sharing opinion. Followings is mine. On Tue, Jul 5, 2016 at 7:23 AM, Stanislav Malyshev wrote: >> Could you share the reason why against this change? > > 1. I'm not sure exporting raw generator state is a good practice. I may > change my opinion on the subject if I hear fr

[PHP-DEV] [RFC][DISCUSSION] Enable session.use_strict_mode by default

Hi all, Enabling session.use_strict_mode is mandatory setting for secure session management. This RFC proposes enabling session.use_strict_mode by default. https://wiki.php.net/rfc/session-use-strict-mode I appreciate any comments/improvements/corrections. Thank you! -- Yasuo Ohgaki yohg...@o

[PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

Hi! > Could you share the reason why against this change? 1. I'm not sure exporting raw generator state is a good practice. I may change my opinion on the subject if I hear from some security people (I'm no crypto expert) that this is ok, then I may change my opinion. 2. Due to (1), I do not thi

Re: [PHP-DEV] About session.use_strict_mode=0 by default (was: Re: [PHP-DEV] [RFC][VOTE] Session ID without hashing)

Hi Markus, On Sat, Jul 2, 2016 at 6:06 PM, Markus Fischer wrote: > Everytime I see a thread mentioning session.use_strict_mode I'm > wondering why we haven't got around to enable it by default (by means of > php.ini-development/php.ini-production ). > > Maybe someone can step forward and propose

[PHP-DEV] Re: [RFC] Additional context in pcntl_signal handler (was Re: [PHP-DEV] pcntl_signal & sa_siginfo)

On Thu, Jun 23, 2016 at 1:18 PM, Bishop Bettini wrote: > Hi All, > > David and I would like to propose a second array argument be added to > signal handlers registered with pcntl_signal > . The array passes > through kernel-provided signal conte

[PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

Hi Stas and Danack On Sat, Jul 2, 2016 at 4:35 PM, Yasuo Ohgaki wrote: > This proposal cleans up session code by removing hash. > > https://wiki.php.net/rfc/session-id-without-hashing > > I set vote requires 2/3 support. > Please describe the reason why when you against this RFC. Reasons are > im

Re: [PHP-DEV] [RFC][Vote] ReflectionType Improvements

Den 2016-06-30 kl. 23:57, skrev Nikita Popov: On Thu, Jun 30, 2016 at 6:06 PM, Levi Morrison wrote: The RFC for improving ReflectionType[1] is now in voting phase. The voting window is June 30th through July 8th. I have not finished the patch but I'll have it done before the end of voting.

[PHP-DEV] UGLY Benchmark Results for PHP Master 2016-07-04

Results for project PHP master, build date 2016-07-04 06:29:25+03:00 commit: c2b29a5 previous commit:acdafc0 revision date: 2016-07-04 03:20:01+02:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB

Re: [PHP-DEV] [RFC][Vote] Throw Error in Extensions

Le 27/06/2016 17:17, Aaron Piotrowski a écrit : Voting has opened on the RFC to change most conditions in extensions that raise E_ERROR or E_RECOVERABLE_ERROR to throw an instance of Error instead. Hi, At AFUP, we would be +1 on this RFC, as it fits well into the path started with PHP 7.0

Re: [PHP-DEV] Request: Prevention of FPD in Fatal/Parse/Other Errors

Hi Ted, On 30/06/2016 17:17, Ted Phillips wrote: - Include a new ini directive for fpd_prevention, defaulting to On or a string for replacement, like the ever-popular [path] [...] - Automatically register the containing path of PHP_SELF at initialization. This will deal will fatal errors occ