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 thing, as minor performance improvements don't justify changing the ini settings imo. * Slipping in a change to make 'session.use_strict_mode' be enbled by default. I actually agree with this change, but I don't like how it's been combined into an unrelated RFC. * Exposing information that could be useful to an attacker, from the RFC: > If PRNG has vulnerability that generates predictable value, exposing > raw PRNG state helps attackers. Although, this is unlikely with modern PRNGs, > but > risk is there. I don't agree that faster session generation is worth exposing the random number generator in a completely known way to the outside world. Reading an extra 60 bytes almost certainly does nothing to mitigate that exposure. > cryptographers recommends > not to reinvent crypt related functions/features. They also recommend reducing your attack surface as much as possible, not opening it up to the point where you're relying on the CSPRNG to work perfectly to avoid having a security hole. But more importantly, as I wrote before (http://news.php.net/php.internals/90940) I don't think the session extension is in a state where incremental improvements are a good way to proceed: > The problem is that you're trying to build on a foundation of sand. > The session handling works but is incredibly fragile. > To me, there are two good ways to proceed: > i) Develop a new session extension, that doesn't depend on magic > behaviour of globals and leave the current session handler as it is. > The new session extension could be shipped as a 'work in progress' when > it's good enough, before PHP 8. Then when it's stable, we could figure > out how to transition users from the old extension. > > ii) Develop a session handler in userland code only. PHP is powerful > enough to support this. Although obviously there are big benefits to > shipping a session handler with PHP, I don't see any need for it to be > done internally other than we don't currently have a way of shipping > userland code with an extension. I'm hoping that before PHP 8, the > ability to ship PHP code as part of extensions would be in place. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
