Hi! > Yeah, well, the people who do that are also the ones that are unlikely > to make use of the new parameters to secure themselves. In order to make
Why? Making use of one parameter is orders of magnitude easier than refactoring your whole application to not use serialize() (especially if you need object support). > exactly replicating the structure. Using the latter format for the > former task is in any case a bad idea. It's not like unserializing You completely ignore situations where two could mix - i.e. where you could store data that can potentially be not reproducible by JSON and still may - due to some or other oversight - be controlled by the user. That's why security has layers - so that if you make mistake on one layer, other layer would limit the exposure. That's why you don't run you webserver as root - even though you could just say "we shouldn't have remote execution holes, so it doesn't matter under which user the webserver runs". You seem to be under impression that if particular technique solves particular problem, there shouldn't be any security measures protecting you if you do not use that technique. I think it is plain wrong approach to security. > doesn't it? Then let's remember those various serialization bugs that > were recently fixed in DateTime (or the related classes, didn't really > look at it). And then we would have a potentially exploitable > segmentation fault :) I don't see how this has anything to do with anything. There are tons of different bugs, and I never claimed this patch protects against all of them, so if you think somehow finding a scenario that this change does not protect from invalidates it, then by the same logic we should never have any security features at all that do not make the application perfectly secure in the hands of most ignorant user. The point is not to make perfect protection, the point is to make common scenario safer and more resistant to common attacks that happen to existing applications all the time now. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
