31–40 of 52 posts
No outgoing http requests, no ability to connect to an external database such as mysql- only SQLite is used. No explanation for what vulnerabilities standard Drupal is actually being hardened against.
No outgoing http requests, no ability to connect to an external database such as mysql- only SQLite is used. No explanation for what vulnerabilities standard Drupal is actually being hardened against.
Ok, considering that it comes from VMware, I think they aim to create some kind of a multi-architectural execution environment that can host apps in a hardware-independent way on multiple clustered nodes. I applaud this development but at the same time any kind of run-time code translation imposes performance penalties. WASM is not exception. It would be enlightening to hear the authors' stance on this topic. CPU uti…
Earlier quoted context omitted.
> No explanation for what vulnerabilities standard Drupal is actually being hardened against. But... Are you not afraid of these unknown, not-yet-public vulnerabilities that this solution clearly protects us against?!
(Wasm Labs dev :)) For me, this is the key point. The end goal is to limit the attack surface for future vulnerabilities. This is not something specific to Drupal or PHP, but an example about technologies / apps that can take advantage of Wasm.
Having said that, searching Druapl on the CISA know exploited list shows a number of remote code execution vulnerabilities that this would help mitigate: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
I used to work with Drupal, it was a security nightmare, like almost all community-based extension system (see also npm). Modules made Drupal popular, they also made it close to impossible to have any sense of security, as only very popular modules would be audited, and you basically needed a panoply of smaller ones depending on your use case. I wonder if that's changed over time, for instance I could see GPT3.5 doin…
I took a quick look at the examples that come with mod_wasm module: from what I could see, the HTTP/WASM interface is based on CGI. I kind of like it because CGI is architecturally elegant, but what about performance implications? By default, the CGI is not the fastest thing on Earth. Every time a HTTP request arrives, a CGI process should be initialized over and over again wasting CPU time on BSS section / runtime l…
Or better PHP-FPM?
No outgoing http requests, no ability to connect to an external database such as mysql- only SQLite is used. No explanation for what vulnerabilities standard Drupal is actually being hardened against.
We are working on adding all that functionality, explanation here: https://news.ycombinator.com/item?id=36115146
Earlier quoted context omitted.
(Wasm Labs dev :)) For me, this is the key point. The end goal is to limit the attack surface for future vulnerabilities. This is not something specific to Drupal or PHP, but an example about technologies / apps that can take advantage of Wasm.
Don't disagree - but if I have a limited amount of resources to harden my Drupal server, it might be best to start looking at hardening around the most commonly exploited Drupal vulnerabilities. Having said that, searching Druapl on the CISA know exploited list shows a number of remote code execution vulnerabilities that this would help mitigate: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
No outgoing http requests, no ability to connect to an external database such as mysql- only SQLite is used. No explanation for what vulnerabilities standard Drupal is actually being hardened against.
Yeah, would have been nice to have a list of the last dozen or so medium+ Drupal CVEs and if they were mitigated to any degree by this setup.
Earlier quoted context omitted.
So a GraalVM competitor but on WASM. I do want to see the WASM ecosystem grow and thrive, but it will take some time, although what I have seen so far is amazing. I am most excited for WASI. Havent checked up on it in a moment but its basically the WebAssembly version of nodejs but as a spec anyone implementing a WASM runtime can support, so there will be various options to run your code ultimately.
Yes, I agree on WASM versatility, but: when I use my Mac M1 (with ARM64 processor) and try to run a x64 based executable, there is a small but noticeable lag on the app's start. It is caused by the dynamic instruction translation, essentially by JITting x64 code to ARM64 instruction set on the fly. While the lag is small, it is unpleasant enough to make my work less comfortable when compared to the native ARM64 image…
Translating x86_64 code to arm64 requires more CPU cycles than JITting Wasm into arm64 or x86_64.
Buy even more: in the use case covered in this article, the PHP interpreter won't change so it can be AoT compiled upon deployment to the target architecture. No JIT compilation needed :-)