Hi! > https://bugs.php.net/bug.php?id=75006 has been marked as a non-security > bug, with the justification that unserialize() should not be fed untrusted > input. While we do document that unserialize() shouldn't be used on > untrusted input, we have always treated these as security bugs in the past.
Not always, but sometimes we did. I think we should stop doing it, as to not validate the idea that unserialize can safely be used with untrusted data (it can't, and it doesn't look likely that it ever will be, at least not without comprehensive rewrite and possibly removing references support, which is not likely to happen). If anybody strongly feels that this is wrong, we can make an RFC about it, but given the current state of unserialize(), I can not say we can support such usage scenario in the current state of unserialize() code, and would like to hear arguments to the contrary. If somebody wants to do something about it, please feel welcome, we have a number of open unserialize bugs right now (if you want to work on them and don't have access to private bugs and you believe you should - please ask on security@ list). -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
