[PHP-DEV] Re: [RFC][VOTE] Session ID without hashing - Vote reopened and restarted

Hi Christoph, On Tue, Aug 9, 2016 at 12:44 AM, Christoph M. Becker wrote: > > I've just noticed that the voting is still open, although it's already > 2016-08-08. Shouldn't it be closed? Thank you! Closed. -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime

[PHP-DEV] Re: [RFC][VOTE] Session ID without hashing - Vote reopened and restarted

Hi Yasuo! On 25.07.2016 at 11:49, Yasuo Ohgaki wrote: > Due to defects in the RFC, vote is reopened and restarted. > Followings are changes from 1st vote. > > […] > > Vote ends 2016/08/02 23:59:59 UTC. I've just noticed that the voting is still open, although it's already 2016-08-08. Shouldn't

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing - Vote reopened and restarted

Hi all and Davey, On Wed, Aug 3, 2016 at 4:36 PM, Davey Shafik wrote: > > Unfortunately this missed beta2 (tagged yesterday), I'll confirm with Joe > about putting it in for 7.1beta3. > > Thanks for those last minute changes, I'm much happier with this result! :) I just realized,

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing - Vote reopened and restarted

Hey Yasuo, Unfortunately this missed beta2 (tagged yesterday), I'll confirm with Joe about putting it in for 7.1beta3. Thanks for those last minute changes, I'm much happier with this result! :) - Davey On Tue, Aug 2, 2016 at 10:29 PM, Yasuo Ohgaki wrote: > Hi all, > >

[PHP-DEV] Re: [RFC][VOTE] Session ID without hashing - Vote reopened and restarted

Hi all, Session ID without hashing https://wiki.php.net/rfc/session-id-without-hashing#vote This RFC is passed 9 vs 0. Compatible default is used as default. 7 vs 3. It needs to update the default INI. I'll finish it in a few days. Thank you for voting! -- Yasuo Ohgaki yohg...@ohgaki.net On

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

Hi all, Old votes are removed. Everyone already have voted 1st vote should vote again! https://wiki.php.net/rfc/session-id-without-hashing#vote Sorry for the inconvenience & thank you for voting! -- Yasuo Ohgaki yohg...@ohgaki.net On Sun, Jul 24, 2016 at 1:50 PM, Yasuo Ohgaki

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

Hi Yasuo, On Jul 24, 2016 10:51 AM, "Yasuo Ohgaki" wrote: > > Hi all, > > On Sun, Jul 24, 2016 at 6:13 AM, Stanislav Malyshev wrote: > >> Changing the RFC during voting requires a _restart_ not an extension. > >> The vote must be re-run. I will not put

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

Hi all, On Sun, Jul 24, 2016 at 6:13 AM, Stanislav Malyshev wrote: >> Changing the RFC during voting requires a _restart_ not an extension. >> The vote must be re-run. I will not put this in 7.1 without a new vote. > > OK, looks like I was underestimating the magnitude of

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

Hi! > Changing the RFC during voting requires a _restart_ not an extension. > The vote must be re-run. I will not put this in 7.1 without a new vote. OK, looks like I was underestimating the magnitude of the messiness that this change (or lack of it) brought to a vote. Let's re-run the vote

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

Stas, The issue is that changes were made once the voting started, and some of us were waiting for the vote to restart: > I'd like to see the vote re-run (1 week?) with the changes in place. I didn't vote because I expected it to be restarted. I would have voted -1 on the current proposal.

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

