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,
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,
>
>
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
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
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
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.
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
>
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
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.
>
>
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
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.
>
>
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.
>
>
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
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
>
> > 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
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
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
> 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
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
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()
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?
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]
> <
>
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
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.
>>
>>
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
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
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
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 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
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
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
31 matches
Mail list logo