Hi! > 2. Improve caller control on unserialization. Change the signature to > public Phar::getMetadata ( mixed $allowed_classes = true ) : mixed, and > invoke the behavior similar to how unserialize itself works. Since all > of this problem stems from the use of untrusted content on the phar:// > stream, we should put into the caller's hands as much control as possible.
This, unfortunately, is only a partial solution. As long as serialization format supports references - and they are likely not going anywhere - it won't be security, it's virtually impossible to secure code that can modify references while object is being unserialized. At least without rewriting whole unserialization code. If somebody undertakes this task, then yes, maybe it can be made secure (not sure even then). For now, unserializing insecure data is insecure, regardless of allowed_classes. Allowed_classes is just a barrier to block most obvious attacks in the wild now, but it does not guarantee safety. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
