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, php.ini-develop
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,
>
> Session ID without hash
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 this in 7.1 without a new vote.
> >
> > OK,
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 the messiness that
> thi
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
then,
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.
Chang
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
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 irreg
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.
>
> https://wiki.php.net/rfc/s
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 implementation.
>>
>> Although you said:
>>
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.
>
> https://wiki.php.n
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.
>
> https://wiki.php.net/rfc/sessi
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 t
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 it happens to.
Of course
>
> > 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 random_b
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 to the people it happens
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 valid for the type.
>>
>> Session module
> 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 i
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 impossible to use a session
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() several
> places/times. I
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?
php_session_create_id
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]
> <
> https://github.com/php/php
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 CS but it is not php's job to
decide
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.
>>
>> I think we need to drop the concerns abou
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 yo
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 yo
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 state".
A reminder of what
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 php_random_bytes looks at (in or
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 Windows
* arc4random_buf
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
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
31 matches
Mail list logo
