> On Sep 20, 2024, at 12:56 AM, Arvids Godjuks <[email protected]> wrote:
>
>
> On Fri, 20 Sept 2024 at 09:17, Dennis Snell <[email protected]
>> wrote:
>
>>
>> Hi Hammed, thank you for taking the time to read through this and share your thoughts.
>>
>>
>>> snip
>>>
>>
>>>
>>> Cheers,
>>> Hammed
>>>
>>>
>>>
>>
>> Hope you have a nice weekend. Cheers.
>>
>>
>>
>
>
> Hello everyone,
>
> I want to chip in here, since reading the thread lead me into a state of cognitive dissonance.
>
Hi Arvīds, that sounds stressful. This is definitely a wavering thread, as noted by the
“tangents” subject. As far as the email you’re replying to, the main point is that if PHP
offered a way to embed safe native-like extensions in a sandbox, then lots of the pressure to add
and maintain extensions would drop from the host and provider and enable the customers to manage
that on their own, and open many doors for PHP. A WASM runtime engine inside PHP would be a viable
path to get to that point.
> I've been in PHP world for a long time, about 3 years shy of how old Wordpress is. When
> I'm reading "shared hosting" and "WASM" and knowing how managed hosting
> works, I have to ask: What type of la-la land is this conversation is taking place in?
> All managed wordpess hosting is locked down hard. Extensions are very limited and everything
> that allows any type of freedom is disabled, functions are disabled en mass. I have to ask: knowing
> the history of past 27 years, what managed hoster in their right mind and sanity will allow WASM to
> be enabled to bypass ____A L L _____ PHP security features and allow PHP code do anything it wants?
> On a shared hosting... I seriously want to know answer to this question, because I firmly believe
> there was zero risk and security assessment not only done, but it hasn't been even a twinkle in
> the eye.
>
These are good questions. The basic point of confusion might stem from what the security domain is
for a WASM runtime. It’s actually precisely because of the concerns you raise that WASM is a
candidate here, being sandboxed by default and unable to interact with the host system.
That is, a WASM extension not only can’t bypass any PHP security features, but it’s
significantly more constrained than any PHP code is. Managed hosts are locked down largely because
of the security concerns that are categorically not present with the system we’re discussing, so
being able to offer more on their platforms without having to dedicate additional resources to it
could be a nice selling point.
>
>
> On VPS/Decicated you can run whatever you want, so you don't have the limitations.
>
I mentioned this in my email; I appreciate that many folks around here have full control over their
infrastructure, but when building platform like WordPress or any of the other PHP frameworks, we
just don’t have the liberty of having that control. In any case, even some very large shops who
write and manage their own PHP extensions are constantly on the hook for security issues and updates
and breakages. I’m sure we’d do much more at Automattic to extend PHP if we could do so without
the security, platform-dependancy, and build issues involved in maintaining custom extensions.
>
>
> On other note - people have pointed out how big body of work it is. If you want to sponsor WASM
> development for PHP, I suggest Automatic open their wallet and put in 2-3 million $ a year for the
> next 5-10 years to PHPFoundation and find devs who are capable and willing to do this job. Honestly,
> I think you might find people to want to do that rather than lack of money being the cause of it.
>
I’m not sure why you’re singling out Automattic, since nobody from Automattic started this
thread or requested other people provide unfunded volunteer work, or why you’re expecting a single
corporate entity to fully fund long-term planned features in the language. Is that how PHP normally
grows? I’m not familiar with the process.
My goal in sharing here is to help better represent my own perspective of WordPress’ needs based
on what I’ve seen. It’s long been on my list to propose a WASM RFC, but because I personally
haven’t had the priority available to get an implementation working I haven’t done so. It’s my
impression from the documentation that the purpose of these email threads w.r.t. RFCs is to gather
interest and input before any RFC would be put together, to hold these discussions before anyone
commits any major time to it.
>
>
> --
>
>
> Arvīds Godjuks+371 26 851 664
> [email protected]
>
> Telegram: @psihius https://t.me/psihius
>
>
>
>
>
Warmly,
Dennis Snell