chore(plugin): security plugin

[vgarleanu]

I'm happy to see that this project is active, and I'm excited to give it a try.

However, going through the source code, I've noticed that the plugin system is using C ffi and libloading. Are there any plans to migrate the plugin system to wasm or at least sandbox the plugins?

Native un-sandboxed plugins sound like a major hazard for an application like this, especially if plugins will be created by the community.

[tooshel]

Thank you so much! I'm really glad you are pointing this out because it means you really dug in! We have the same concerns which is why the plugins you see now are part of the code base for the app and in fact, we have to include the compiled versions in the signing/certification process for publishing the app. We are still figuring out how to make the marketplace work and concerns like this are why it's still early days. For now the plugins act as a sort of "feature flipper" that allow you to toggle off features that you may or may not want. It allows us to explore what sort of hurdles we need to overcome to add plugin support for the greater community while also sharing our vision of an extensible chat app.

[vgarleanu]

Awesome. I'm glad to hear this is on your guys' watchlist!

One slightly unrelated question, I've noticed that you're passing dioxus objects across the FFI boundary. How did you guys manage to do this when these objects don't repr(C) in the original crate?

[InfamousVague]

I'm happy to see that this project is active, and I'm excited to give it a try.

However, going through the source code, I've noticed that the plugin system is using C ffi and libloading. Are there any plans to migrate the plugin system to wasm or at least sandbox the plugins?

Native un-sandboxed plugins sound like a major hazard for an application like this, especially if plugins will be created by the community.

Just to tack on to this, the plugin system is certainly not in a production state right now and is more of a primer and R&D phase. I totally agree we need to find a balance between performance and security. Wasm can be limiting if you're building certain plugins (Like one to record meetings and compress them to an h.264 with ffmpeg or gstreamer or something).

It also needs to implement a secured proxy of state so that certain values cannot be read or mutated.

It needs more work for sure the first approach is pretty naive for sure!

[sdwoodbury]

Awesome. I'm glad to hear this is on your guys' watchlist!

One slightly unrelated question, I've noticed that you're passing dioxus objects across the FFI boundary. How did you guys manage to do this when these objects don't repr(C) in the original crate?

We force the extensions to be compiled with the same vesion of Rust as the Uplink app.

[dariusc93]

Just to add a little note to this when this is ever targeted in the future:

While uplink does use shared libraries, this does open up some concerns as mentioned above (also made note of this in the previous iteration of uplink). Sandboxing is a option but may come at some form of cost, of which would also need a permission system implemented to grant permission to the system for specific things (eg IO, etc), but I do believe extensions in the future would probably have some form of permission system, so this would likely fit right in. WASM may be a option (and generally preferred due to its actual nature), but may add additional complexity especially given how dioxus work and is changing alot, on top of interaction with anything not compatible with WASM (which may require some form of channel to communicate between the wasm runtime and native code, but may vary on what we wish to expose). Scripting languages might be an option. Ie JS may be a better choice since JS will work within uplink, though might require some additional abstraction depending on the hooks that we may wish to expose, if it can be done in a suitable manner. Furthermore we will want to balance between performance and security and not lean to far on one side at the cost of the other.