Re: Re: Bug 67072 resolution for 5.4/5.5

Hi! > I don't see any problem in the fact that you can skip actual instantiation > of the object. Even if there *is* a problem with that - a lot of user-land The problem is remotely-triggerable DoS and potentially RCE. Not sounding bad enough? > code already uses this trick and it will be a pretty big BC break (as we The mere fact O: works for custom serializer objects is a clear bug. It should have never worked, it was never documented as working and nobody ever promised anybody it would work. It is unfortunate that userland code relies on a bug to be working, but this particular bug is too dangerous to keep in. Yes, BC is important. Not having remotely-triggerable memory corruption is more important. > million times already. Using input data blindly is user's mistake. I think Sorry, you can not bursh it off in this case as "user error". The case where unserializer crashes on wrong data is a bad problem - and there's absolutely no way for the user to filter the data to ensure it does not happen, except for implementing completely custom unserializer. The only way is to completely abandon usage of serialize(). This is not a good solution to propose to people with existing apps. > there are already cases of PHP trying to 'secure' users from themselves > (hello magic quotes). And I think all we have to do is to prevent How magic quotes have anything to do with it? MC failed because it didn't work and was applied in proper place, not because it didn't allow you to trigger crashes and UMRs whenever you'd like. We give people plenty of the rope, but there should be some limit. I think remotely-triggerable crashes go beyond the limit. > possibility of segfault, not the possibility of instantiation of the > object (without calling internal constructor) itself, because skipping > constructor (for whatever type classes - internal or user-land) has its > use cases. I'd like to question this - the whole meaning of ctor is to initialize the object and if you need to routinely skip it the problem is probably elsewhere. But this is a topic for another discussion. > Don't you think that it would be better, instead of preventing creation of > the objects without calling internal constructor, to prevent calling any We're not preventing this right now. We're preventing using serializer for doing this, because it does not work. If there's another way of doing this without causing breakage, then fine, do it. Let's have an RFC about it and discuss it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227