[HN Gopher] Announcing WCGI: WebAssembly and CGI
___________________________________________________________________
Announcing WCGI: WebAssembly and CGI
Author : syrusakbary
Score : 121 points
Date : 2023-04-06 15:03 UTC (7 hours ago)
(HTM) web link (wasmer.io)
(TXT) w3m dump (wasmer.io)
| __MatrixMan__ wrote:
| I don't understand. Why not just compile to machine code and use
| plain old CGI?
| VikingCoder wrote:
| Sandboxing, I believe is the answer. Portability, too, I
| suppose. Maybe a long-lasting archive format for older
| binaries...
| rektide wrote:
| Others have some good reasons to also consider. Also, launching
| new sandboxes in wasm is supposed to be extremely extremely
| extremely cheap.
|
| Where-as launching a cgi-bin executable- even a very small
| libcgi based one-has a significant cost, requires a lot of
| kernel work & context switching.
|
| With WCGI making new "processes" is nearly free & you don't
| have to context switch.
|
| A lot of the excitement around wasm in general is that it could
| potentially enable a communicating-processes model of computing
| that would be inefficient today. Even current "function as a
| service" paradigms tend to retain processes, have warm/cold
| start distinctions. With wasm there is a potential to have
| requests spawn not just their sandbox, but to create whole
| graphs of lightweight sandbox/processes. Sometimes you might
| hear this described as a "Nano-functions" architecture.
| smiletondi wrote:
| Platform independence: WebAssembly allows you to compile code
| once and run it on any platform supporting it, saving time and
| effort when deploying applications across various servers
| compared to dealing with platform-specific binaries.
| jeremyjh wrote:
| Who is deploying the same backend to multiple architectures?
| smiletondi wrote:
| Though many developers may not prioritize deploying the
| same backend across multiple architectures, the platform
| independence offered by WebAssembly and WCGI can still be
| advantageous for migration, development efficiency, and
| keeping up with changing tech trends(serverless, edge
| computing)
| laurencerowe wrote:
| As well as sandboxing there's the potential for better startup
| performance. Wasmtime have described how they can achieve
| microsecond startup times using virtual memory tricks to reset
| and reuse a module isolated between requests.
| https://bytecodealliance.org/articles/wasmtime-10-performanc...
|
| This is faster than forking a process because there are fewer
| operating system resources to manage.
|
| CGI starts a new process rather than forking an existing one
| which makes it unsuitable for use with languages such as Python
| or JS which have slow initialisation times (milliseconds.)
| Wizer is able to snapshot a WebAssembly module to avoid that
| work. So in combination with the fast startup that brings
| initialisation down to microseconds.
|
| Now runtimes are still somewhat slower on WebAssembly than
| native, and much slower for JITed languages since the JIT
| cannot run in WebAssembly. But there are many cases where
| startup time dominates and this will be faster overall for
| cases where you need per request isolation.
| jtms wrote:
| I believe the main selling point is portability and
| flexibility. Anything written in a language that can be
| compiled to wasm can now be turned into a web service.
| smiletondi wrote:
| This is genuinely exciting - the prospect of running Wordpress
| without the usual security concerns is a game-changer. WCGI seems
| like it could really disrupt the server-side development
| landscape. Can't wait to see what other applications will benefit
| from this technology!
| smiletondi wrote:
| Full disclosure, I work at the company behind WCGI, but I truly
| believe this is a groundbreaking development that will have a
| significant impact on the industry.
| la_fayette wrote:
| Full disclosure, I have only minimal understanding of web
| assembly, other than using C functions inside a web browser.
| I run wordpress in a read only docker container, what better
| security could WCGI bring?
| smiletondi wrote:
| Another aspect to consider is portability. WCGI, built on
| open standards like WebAssembly & CGI, allows for easier
| adoption of security improvements/updates across different
| platforms & environments. Definitely worth exploring
| alongside read-only Docker containers!
| syrusakbary wrote:
| Here are the main differences with the Docker strategy:
|
| * If you want it to be usable, you will need to ship it
| with some mechanism that allows running CGI over http (kind
| of Apache or Nginx), so your container would be bigger than
| the Wasmer package
|
| * Regarding security: Docker containers needs to rely on
| hardware virtualization to run securely (via KVM or
| simlar), aside of a virtualization on the systemcall layer
| (which depends on the crun layer that you use)
|
| Because of that, Docker containers will have the downside
| of: being able to run only in one chipset/OS, they will be
| bigger-sized and they would be slower to start up (even if
| you use state of the art for running them, aka Firecracker,
| you still get 250ms vs < 1ms with Wasmer)
| samstave wrote:
| Im going to ask a very ignorant question ;;
|
| Is it possible to spin-up a 'container' or whatever youre
| calling the VM of a site, for each individual user? So if
| you have a high security req on data accessible by
| computers, you spin up an individual container of said
| site that only serves that user, and is destroyed on
| exit... so that whatever the user does cannot affect
| others?
|
| ELI5?
| rtml wrote:
| [dead]
| Kwpolska wrote:
| > you will need to ship it with some mechanism that
| allows running CGI over http (kind of Apache or Nginx)
|
| Is wasmer stable and secure enough to be exposed to abuse
| of the entire Internet?
|
| > your container would be bigger than the Wasmer package
|
| The first Google hit for "docker php nginx" is
| https://hub.docker.com/r/trafex/php-nginx - they claim
| their Docker image is 40 MB compressed, whereas Wasmer
| for amd64 (latest from
| https://github.com/wasmerio/wasmer/releases) is a 80 MB
| tar.gz (unpacks to 300 MB tar). Even with larger images,
| like the `wordpress` image (200 MB), the size is
| neglible.
|
| > Because of that, Docker containers will have the
| downside of: being able to run only in one chipset/OS
|
| You probably don't need to care about architectures other
| than amd64 and arm64. Both are supported by the
| trafex/php-nginx and wordpress Docker images.
|
| > (even if you use state of the art for running them, aka
| Firecracker, you still get 250ms vs < 1ms with Wasmer)
|
| Starting a fresh VM for every request doesn't make sense,
| so this difference wouldn't matter in real life.
| syrusakbary wrote:
| > whereas Wasmer for amd64 is a 80 MB tar.gz
|
| Wasmer ships _everything_ by default, including 3
| compilers (LLVM is the big one!), which adds most of the
| size. However, the wasmer runtime in headless mode
| weights only about 2 megabytes.
|
| Even more, even if you include only one compiler instead
| of 3 (just singlepass) it would be in the order of
| 5-10Mb.
|
| Stay tuned, because if you are in macOS/iOS you will see
| even smaller binary sizes!
| [deleted]
| evntdrvn wrote:
| The amount (and evolution) of acronyms in the WASM space is kinda
| overwhelming so I might be out to lunch...
|
| At the top of the article it says "...compiling them to WASI",
| but is that a semantically/technically correct statement? My
| understanding would be more that it should say something like
| "compiling them to WASI-compliant WASM" or something. Or can you
| actually "compile to WASI"
| capableweb wrote:
| WASI is just WASM outside the browser, it kind of implies what
| you're saying. It's still WASM, just adhering to a specific
| interface.
|
| Like when you say "HTTP API" you don't necessarily need to
| change it to "TCP HTTP API" as it's somewhat implied (although
| maybe a shitty example, as HTTP is starting to appear over more
| things than just TCP as of late)
| cobbal wrote:
| WASI is also WASM inside the browser :), since there's a
| js/wasm conformance of the interface:
| https://www.npmjs.com/package/@wasmer/wasi
| thomasjb wrote:
| This looks good, I'd been thinking about putting my little Python
| program that prints a random line from a textfile onto my Apache
| server for the internet to enjoy, this ought to enable it nicely.
| Where would be best to look for examples?
|
| The idea of exposing Python via a normal cgi script is terrifying
| to me
| chrismorgan wrote:
| > _Consider the challenge of running PHP programs on servers. We
| have two primary options:_
|
| > _1. Wrap the PHP interpreter with a layer that instruments each
| HTTP call_
|
| > _2. Use the existing php-cgi program and simply compile it to
| Wasm_
|
| > _Option 2 is not only faster, but it also enables any web
| application on Wasmer more efficiently._
|
| I'm confused. This seems to be suggesting that php-cgi, which has
| to initialise the PHP environment every time, would be faster
| than the likes of php-fpm, which, well, I understand and
| _presume_ it has significantly less overhead per request, though
| I've never benchmarked it.
|
| I have PHP 5.6 installed on my VPS for one old site, and it takes
| around 27ms to start1 (compared to under 30ms for just plain
| `echo`, as a closer indicator of actual process spawn overhead).
| PHP 8.2 might be faster, but it's still going to be much slower
| than `echo`.
|
| By simply compiling php-cgi to WASM, it will surely be doing all
| that initialisation for every request. Because CGI starts
| everything from scratch for each request, it's inherently less
| efficient. In theory you could coordinate a time to snapshot the
| process/VM/whatever, forking from that point, but that's not CGI
| any more.
|
| All up, what they're claiming is so _completely_ contrary to what
| I would expect (and without any explanation or justification
| whatsoever), _and_ kinda follows the "dust off something old to
| laugh at it again" trope, that I'm honestly having to check that
| it's not the first of April any more (the article is dated the
| 6th).
|
| So as I say, I'm confused. Option 2 seems very clearly slower and
| much less efficient, by the very nature of CGI. _No one_ targets
| CGI (it's been basically dead for... I dunno, close to twenty
| years?), because CGI is considerably worse than the alternatives.
| Can someone enlighten me? Have I missed or misunderstood
| something?
|
| --***--
|
| 1 Measured by running this in zsh and reading the "total" figure
| (across sixteen runs, I got between 2.671 and 3.032 seconds):
| time ( for i in {0..100}; do php56 <<<'<?="."?>'; done )
|
| The comparative echo test uses `echo -n .` and takes one
| thousandth as long.
| jeremyjh wrote:
| To me this seems a little closer to the architecture of AWS
| Lambda than OG CGI, though that is not a perfect analogy either
| since this is in a WASM runtime within their server process,
| rather than a separate process. But the programming interface
| is a handler function you provide with an interface that looks
| like this in Rust:
|
| `fn handler(request: Request) -> Response `
|
| My understanding is the main function is called only once, and
| registers that handler. So `main` is where you'd initialize the
| majority of the environment, and no that is not truly CGI;
| definitely no process is being created for each request, but it
| may be the case that this is more like FastCGI where you have a
| pool of single-threaded runtimes all setup that way that can
| handle requests.
|
| This still seems inefficient compared to a threaded or event
| polling process that can handle multiple requests concurrently
| without having to marshall data back and forth, but I'd think
| it can get closer to that than FastCGI or Lambda do.
| aaronbrethorst wrote:
| "AsseAmbly"?
| dang wrote:
| Fixed. Thanks!
| joncfoo wrote:
| Next thing you know each wasm assembly will need a package format
| to ship assets with and have the app server provide common
| resources to all assemblies, e.g. db connection pools, some
| notion of security, etc.
|
| Replace Wasmer with the a JVM-based app server and WASM
| assemblies with JVM-bytecode. The big difference is the source
| language doesn't matter as long as it's able to be run/replaced
| by WASM bytecode.
|
| We're heading in circles in a lot of ways
| tiffanyh wrote:
| Don't forget, a mail server will be included at some point
| since that always seems inevitable.
| gabereiser wrote:
| I was just going to say, this road leads to OSGi...
| syrusakbary wrote:
| Indeed. The JVM did a lot of things right, however they missed
| three that are now solved with Wasm:
|
| * Completely tied to an ecosystem, and incompatible with
| another (you could not run C programs in the JVM)
|
| * Proprietary (vs based on an open standard)
|
| * They couldn't run in the browser seamlessly
| yazzku wrote:
| Memory usage too, right? A C++/Rust wasm won't consume a
| hundredth of the memory a JVM application typically uses. I
| like getting the job done on a 512MB RAM VPS. JVM the
| language might be cool; the bloat and forced-GC can be
| spared.
| icedchai wrote:
| JVM ran in relatively little memory back in the day. I
| remember running applets on ~16 megabyte systems. Compare
| that to today where you need a half gig of RAM to even
| launch a browser.
| pjmlp wrote:
| Just like a JVM for embedded development won't.
| tubs wrote:
| You can't run c in wasm.
|
| You can compile c to wasm and run that.
|
| In the same way one could compile c to java byte code, write
| a wrapper program to allocate the "heap", disable the gc and
| execute it in close to the same way it executes in a wasm
| runtime.
| michaelmior wrote:
| > you could not run C programs in the JVM
|
| Not entirely true, but of course there has never been any
| official support. http://nestedvm.ibex.org/
| mdellavo wrote:
| It's not an open standard but the JVM spec is publically
| available and intended for multiple implementations
|
| https://docs.oracle.com/javase/specs/jvms/se8/html/
| [deleted]
| 0xbadcafebee wrote:
| I'm still flabbergasted that all these people, in the year
| 2023, think a hypertext markup document viewer with a
| terrible UX and bizarre design restrictions that takes 4GB of
| RAM to run and re-implements the features of an entire
| operating system is the end-all be-all of technology. If it
| doesn't run in a web browser it's worthless.
|
| I can't even come up with a metaphor for it. We're choosing
| to be stuck with shitty antiquated technology because it's
| easier than making something better. It's depressing. Like a
| world that never got past the horse and buggy. Large engines
| powered by steam would require additional investment in
| refining of steel and making giant cast or forged parts...
| easier to just stick with the horse.
| mch82 wrote:
| > Like a world that never got past the horse and buggy
|
| At lunch one day a colleague explained that the size of the
| space shuttle could be linked to the width of two horses
| walking on a Roman road :-)
|
| One of my favorite lunch breaks of all time.
| qup wrote:
| Give us the recap
| mrec wrote:
| http://www.astrodigital.org/space/stshorse.html
|
| I'd be very leery of trusting the specifics too much.
| E.g. the reference to "Roman war chariots", which are not
| a thing the Romans ever used.
|
| Snopes entry: https://www.snopes.com/fact-check/railroad-
| gauge-chariots/
| qup wrote:
| Nice, so dude was actually just reciting an email FWD he
| studied to sound interesting.
|
| God, I had forgotten about those email FWDs. The old
| people I know totally abandoned email.
| reginaldo wrote:
| The browser "won" on seamless distribution. The browser is
| all the things you said and worse. It conflates the
| developer API (which could be as complex as the collective
| human comprehension will allow) with the execution
| environment (which must be as simple as possible and
| understandable to mostly anyone). I have a dream that the
| browser will turn inside out and start losing APIs that
| will be reimplemented on WebAssembly. But WebAssembly is
| moving too slowly e.g. with regards to tail calls and
| parallelism. So it's probably just a dream from now[1].
|
| [1] https://www.youtube.com/watch?v=zlQEQQSqZ9g -> it's an
| old dream that others have had before.
| MR4D wrote:
| Unfortunately, the world is scheduled to end (or reboot if
| you prefer) at 03:14:07 UTC on January 19th, 2038. [0]
|
| So, that means that the remake of an OS that we call a
| browser is likely to be the pinnacle of computing for our
| lifetimes.
|
| Hopefully after the Great Reboot of 2038, the next
| generation will learn from our computing mistakes, but
| since we've never learned from those that came before us,
| it's highly unlikely. But at least they will have to start
| from scratch, so there's a chance!
|
| [0] - https://en.wikipedia.org/wiki/Year_2038_problem
| ThePhysicist wrote:
| Funny that most people seem to have forgotten that browsers
| used to ship with Java support. Not saying that was a good
| thing, but 20 years ago you could run JVM apps in the browser
| without issues. Also, there are dozens of language runtimes
| for the JVM, e.g. Ruby, Python, Golang, Javascript, Scheme,
| .... And regarding proprietary software, Wasmer is a for-
| profit startup that seems to offer open-source tooling with
| the hope the ecosystem will standardize on it and give them
| opportunities to monetize that. So not that much unlike Java
| I'd say.
| throwaway50609 wrote:
| Funny that you forgot about all the security issues of JVM
| applets that Wasm finally solved
| baq wrote:
| And now you can run a wasm jvm:
| https://leaningtech.com/cheerpj/ (there are others, too)
| eyberg wrote:
| Like this one? #include <stdio.h>
| #include <stdlib.h> int main() { char
| *s = "world"; s[0] = 'o'; s[1] =
| 'w'; s[2] = 'n'; s[3] = 'e'; s[4]
| = 'd'; printf("Hello, %s\n", s); }
| throwaway50609 wrote:
| Just compiled and ran it on my system within Wasm, my
| computer is still fine. Your point?
|
| The point of Wasm is - programs can and will malfunction
| (and some will be malicious), so we have to protect the
| environment that runs it.
| [deleted]
| [deleted]
| akira2501 wrote:
| > but 20 years ago you could run JVM apps in the browser
| without issues
|
| That was definitely not my experience at that time using a
| linux desktop.
| pookeh wrote:
| There was a time when JVM ran in the browsers.
| chunk_waffle wrote:
| I recall around 2010 or so, when a company I worked for was
| creating a new, rather ambitions, web application. I had to
| argue against using Java Applets in favor of standard web
| technology for several components. Thankfully I won that
| battle.
|
| That web application is still in use, in production, today.
| syrusakbary wrote:
| Yup, via Java Applets. But they were a pain to use, that's
| why I intentionally wrote "seamlessly" :P
| wwweston wrote:
| As far as I could tell, the big pain point was
| performance -- they were just too slow on median machines
| during the late 90s/early 00s window they had mindshare.
|
| I actually enjoyed using them to get around a few browser
| limitations around the mid-to-late 00s, and they seemed
| feature/performance competitive with Flash unless what
| you were doing fit the media authoring model closely. But
| by then people were skeptical about Java and if you had
| to do anything to get it installed they wouldn't, and the
| direction was native web.
| pjmlp wrote:
| The Java Kernel project sorted that out.
| freeone3000 wrote:
| They were better than Flash (which needed a weirder
| runtime, and couldn't interact easily with the DOM, and
| didn't have _variables_ until version 3). This is hugely
| improved over JavaScript at the time (pre-XHR) and had
| less lock-in than ActiveX.
| ex3ndr wrote:
| GWT allowed to run it without applets, also much more
| efficient than any current stack (since they dont support
| closure compiler)
| switchbak wrote:
| I spent years working with GWT, it's not nearly as simple
| as you describe. It's not running "Java" in the browser,
| it's compiling down (a subset of) Java to Javascript.
|
| That said, GWT was ahead of its time in a lot of ways,
| but it had warts galore.
| pitaj wrote:
| I would also mention that, especially in the past, the JVM
| sandboxing was not great. Which is why Applets were such a
| problem.
| KRAKRISMOTT wrote:
| Not just in the past, arbitrary program sandboxing is not
| possible even today.
| kllrnohj wrote:
| Exactly, yet everyone pretends wasm is the exception for
| some reason...
| pjmlp wrote:
| It is incredible how with so much Java hate, the WASM folks are
| doing their best to replicate everything we had in 2005.
| nu11ptr wrote:
| Honestly, I just think Java was ahead of its time. I hated
| sites with applets because they felt slow to startup and run.
| That problem is long gone with modern computers.
| miohtama wrote:
| We are not replicating Oracle's lawyers, sales agreements and
| non-disclosure policies.
| dianeb wrote:
| Sure, this fits the way software evolves on the circle of
| dumb. It goes something like this: What a great idea!... (a
| little later) Hmmm. That's a problem... (later) We need
| something to run apps in the browser. I wonder if WASM would
| work... (now) What a great idea!...
|
| Software development always goes in cycles. "Apps" were great
| now maybe not so much so...
|
| In the late 80s/early 90s, the CEO of ETA Systems (a
| supercomputer company) had a vision that by 2000, the world
| would be split between supercomputers and workstations. I
| have seen some evidence that people are considerng that once
| again... The Circle of Dumb is always with us in software
| land.
| frou_dh wrote:
| As long as it's refining and making at least some progress
| then it's more of a helix than a circle
| Y_Y wrote:
| I see it as more of a conical spiral, like water going
| down a drain.
| moonchrome wrote:
| Java still doesn't have value types AFAIK. Meanwhile WASM
| started out as no-gc continuous memory VM.
|
| Comparing WASM and JVM is like comparing a truck and a bus
| because they are relatively the same size, move at the same
| speed etc.
|
| I mean sure you can load people in trucks and cargo into
| buses - and both have been done with JVM (eg. people built C
| compilers) and WASM (people are building GCed runtimes on top
| of it despite lack of GC support from platform).
|
| Almost 30 years later nobody sane is running C on JVM and
| there were many attempts posted here over the years.
| pjmlp wrote:
| Nobody sane should be running C, regardless of the target
| platform.
| throwaway12245 wrote:
| You'd have to delete your operating system and most of
| your libraries.
| kllrnohj wrote:
| Outside of the kernel it's a lot more C++ than C
| pjmlp wrote:
| Thankfully not all OS are written in C, and many are
| making efforts to fix that mistake created by UNIX
| release into the industry.
|
| Similarly, many managed compiled languages don't depend
| on C.
|
| Finally, cybersecurity legislation will speed those
| efforts.
| icedchai wrote:
| 2005? Maybe 1996. That's when I ran (and wrote) my first
| applet.
| mc_woods wrote:
| > Next thing you know each wasm assembly will need a package
| format to ship assets with and have the app server provide
| common resources to all assemblies, e.g. db connection pools,
| some notion of security, etc.
|
| You mean in a OCI image, a bit like this? -
| https://docs.docker.com/desktop/wasm/
|
| and then deployed using Kubernetes? - a bit like this -
| https://learn.microsoft.com/en-us/azure/aks/use-wasi-node-po...
| pjmlp wrote:
| Hello Java Servlets.
| paulgb wrote:
| I've always loved the simplicity and flexibility of CGI.
|
| To check my understanding: since CGI just takes a raw request
| over stdin and returns a response over stdout, would a WCGI wasm
| module be compatible with WAGI[1] and vice-versa?
|
| [1] https://github.com/deislabs/wagi
| syrusakbary wrote:
| That's right, both WCGI and WAGI are currently compatible!
|
| Things might evolve a bit different on the mid term, but let's
| see what the future holds :)
| cassepipe wrote:
| To me it has always felt like a underspecified hack but maybe I
| am talking out of ignorance. (I did read the RFC though( I
| think it's strange idea to run to get a bunch of arguments that
| you have to get from the environment and/or the stdin and parse
| the whole of it and then try to programmatically output it all
| by printing to stdout. No wonder people have come up with
| template languages that are html supersets and that work with a
| preprocessor.
|
| I don't use CGI but when I do I like the simplicity of Haserl
| (Basic template language + any interpreter, lua by default) :
| https://haserl.sourceforge.net/
| 0xbadcafebee wrote:
| PHP was compiled into WASM, so now you can run PHP apps "as
| WASM". How is this different from just running PHP, without WASM?
| Apparently it's faster, but also they make this claim:
|
| _" Picture running Wordpress and not having to worry about
| attackers breaking into your system"_
|
| uh, so, you sprinkled some WASM magic on some code and suddenly
| several decades worth of security research is obsolete?
| .....yeah, I'm gonna call bullshit. Compiling code or "running in
| a sandbox" does not stop attackers from breaking into your
| system. Might slow them down for a few months while they develop
| some new attacks.
| kristjansson wrote:
| edit: this was completely wrong, TFA is talking about server
| side WASM
|
| I think the point is that a simple-enough application can be
| delievered as WASM and run entirely in the user's browser, so
| there wouldn't be any server-side system to break into? So one
| could ship e.g. wordpress + db + content in one bundle, and the
| user would be none the wiser. A wild claim, and probably self-
| defeating for anyone who needs to protect their content.
|
| Otherwise, the WASM-dust at best moves the security boundry to
| a different service.
| jeremyjh wrote:
| No, CGI is an interface for backend web servers, this is not
| about client code.
| noahtallen wrote:
| It's already been done!
|
| https://make.wordpress.org/core/2022/09/23/client-side-
| webas...
|
| (By my colleague Adam!)
|
| I think this experiment becomes interesting thinking about
| times you really want WordPress to be headless (like demoing
| a plug-in or theme), but less for serving websites to people.
| Potentially also useful as a testing development environment.
|
| I was surprised at how fast it is, since it basically becomes
| an SPA.
| ThePhysicist wrote:
| I don't think that's what they mean, Wordpress is a server-
| side app with a database backend, I don't think you'd want to
| ship your entire Wordpress database to the browser.
| PoignardAzur wrote:
| Compiling a service to wasm to protect it "from itself" (ie
| from untrusted data) has trade-offs.
|
| On the one hand, you lose ASLR and other security features
| designed for native code. On the other hand, your program
| becomes immune to stack smashing, so arbitrary code execution
| becomes _a lot_ harder for an attacker (at least that 's my
| understanding).
| kllrnohj wrote:
| The fact that the address space starts at 0x0 comboned with
| no ASLR seems like some pretty major regressions in security.
| Nearly all SIGSEGV crashes just became memory corruption
| bugs, for example. That's _huge_.
|
| And of course WASM won't protect from just regular ol logic
| bugs like SQL injection or similar.
|
| Compiling things to WASM to make them "more secure" seems
| bonkers backwards. WASM's priorities are to protect the host,
| not the guest.
| eyberg wrote:
| Does it become harder or easier? #include
| <stdio.h> #include <string.h> int bad(char*
| src) { int admin = 0; char buf[2];
| strcpy(buf, src); printf("%d\n", admin);
| return admin; } int main() { if
| (bad("ADMIN!!!")) { printf("we're admin!\n");
| } else { printf("we are not admin\n"); }
| }
___________________________________________________________________
(page generated 2023-04-06 23:01 UTC)