Show me an exploit, show me with detailed and technical information, show some sort of evidence.
Both of you are just repeating your claim more forcefully, never adding anything that backs up your claims.
Compiling C to webasm doesn't fix C bugs within the local memory space of webasm? No one has those expectations except people with a bizarre vendetta against a simple and benign technology like webasm.
If one wants to argue against pjmlp (as you and I both do), there are two ways to go: 1) you can say that nobody is making those claims, or 2) you can say that if people are making those claims, the problem is with those people, not WASM.
I choose #2, because it seems plausible to me that VC-backed startup types over-hype WASM. If I was more familiar with the discourse around WASM, I might try to argue #1 if I thought I could demonstrate that over-hyping WASM doesn't really happen. Maybe you could go the burden of proof route, that it's their responsibility to prove that people are over-hyping WASM and take the discussion from there.
But you ... don't seem to be engaging with the argument. You agree that "compiling C to wasm doesn't fix C bugs within the local memory space of wasm", yet you say that "the claim of insecurity is not being backed up by anything" when the claim of insecurity is that compiling C to wasm doesn't fix C bugs within the local memory space of wasm. That's literally what was meant by "internal memory corruption" in pjmlp's very first comment which mentioned the security angle. Again, they're wrong to mention this as a flaw of WASM because making C code resistant against "internal memory corruption" was never a goal of WASM, but that doesn't mean that their "claim of insecurity" is wrong.
To show an example of the kind of exploit pjmlp is talking about, just take any C program with some kind of exploitable buffer overflow, run it in wasmtime or wasmer or whatever, and exploit the buffer overflow. Maybe the buffer overflow lets an attacker write 101 bytes to a 100 byte buffer and therefore flip an "isAdministrator" flag from 0 to 1. You, I and pjmlp all agree that such security issues can exist; WASM doesn't magically protect C code from memory corruption. And that is not a flaw in WASM, which is what your argument should be focusing on.
Insecurity would be escaping the VM it runs in. In a native compiled binary you have infinite permissions and can make system calls. You can't do that in a webasm VM.
Webasm is not insecure because a C program that crashes also crashes in webasm.
You still haven't shown any evidence of escaping the VM or actual insecurity.
If someone is dumping privileged data into a VM that's insecure no matter what, why would you blame webasm?
"Why would you blame WASM" is the right question. As I have said in LITERALLY every single comment so far, blaming WASM instead of the alleged hype people is where pjmlp is wrong. He's not wrong in the assertion that insecure programs may remain insecure when run in the WASM sandbox. But you refuse to listen. This conversation is like talking to a much less polite ChatGPT.
What specific marketing are you talking about? Link what you're referring to.
Ask him to link to what he's referring to.
He posts this stuff in half the webasm threads I see. Like you he never has anything to back it up and you both get very upset at people asking.
This is my last response in this thread. You've displayed a profound inability to think. I can't be part of this anymore.
I replied to you because I thought (and still think) you were wrong and/or misunderstanding what pjmlp was saying.
I can disagree with two people at the same time. I don't see the issue.
It is still worth looking at and is actual information, so I appreciate that.
In order to be useful, your wasm application will likely have to be able to make systems calls, or whatever its equivalent might be on your particular host environment. If you can corrupt internal state, you can control the arguments to these calls. The severity of the issue will depend on what your application is allowed to do: If all it has access to is a some virtual file system, the host will still be safe. But if that virtual file system contains sensitive data, results may nevertheless be catastrophic if, say, it can also request resources over http.