[RFC] [VOTE] FFI - Foreign Function Interface

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

Hi internals,

The FFI RFC is turned into voting state.

https://wiki.php.net/rfc/ffi
...

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

Regards,
Mike

Hi internals,

The FFI RFC is turned into voting state.

https://wiki.php.net/rfc/ffi

There were very few minor changes since the initial proposal, e.g.
renaming FFI:array_type() into FFI::arrayType()

Thanks. Dmitry.

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 internals,

The FFI RFC is turned into voting state.

https://wiki.php.net/rfc/ffi

There were very few minor changes since the initial proposal, e.g. renaming FFI:array_type() into FFI::arrayType()

Thanks. Dmitry.

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

Hi internals,

The FFI RFC is turned into voting state.

https://wiki.php.net/rfc/ffi

There were very few minor changes since the initial proposal, e.g.
renaming FFI:array_type() into FFI::arrayType()

Thanks. Dmitry.

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
smalyshev@gmail.com