Hi! I like the idea of having such an agile API in the language. But I am, like many others, somewhat worried about security implication of this extension.
In theory, it does not give the attacker anything they don't already have - if you have PHP code access, you can probably execute anything on the server under PHP user, given enough work, regardless of the settings, more or less. In practice, however, "enough work" can be a very different thing - a difference between having to be a rather skilled low-level programmer with code exploitation background to find specific venues to circumvent PHP engine, and direct highlighted easy-to-use highway to accessing arbitrary memory and running arbitrary code. Again, it's not a security issue per se, especially given the default of ffi.enable=preload, but what if we have a bug that somehow allows to circumvent those? If this extension were not enabled by default and required explicit enabling action to build - that's fine, if you did it, we assume you know what you're doing enough to assume the risk. But if it's present and enabled by default in a common PHP build, I am concerned that we're creating a small stepstone making PHP systems easier to exploit. Again, it's not a security issue per se, and there are layers of that should prevent any problem - but that's the thing, security works in layers, and FFI would make it one layer weaker. If we said default build has it not compiled in (and would recommend distros to also ship it as a separate extension, requiring explicit action to install) then I'd be fully confident to vote yes for it. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
