Hi!
> The Horde_SessionHandler test suite still fail differently: Both
> are related to "getSessionIDs" (which list active sessions)
Any way to get a short repro script for that too?
In general, I start to be more and more doubtful about the idea of
messing with sessions in stable versions.
--
Hi Remi,
On Wed, Jan 27, 2016 at 3:32 PM, Remi Collet wrote:
>
> There were 2 failures:
>
> 1) Horde_SessionHandler_Storage_BuiltinTest::testGc
> Failed asserting that two arrays are equal.
> - --- Expected
> +++ Actual
> @@ @@
> Array (
> +0 => 'db620868d98d974c1193d14c3ad7bb35'
> )
This
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 27/01/2016 06:45, Stanislav Malyshev a écrit :
> Yes, this patch:
> https://gist.github.com/smalyshev/4d8435b7993bef80c0ed fixes it for
> me. Remi, could you check that it also fixes the failures in the
> test suites?
I confirm it fix the unit test
Hi Stas,
On Wed, Jan 27, 2016 at 2:45 PM, Stanislav Malyshev wrote:
>> Note for this issue.
>> The change does not breaks normal codes as PHP cannot set new session
>> ID when header is already sent. The session is _not_ accessible
>> anyway. Not writing orphaned session does not matter at all.
>
Hi!
> Note for this issue.
> The change does not breaks normal codes as PHP cannot set new session
> ID when header is already sent. The session is _not_ accessible
> anyway. Not writing orphaned session does not matter at all.
So it looks like this particular breakage is because write does not
h
Hi all,
On Wed, Jan 27, 2016 at 12:28 PM, Yasuo Ohgaki wrote:
>> Note for this issue.
>> The change does not breaks normal codes as PHP cannot set new session
>> ID when header is already sent. The session is _not_ accessible
>> anyway. Not writing orphaned session does not matter at all.
>>
>> I
Hi all,
On Wed, Jan 27, 2016 at 12:19 PM, Yasuo Ohgaki wrote:
>
> On Wed, Jan 27, 2016 at 11:04 AM, Stanislav Malyshev
> wrote:
>>
It seems that using a user land SessionHandler, the "write" method
is not called, raising this issue.
>>>
>>> Attached as .phpt
>>
>> Bisecting with this t
Hi all,
On Wed, Jan 27, 2016 at 11:04 AM, Stanislav Malyshev
wrote:
>
>>> It seems that using a user land SessionHandler, the "write" method
>>> is not called, raising this issue.
>>
>> Attached as .phpt
>
> Bisecting with this test shows a15e9ccba8a34553c029fb4574edba87c76447e5
> as the breaking
Hi!
On Wed, Jan 27, 2016 at 11:02 AM, Yasuo Ohgaki wrote:
>
> There are 2 ways to keep/generate stolen session
>
> - Set undeletable cookie to browser
> - Get active session via exploit and access it before GC
>
> As I have already explained, getting active session ID is trivial with
> access t
Hi!
>> It seems that using a user land SessionHandler, the "write" method
>> is not called, raising this issue.
>
> Attached as .phpt
Bisecting with this test shows a15e9ccba8a34553c029fb4574edba87c76447e5
as the breaking change. So we need to either fix it (this week, as next
week it should be
Hi Stas,
On Wed, Jan 27, 2016 at 10:25 AM, Stanislav Malyshev
wrote:
>
>> Other than HTTPS, setting unremovable cookies is easy with JavaScript
>> vulnerability. Currently, we only has session.use_strict_mode=1. This
>> is not good enough because attacker can generate valid session ID by
>
> That
On Tue, Jan 26, 2016 at 7:54 PM, Levi Morrison wrote:
> I personally consider the new changes with fractional and scientific
> notation strings and integer operators to be the more important
> change. Thanks to everyone who identified and fixed this
> inconsistency.
>
Seconded, thanks all!
> D
Hi Stas,
On Wed, Jan 27, 2016 at 10:22 AM, Stanislav Malyshev
wrote:
>
>> Oops, sorry. Too many lines to reply, I misread
>> session_id()/session_create_id()
>>
>> session_id() sets session ID. Invalid char that cannot be accepted should be
>> rejected. Otherwise, user will have lost sessions wi
Hi!
> Other than HTTPS, setting unremovable cookies is easy with JavaScript
> vulnerability. Currently, we only has session.use_strict_mode=1. This
> is not good enough because attacker can generate valid session ID by
That sound unlikely, given how much space needs to be searched. By the
same ve
Hi!
> Oops, sorry. Too many lines to reply, I misread
> session_id()/session_create_id()
>
> session_id() sets session ID. Invalid char that cannot be accepted should be
> rejected. Otherwise, user will have lost sessions without errors.
As far as I know, handlers already reject characters that
Hi Stas,
On Wed, Jan 27, 2016 at 9:16 AM, Stanislav Malyshev wrote:
>>> About, since session_id() is a user function, what do we gain by
>>> limiting what it does?
>>
>> Prefix is a part of session ID and it should have the same requirement
>> as session ID for security reasons.
>
> I'm not sure
Hi Stas,
On Wed, Jan 27, 2016 at 9:12 AM, Stanislav Malyshev wrote:
>
>
>> CREATED is used to determine if the session should be renewed.
>> i.e. session_regenerate_id()
>
> This looks like something that belongs in userspace.
As my PHP like pseudo code illustrates, this could be done by user
sc
I personally consider the new changes with fractional and scientific
notation strings and integer operators to be the more important
change. Thanks to everyone who identified and fixed this
inconsistency.
Does anyone have any good ideas on how to prevent strtol and strtod
from being re-introduced
Hi Stas,
On Wed, Jan 27, 2016 at 8:49 AM, Stanislav Malyshev wrote:
>
>> I have
>> https://wiki.php.net/rfc/dbc2
>
> This doesn't seem to do anything with security. It's just a way of doing
> asserts, which we already have.
It's a framework for secure programming.
Using it is up to users, but Db
Hi!
>> About, since session_id() is a user function, what do we gain by
>> limiting what it does?
>
> Prefix is a part of session ID and it should have the same requirement
> as session ID for security reasons.
I'm not sure why you're talking about prefix. I thought that the issue
was that user
Hi!
> There hasn’t been any discussion on this for a while. Just to to be
> sure it didn’t just got forgotten due to the CoC discussion, let me
> remind you of it ;)
I think it looks fine, not much to discuss :) It looks like /e should be
phased out here just as we did in other places.
--
Stas
Hi!
> CREATED is used to determine if the session should be renewed.
> i.e. session_regenerate_id()
This looks like something that belongs in userspace.
> UPDATED is used to determine if the session is expired or not.
> "UPDATED+ttl < now" is expired.
We already have GC mechanism that does that
Hi!
> I have
> https://wiki.php.net/rfc/dbc2
This doesn't seem to do anything with security. It's just a way of doing
asserts, which we already have.
> https://wiki.php.net/rfc/secure_serialization
This may be a viable extension of somebody really is going to use it. I
would suggest making a PE
> On 04 Jan 2016, at 17:46, Rouven Weßling wrote:
>
> I’d like to propose the following RFC to you
> https://wiki.php.net/rfc/deprecate_mb_ereg_replace_eval_option
There hasn’t been any discussion on this for a while. Just to to be sure it
didn’t just got forgotten due to the CoC discussion,
Hi Dan,
On Wed, Jan 27, 2016 at 12:05 AM, Dan Ackroyd wrote:
>> I'll appreciate if one could find defect if there is.
>
> The problem is that you're trying to build on a foundation of sand.
> The session handling works but is incredibly fragile.
>
> Or to put it more colloquially this is a "how t
...I proof-read my email, but I forgot the most important thing. The link!
https://wiki.php.net/rfc/invalid_strings_in_arithmetic
Sorry.
Andrea Faulds wrote:
Good evening,
I had opened the vote for this RFC, but then I was reminded by a
discussion in the pull request about a particular unreso
Good evening,
I had opened the vote for this RFC, but then I was reminded by a
discussion in the pull request about a particular unresolved problem I
had forgotten about.
In order to deal with that issue, I have cancelled the vote and expanded
the RFC (both in length and scope) to deal with
>
>
> > This is added because when session cannot be started, then it should
> fail.
> > This fix is related to https://bugs.php.net/bug.php?id=71243
> > The php_session_abort() is not directly related to this bug, but this
> (and
> > other fixes) is added because session_start() returns TRUE even
Results for project PHP master, build date 2016-01-26 06:29:59+02:00
commit: 7159f16
previous commit:319e828
revision date: 2016-01-25 17:20:05+00:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
On 26 January 2016 at 12:17, Yasuo Ohgaki wrote:
> I'll appreciate if one could find defect if there is.
The problem is that you're trying to build on a foundation of sand.
The session handling works but is incredibly fragile.
Or to put it more colloquially this is a "how to get to Dublin
probl
Hello all,
This concerns the RFC on generics. It isn't an extension to the proposal,
a sale or anything, just hypothetical, it only regards a technicality about
its implementation of syntax.
The issue is the T_SR >> for nested type arguments. I understand the
reason this is difficult, and I kno
Hi Stas,
On Tue, Jan 26, 2016 at 7:28 PM, Yasuo Ohgaki wrote:
> I've already have/will have 3 RFC for session.
> This one, session_id() and user space serialize handler.
> https://github.com/php/php-src/pull/1732
> I would like not to have too many RFCs for session.
I would like to make PHP more
On Jan 26, 2016 5:50 PM, "Julien Pauli" wrote:
>
> On Tue, Jan 26, 2016 at 5:15 AM, Yasuo Ohgaki wrote:
> > Hi Umberto,
> >
> > On Fri, Jan 22, 2016 at 9:49 PM, Umberto Salsi
wrote:
> >> thank you very much for the reply, I now start understanding better
what
> >> happen and why currently i/o ca
On Jan 26, 2016 4:02 AM, "Yasuo Ohgaki" wrote:
>
> Hi Remi and all,
>
> On Fri, Jan 22, 2016 at 1:20 AM, Remi Collet
wrote:
> > Fedora detected a BC break in 5.6.18RC1 and 7.0.3RC1 related to
> > session management.
> >
> > This update breaks:
> >
> > Horde_SessionHandler (2.2.6) and symfony (2.7
On Tue, Jan 26, 2016 at 5:15 AM, Yasuo Ohgaki wrote:
> Hi Umberto,
>
> On Fri, Jan 22, 2016 at 9:49 PM, Umberto Salsi wrote:
>> thank you very much for the reply, I now start understanding better what
>> happen and why currently i/o cannot be handled in user's space.
>
> You're welcome.
> I think
Hi Stas,
TL;DR; for others.
Those who have no idea why this RFC is mandatory and how current
session management is broken, please read the RFC's TL;DR;.
On Tue, Jan 26, 2016 at 5:01 PM, Stanislav Malyshev wrote:
>> https://wiki.php.net/rfc/precise_session_management
>> https://github.com/php/php
Hi Stas,
On Tue, Jan 26, 2016 at 5:15 PM, Stanislav Malyshev wrote:
>> Since this RFC is about preciseness of session management, I would like to
>> change session_id() validates against default allowed chars as follows.
>> (As well as enabling already written session_create_id() function)
>> Thi
Hi!
> Since this RFC is about preciseness of session management, I would like to
> change session_id() validates against default allowed chars as follows.
> (As well as enabling already written session_create_id() function)
> This patch is against the PR.
I would strongly advise not to add more t
Hi!
> https://wiki.php.net/rfc/precise_session_management
> https://github.com/php/php-src/pull/1734
I'm re-reading this RFC and I notice it does quite a lot of things:
- Add five new INI values
- Add two new functions
- Changes behavior of two widely used functions
- Changes four different defau
39 matches
Mail list logo
