At this point the community’s small and friendly, so I assume people are pretty trusting when downloading new versions of plugins.
That being said, a stolen github account or rogue plugin developer could cause a lot of damage by releasing malicious code. Hopefully with obsidian growing in popularity it doesn’t eventually get targeted
How do reproducible builds help?
Right now any main.js file can be uploaded to github when releasing a plugin update.
A reproducible build would make it easier to verify that this built/minified main.js was actually generated from the source code. You could build it yourself from source and compare the file contents.
By knowing main.js was generated from source you can confidently review the new version’s git diff to make sure it’s safe. A tool could maybe even be created to automate verifying the build and highlight potentially risky changes (like changes to package.json or the build script)
What could reproducible builds look like?
There’d have to be some encouraged conventions, like that running npm run setup or setup.sh will install all dependencies and build the plugin, whether it be with npm, yarn, pnpm, webpack, rollup, etc.
I think that’s a great idea for any kind of extension or plugin!
For example browser extension builds need to be reproducible and Mozilla is particularly picky about it during their review process!
It’s probably a good idea to have a single package file as the build result - something Obsidian is currently not doing.
In a zip archive, the date is part of the checksum tho, so when reproducing a build, it must be possible to specify the SOURCE_DATE_EPOCH (see: SOURCE_DATE_EPOCH — reproducible-builds.org)
When working on browser extensions, I’ve bundled the SOURCE_DATE_EPOCH also in the zip, so when you want to build the project again, you’d do something like:
SOURCE_DATE_EPOCH=$(cat ../previous-build/SOURCE_DATE_EPOCH) npm run build
And the official release zip package should be identical to the rebuild, and even the checksum of the two zip files would be identical.
It’s then easy for the user to just diff the zip file hash instead of individual files in the build.