It doesn't?

bool session_regenerate_id ([ bool $delete_old_session = false ] )

Make this to change request :)

Shouldn't this one be closed already?

Unfortunately no.
To delete old session properly, old session data should be deleted after a while. This behavior is under discussion now.

Huh, well ... it was last discussed 4 months ago and the RFC hasn't been updated since.

Patch was there, but there are some objections for lazy destroy. I think there is no objection now.

This bug is related to 
https://bugs.php.net/bug.php?id=69127

Related RFC
https://wiki.php.net/rfc/precise_session_management

Use proper title. Original title meant "no deletion by __default__".
Last RFC is declined, but we _MUST_ fix this issue.

session_regenerate_id() depreciation is a option. We shouldn't keep security related broken function.

session_regenerate_id() was never meant to destroy the session data, that is what unset($_SESSION) is for. Not even session_destroy() will delete the $_SESSION array, which means that it can be reused with the next call to session_start().

It is perfectly legitimate to open a session with one id, thus obtaining the $_SESSION array, then to use session_regenerate_id() to change the session_id() so that it can be saved under the new id. Any scripts still using the previous session_id() will still work. While both sessions start off with copies of the same $_SESSION array, these copies can quickly diverge because they are different copies being accessed with different ids.

It's not about $_SESSION, but old session data stored in session storage.

Anyway, my bug description was incorrect.

bool session_regenerate_id ([ bool $delete_old_session = FALSE ] )

$delete_old_session option deletes session data from the session storage immediately, but it should eventually delete old session data. i.e. It should make old session data inaccessible after a while by keeping track expiration time stamp to avoid and detect hijacked sessions.

Immediate session data deletion will cause race condition that is very hard to debug also. e.g. Few lost sessions with tens of millions requests per day.

Current behavior and design is wrong. I created 2 RFCs to fix this design bug. I shall write 3rd RFC in the future.

Precisely, there are 2 issues;

 1. session_regenerate_id() will not delete/invalidate old data.
 2. session_regenerate_id(true) deletes data immediately.

1. allows attackers to abuse hijacked sessions safely(undetected) and freely(keep it as long as they want).
2. causes race condition that results in lost sessions.

Deleting session data in the file system is what session_destroy() is for.

Use unset($_SESSION) to clear the session data in memory.

Use session_destroy() to clear the session data from the file system.

Both of these operations are completely independent of session_regenerate_id() which should not clear anything. All it is supposed to do is update the current session_id. Other operations should be handled with other function calls.

Those users who think that a single function call combines several operations are simply wrong. By changing this function to automatically include another function will cause problems for those users who do not want that other function called at all.

Tony, you are ignoring the fact that there is $delete_old_session option. It exists for security reasons. 

Please stop insisting irrelevant/unrelated opinion for this bug.

I was referring to your post of [2016-10-17 06:38 UTC] in which you said "session_regenerate_id() depreciation is a option. We shouldn't keep security related broken function" which implied that the function was broken and should be deprecated.

The idea that session_regenerate_id() should do anything other than regenerate the id for the current session is totally wrong as that is handled separately by other functions.

I now notice that you have updated this function to delete the current session data as an option, which is acceptable. The idea that it should do so automatically is what I was objecting to.

Your idea is against OWASP guideline, for example.

Timestamps must be managed and these timestamps must be used for precise session life cycle management. Mandatory requirements are better to be managed as default feature.

Current implementation is simply broken because it removes old session data immediately or hopes removal by GC.

It's better to say "session_regenerate_id() is vulnerable" rather than "it is broken".

mydailyfashionblog My Daily Fashion Blog are sharing latest news about about fashion, shopping, lifestyle, clothing, photography, wedding etc. More info to visit:(https://mydailyfashionblog.com)github.com