Using Wasm for plugins, so that security is better

[gedw99]

https://github.com/hashicorp/go-plugin spawns a separate process for each plugin, and talks to it over RPC. It's very robust and secure in that each plugin runs in a different process.

But it definitely does not stop a plugin doing weird things to your computer.
We could use WASM to run all plugins and so make it much more secure.
https://github.com/knqyf263/go-plugin

https://github.com/knqyf263/go-plugin/network/dependents is worth looking at at this is used by K8 and others to do the same aspect.

This IMHO provides a robust security story as we have Process Isolation ( thanks to just running the Plugins in their own Process group ), as well as Networks and File system isolation ( thanks to WASM ).

No security system is 100% secure. It's all about tradeoffs and risk analysis.

[gedw99]

There is a bug at the moment due to the Tiyngo version update breaking things.

ONLY with tinygo version 0.32.0

tinygo version
tinygo version 0.32.0 darwin/arm64 (using go version go1.22.6 and LLVM version 18.1.2)

Looks like it will be fixed:

knqyf263/go-plugin#64

[julien040]

Hi @gedw99, thank you for the suggestion.
I have a limited knowledge of WASM, but I'm afraid using WASM-based plugins would come with several cons compared to the security pros.

First, I'm not really sure you can use CGO with TinyGo/Wasm. Currently, no plugins are using CGO but that might change in the future (e.g. fetching Reminders using macOS native interfaces). Secondly, I wonder if there would be a performance impact compared to native Go.

However, I understand the security advantages. Restricting file system and network access is great. Currently, to circumvent these issues, any plugin published has its code reviewed. And to prevent supply-chain attacks, I plan to use Go reproducible builds.

[gedw99]

Hey,

I did a search to see if CGO is deal breaker. I have used Wazero but not that much.

https://github.com/klippa-app/go-pdfium is a wazero ( wasm ) based system that uses CGO.

There are other examples listed here: https://github.com/tetratelabs/wazero/blob/main/site/content/community/users.md

[gedw99]

Btw you can use stdio to interact with the plugins , which can be easier and more flexible., faster.

the plugins can then be in any language because every language supports stdio.

wazero can do the same for them as WASM.

so the plugins can be native or WASM with zero changes to the plugins api.

this means you don’t need rpc layer etc.

you can replace rpc layer with a more capable one then like nats Jetstream.

Golang has fantastic support for doing this and even doing it across networks, with no changes at all , by using nats , which can do in process or out of process or to server or cluster or global super cluster . Zero changes to the anywhere setup.

If your curious let me know ..

[julien040]

Thank you for the write-up.

If one day I'm rewriting the RPC package with a new interface, I'll definitely consider WASM as an alternative and safer mode. In the meantime, I'll stick to the current RPC implementation because that would be a lot of work to refactor the whole thing.

[gedw99]

True it’s a lot of work.

it’s easy for me to just add plugins that have wazero inside. Then it will work fine with existing doc system . It’s a decent compromise.

[gedw99]

Conduit has both builtin processors and WASM processors.

you could easily reuse its plugin system.

ConduitIO/conduit#1614 (comment) explains it well..

[julien040]

I like the idea of both regular RPC plugins and WASM plugins for additional security, so that the user can choose between advanced security and native OS features with regular plugins.

I'll consider it for the 1.0.0 release, but don't expect it in the near future. I'm currently entering my last year of undergraduate studies, and I might have less time to work on Anyquery. Therefore, I'll prioritize integrations, fixes, and minor features.