[RFC] [VOTE] FFI - Foreign Function Interface

Am Do., 20. Dez. 2018, 16:13 hat Dmitry Stogov <dmitry@zend.com> geschrieben:

As the other one, lagging hugely behind, I'll refrain my vote. Regards, Mike

On Thu, Dec 20, 2018 at 4:13 PM Dmitry Stogov <dmitry@zend.com> wrote:

My main concern here is that this is a very new extension and I think that apart from you barely anyone had a chance to actually implement something based on it and gain experience using the proposed API. Bundling an extension with PHP means that the API becomes frozen in time and it becomes very hard to change anything. I think that having FFI support is important, but I'm afraid that once we bundle this extension and it will see more usage, it will quickly turn out that the API needs to change to make it easier to use or accommodate more use-cases. My other concern is platform support. FFI is by nature a rather platform dependent. The RFC says that the extension is currently tested on Linux and Windows. It would be great if someone using such a system can confirm whether it also works on OSX and FreeBSD, so we at least have coverage of the major platforms. Nikita

Dmitry Stogov wrote:

Hi Dmitry, Reading Sara's concern about it being dangerous made me decide to vote against this. I do think it's a useful thing to have, but if it just lives in PECL then it ia less of a risk. As Nikita points out, it's also quite a young thing and I wonder if now is the right moment to add it to PHP. I can see myself using the extension myself though. :) Thanks, Andrea

Is sad to see people voting against this feature, which would help move PHP into territories outside of the web development landscape. For those developers not interested in learning the zend engine (lack of time) but with enough knowledge about C, this extension would surely help a lot when in need of writing a php cli application that needs access to some C library. This would further help move PHP into the general purpose scripting language arena which is currently dominated by Python and others. And I know many people have this mindset of "use the right tool for the job" but, actually a programming language is already a set of tools, so why buy a fully brand new tool set when you can clearly extend the existing one by adding the missing pieces. Can people explain why they are voting no to a feature that seems really well put and thought? Without disrespecting anyone but, in my opinion seems to me like a lack of vision. I think that shipping this extension as part of the 7.4 release would be an opportunity for people to easily test it before the JIT/8.0 milestone is reached, giving people with time the opportunity to start writing stuff that then would be optimized(more practical) when JIT/8.0 lands, heck, this implementation is even faster than Python one and you can still find lots of stuff on the Python world that uses FFI... I just hope such a feature which is a core part of most scripting languages is not kept as just an optional and forgotten pecl option.

Hi, I agree with the comments about safety here however I still vote yes. FFI and Jit integration will be a critical part of php in a near future. As I have seen in the past, it is extremely time consuming to maintain such implementation outside the core, especially if performance and tight integration are required. That's why I prefer to give this project more chances to succeed. best Pierre On Thu, Dec 20, 2018, 10:13 PM Dmitry Stogov <dmitry@zend.com wrote:

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.