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
Maar maak mijn werk als beheerder gemakkelijker. Ik, als plugin-ontwikkelaar, wil uw werk gemakkelijker maken.
Momenteel vertrouwt de upgrade absoluut op de bron-URI. Dit baart me zorgen, aangezien is aangetoond dat de bron (github) niet betrouwbaar is, vooral niet in bepaalde stappen van een container-rebuild. Waarschuw mij, als beheerder, dat er een verandering is in vertrouwensrelaties.
Ik, als beheerder, heb elk plugin- of themaonderdeel gecontroleerd voordat ik het heb toegevoegd. Daarna geeft Discourse mij weinig tot geen begeleiding bij het controleren. Vandaag moest ik mijn container opnieuw opbouwen, wat alle plugins opnieuw zal klonen. Ik heb vrijwel geen controle, tenzij ik een geavanceerde wijziging aanbreng in de setup om een release vast te pinnen.
Dit werkt misschien voor mij als een goed uitgeruste softwareontwikkelaar op het moment dat ik onderhoud moet plegen. Maar dat zijn nogal wat beperkingen. Naast het maken van Discourse een geweldig platform voor discussie. We moeten het ook een technisch veilig platform maken voor discussie. Gecompromitteerde plugins kunnen ernstige schade aanrichten. Gecompromitteerde themaonderdelen kunnen aanzienlijke schade aanrichten.
Ik vind dit erg logisch. We hebben SRI voor Javascript, MS Authenticode voor Windows.
Er zijn veel supply chain attacks geweest op bijvoorbeeld NPM en RubyGems.
Het enige waar ik me zorgen over maak, is dat er een drempel zou zijn voor mensen om hun plugin of thema-component “geaccepteerd” te krijgen, zoals hoe Microsoft Smartscreen gebruikers ervan weerhoudt minder bekende software van individuele ontwikkelaars uit te voeren.