It is nice that this problem is “solved” for this repository. But the real problem still exists. How do you sign, and what is the source for the key to verify the signature with.
So my first stab at that problem would be to make use for the git builtin signing mechanism. Discourse would then need to keep track of the signer of an installed plugin. If that changes it should warn the admin.
This obviously has a lot of holes in it.
Where to get the signer’s keys from? Metadata in plugin.rb and about.json. Keyservers are nice… but quite complicated. Or… meta.discourse.org serves as keyserver, so authors should register their public keys.
Only verify the most recent commit? Probably sufficient, can’t do much about stolen keys
But if a key is stolen, how to check revocation? If meta serves the key, that problem could be solved.
This is great for the admin ui, but what about the plugin installs in a docker container? Save previously accepted singing keys in shared, and add a verification step to the rebuild. Probably a pre-build check to prevent taking the system down and then rejecting the clone; and then a post checkout check just in case somebody messed with the repo in the meantime?
What about old unsigned repos? Big warning that its content cannot be verified. + yes/no/cancel prompt
has responsibilty. The Server Owner should make sure that some Server loads the desired code. Whether that be pointing the blame at GitHub, upstream to their TLD (e.g. .com), or further downstream
But make my work, as admin, easier. I, as plugin developer, want to make your work easier.
Currently upgrading puts absolute trust in the source URI. This troubles me, as it has been shown that the source (github) is not trustworthy, especially not in certain steps on a container rebuild. Warn me, as admin, than there is a change in trust relations.
I, as admin, have vetted every plugin or theme component before I added it. After than, Discourse gives me little to no guidance in vetting. Today I needed to rebuild my container, which will re-clone all plugins. I am pretty much out of control, unless I make an advanced change to setup to pin a release.
This might work for me as a well rested software developer the moment I need to do some maintenance. But those are quite some constraints. Besides making Discourse a great platform for discourse. We also need to make it a technically safe platform for discourse. Compromised plugins can do serious damage. Compromised theme components can do significant damage.
I think this makes great sense. We have SRI for Javascript, MS Authenticode for Windows.
There have been a lot of supply chain attacks on for instance NPM and RubyGems.
The only thing that worries me is that there would be a barrier for people to get their plugin or theme component “accepted”, like how Microsoft Smartscreen prevents users from running less known software from single developers.