Re: Resolution for ver_export()/addslashes() encoding based script execution attack?

Hi! > This is incorrect. PHP supports SJIS and others even in engine. I am not sure what kind of support you're referring to, what support the engine has for SJIS? Do you mean input filters? Those are just to read script code, AFAIK, aren't they? I think we need to face the fact that the scenario you are proposing is at least perceived as a rare case which is encountered in rare environment and is enabled by a shoddy code. Thus, proposing global-level engine changes for it are unlikely to gain consensus. Looking at the RFC, it makes claims of addslashes etc. being insecure, and other functions being insecure and unreliable, without giving proper examples and explanations of the context. I have a feeling that once people learn the context, they feel the claims in the RFC are overreaching and the solution proposed makes too many changes for the case that is perceived as too rare and need sloppy coding to enable. I would suggest to go back to the use case here and consider this: 1. Do we have a use case that is hard to handle in user's code? 2. What exactly makes it hard to handle - which capabilities for the user are missing? Is it access to certain information, certain algorithms, lack of knowledge? 3. What is the minimal set of actions we'd have to take to make it easier? What is the set of actions that would cover 80% of user's needs? I think once we have that, we have better chance at arriving at some resolution that would be more acceptable. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227