Was just curious, as all the above discussions kinda just ended. So I just presumed it was “self code audit”. I personally don’t know any of the programming langs used with obsidian, therefor inspecting the plug-in code doesn’t work for me. 
Just my two-cents on what might be the best balance:
Something simple as using gpg pki might be the “best bang for the buck” concerning the security and effort. Granted I wouldn’t really start this journey until a 1.0 release is closer to being scheduled. Maybe something like the following could work if the devs choose to go down that path.
- Devs create a gpg key pair.
- Plugin authors request a code audit of their plugin “Devs may require a fee for this.” There could be a path for providing a binary plugin, but that would require more effort and more money.
- Once the plugin is vetted, a digest and gpg signature is created. The plugin is packaged “just an example” in that “asar” format and hosted on the devs plugin delivery system." Therefor we have a cryptographically authenticated “trust” plugin.
- The Obsidian comes with the public key that can check signature of the digest to ensure that the plugin has not been modified. Possibly doing random checks through out.
- Provide an option in the community plugins section to allow “vetted” 3rd-party plugins. (Maybe the mobile version of obsidian can provide an option for using the vetted plugins.)
(Honestly, the best option is to keep safe mode on, and have the devs cook in the features natively. Just keep with current “turn off safe-mode” option of prompting the user with a legal narrative about not holding the devs liable for any mishaps unintended or not)