Use case or problem
Obsidian uses GitHub releases as the content of a plugin to install.
Thus, even if you were to inspect the source code present in the repository, the release may contain completely different (potentially malicious) contents.
Proposed solution
If building via GitHub Actions, you have the ability to generate artifact attestations to establish artifact provenance.
This way GitHub creates cryptographically signed attestations that a specific release was created from a certain commit.
This would help everyone who actually tries to vet their community plugins, as you can automatically compare the two given commits, which are guaranteed to be immutable by their hash / commit ID.
Other packaging ecosystems like npm already support SLSA compliant in-toto attestations.
If an attestation exists, the client should verify the signature, and if valid, somehow give the user the ability to see that a valid attestation was found.
The availability of attestation information may increase trust in a certain plugin, as it makes inserting malicious code during the build step hard to stay unnoticed.
Ideally, there is an easy way to see “important” metadata, especially the commit hash, executed workflow file path and probably GitHub Actions run ID and / or link to the run.
Current workaround (optional)
While there are many ways costing more or less effort, the naive solution is to download the new release and vet it in full, or download the new and the currently installed release and look at the diff.
While release artifact can already be more effort to vet for security, for example because they contain compilation / bundling / minification outputs, releases are also not guaranteed to be immutable.
Thus, a sophisticated attacker might add their malicious code into a previous release when releasing a new malicious version, so that it does not appear when diffing on the old release.