Hi! > We already had a vote, at it was completed. Having another vote on the > same subject, slightly modified, is highly irregular and contrary to > voting RFC, which mandates 6 month period or *substantial* changes (with > assumed new discussion period I imagine, since past discussion can't >

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

Hi! > I missed to remove the related lines in RFC. I marked the line by . > I don't mind reopen the vote few days. Any objections? > If no objections, I'll reopen vote few days. We already had a vote, at it was completed. Having another vote on the same subject, slightly modified, is highly

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

Hi Derick, On Tue, Jul 12, 2016 at 7:25 PM, Derick Rethans wrote: > The voted-upon-RFC still has > >> session.use_strict_mode (0 to 1) - Changed as insurance of broken PRNG >> implementation. > > Although you said: > > It was moved to other RFC. > >

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

Hi all and RM, 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 >

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

Hi Davey, On Wed, Jul 13, 2016 at 6:59 AM, Davey Shafik wrote: > On Tue, Jul 12, 2016 at 3:25 AM, Derick Rethans wrote: >> >> Hi, >> >> The voted-upon-RFC still has >> >> > session.use_strict_mode (0 to 1) - Changed as insurance of broken >> > PRNG

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

Hi Derick, On Tue, Jul 12, 2016 at 7:25 PM, Derick Rethans wrote: > Hi, > > The voted-upon-RFC still has > >> session.use_strict_mode (0 to 1) - Changed as insurance of broken PRNG >> implementation. > > Although you said: > > It was moved to other RFC. > >

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

On Tue, Jul 12, 2016 at 3:25 AM, Derick Rethans wrote: > Hi, > > The voted-upon-RFC still has > > > session.use_strict_mode (0 to 1) - Changed as insurance of broken > PRNG implementation. > > Although you said: > > It was moved to other RFC. > >

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

Hi, The voted-upon-RFC still has > session.use_strict_mode (0 to 1) - Changed as insurance of broken PRNG > implementation. Although you said: It was moved to other RFC. https://wiki.php.net/rfc/session-use-strict-mode And neither did you restart voting after modifying

[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

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

On 7 July 2016 at 21:33, Dan Ackroyd wrote: >> I think we need to drop the concerns about exposing "RNG state". >> >> If these are weak RNGs on your system, YOUR SYSTEM is broken. > > Telling people that their system is broken isn't going to be > comforting to the people

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

> > > I think we need to drop the concerns about exposing "RNG state". > > > > If these are weak RNGs on your system, YOUR SYSTEM is broken. > > Telling people that their system is broken isn't going to be > comforting to the people it happens to. > Sure, but it's the right way. Just like

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

Hi Dan, On Fri, Jul 8, 2016 at 5:33 AM, Dan Ackroyd wrote: >> I think we need to drop the concerns about exposing "RNG state". >> >> If these are weak RNGs on your system, YOUR SYSTEM is broken. > > Telling people that their system is broken isn't going to be > comforting

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

Hi Leigh, On Thu, Jul 7, 2016 at 5:25 PM, Leigh wrote: > On 6 July 2016 at 22:30, Yasuo Ohgaki wrote: >> php_session_create_id() may return NULL. It's an usual error. Session >> module supports session ID creation save handler which may return >> anything

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

> I think we need to drop the concerns about exposing "RNG state". > > If these are weak RNGs on your system, YOUR SYSTEM is broken. Telling people that their system is broken isn't going to be comforting to the people it happens to. There are always bugs in software and hardware. At some point

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

On 06.07.2016 at 23:30, Yasuo Ohgaki wrote: > > On Wed, Jul 6, 2016 at 9:10 PM, Christoph Becker wrote: >> >> Yes, I am aware that the patch uses php_random_bytes(), but what happens >> when it fails, in which case php_session_create_id() returns null[1]? >> Would it be

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

On 6 July 2016 at 22:30, Yasuo Ohgaki wrote: > php_session_create_id() may return NULL. It's an usual error. Session > module supports session ID creation save handler which may return > anything valid for the type. > > Session module tries to call php_session_create_id()

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

Hi Christoph, On Wed, Jul 6, 2016 at 9:10 PM, Christoph Becker wrote: > > Yes, I am aware that the patch uses php_random_bytes(), but what happens > when it fails, in which case php_session_create_id() returns null[1]? > Would it be impossible to use a session in this case?

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

On Wed, 6 Jul 2016 at 13:10 Christoph Becker wrote: > > Yes, I am aware that the patch uses php_random_bytes(), but what happens > when it fails, in which case php_session_create_id() returns null[1]? > Would it be impossible to use a session in this case? > > [1] > < >

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

Hi Yasuo! On 06.07.2016 at 03:51, Yasuo Ohgaki wrote: > > On Wed, Jul 6, 2016 at 12:37 AM, Christoph Becker wrote: >> On 05.07.2016 at 16:32, Leigh wrote: >> >>> On 5 July 2016 at 04:02, Pierre Joye wrote: We can argue about the provided pnrng being

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

Hi Christoph, On Wed, Jul 6, 2016 at 12:37 AM, Christoph Becker wrote: > On 05.07.2016 at 16:32, Leigh wrote: > >> On 5 July 2016 at 04:02, Pierre Joye wrote: >>> We can argue about the provided pnrng being CS but it is not php's job to >>> decide. >> >>

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

Hi! > Some of us worried about CSPRNG state exposure. I'm wondering how many > of you will vote in favor if I change the RFC to use hash functions > optionally. This means code and INI settings related to hash function > selection will remain. Please note that ext/hash is not built always. > If

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

Hi! > Some of us worried about CSPRNG state exposure. I'm wondering how many > of you will vote in favor if I change the RFC to use hash functions > optionally. This means code and INI settings related to hash function > selection will remain. Please note that ext/hash is not built always. > If

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

On 7/5/16 11:37 AM, Christoph Becker wrote: On 05.07.2016 at 16:32, Leigh wrote: On 5 July 2016 at 04:02, Pierre Joye wrote: We can argue about the provided pnrng being CS but it is not php's job to decide. I think we need to drop the concerns about exposing "RNG

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

On 05.07.2016 at 16:32, Leigh wrote: > On 5 July 2016 at 04:02, Pierre Joye wrote: >> We can argue about the provided pnrng being CS but it is not php's job to >> decide. > > I think we need to drop the concerns about exposing "RNG state". > > A reminder of what

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

On 5 July 2016 at 04:02, Pierre Joye wrote: > We can argue about the provided pnrng being CS but it is not php's job to > decide. I think we need to drop the concerns about exposing "RNG state". A reminder of what php_random_bytes looks at (in order): * CryptGenRandom on

[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

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

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

[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

[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

[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

[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

[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