C’est bien que ce problème soit « résolu » pour ce dépôt. Mais le vrai problème existe toujours. Comment signer, et quelle est la source de la clé pour vérifier la signature.
Ma première tentative pour résoudre ce problème serait donc d’utiliser le mécanisme de signature intégré de Git. Discourse devrait alors suivre le signataire d’un plugin installé. Si cela change, il devrait avertir l’administrateur.
Cela a évidemment beaucoup de lacunes.
Où obtenir les clés du signataire ? Métadonnées dans plugin.rb et about.json. Les serveurs de clés sont bien… mais assez compliqués. Ou… meta.discourse.org sert de serveur de clés, donc les auteurs devraient enregistrer leurs clés publiques.
Vérifier uniquement le commit le plus récent ? Probablement suffisant, on ne peut pas faire grand-chose contre les clés volées.
Mais si une clé est volée, comment vérifier sa révocation ? Si meta sert la clé, ce problème pourrait être résolu.
C’est génial pour l’interface d’administration, mais qu’en est-il des installations de plugins dans un conteneur Docker ? Enregistrer les clés de signature précédemment acceptées dans un partage, et ajouter une étape de vérification à la reconstruction. Probablement une vérification préalable à la construction pour éviter de mettre le système hors service, puis le rejeter ; et ensuite une vérification après le checkout au cas où quelqu’un aurait modifié le dépôt entre-temps ?
Qu’en est-il des anciens dépôts non signés ? Gros avertissement que son contenu ne peut pas être vérifié. + invite oui/non/annuler.
a la responsabilité. Le propriétaire du serveur doit s’assurer que certains serveurs chargent le code souhaité. Qu’il s’agisse de rejeter la faute sur GitHub, en amont vers leur TLD (par exemple, .com), ou plus en aval.
Mais facilitez mon travail, en tant qu’administrateur. En tant que développeur de plugins, je veux vous faciliter la tâche.
Actuellement, la mise à niveau accorde une confiance absolue à l’URI source. Cela me préoccupe, car il a été démontré que la source (github) n’est pas digne de confiance, surtout dans certaines étapes de la reconstruction d’un conteneur. Prévenez-moi, en tant qu’administrateur, lorsqu’il y a un changement dans les relations de confiance.
En tant qu’administrateur, j’ai examiné chaque plugin ou composant de thème avant de l’ajouter. Après cela, Discourse me donne peu ou pas de conseils pour l’examen. Aujourd’hui, j’ai dû reconstruire mon conteneur, ce qui va cloner à nouveau tous les plugins. Je suis pratiquement hors de contrôle, à moins de faire une modification avancée dans la configuration pour épingler une version.
Cela pourrait me convenir, en tant que développeur logiciel bien reposé, au moment où j’ai besoin d’effectuer une maintenance. Mais ce sont là quelques contraintes. En plus de faire de Discourse une excellente plateforme pour le discours. Nous devons également en faire une plateforme techniquement sûre pour le discours. Les plugins compromis peuvent causer des dommages considérables. Les composants de thème compromis peuvent causer des dommages importants.
Je pense que cela a beaucoup de sens. Nous avons SRI pour Javascript, MS Authenticode pour Windows.
Il y a eu beaucoup d’attaques sur la chaîne d’approvisionnement sur, par exemple, NPM et RubyGems.
La seule chose qui m’inquiète, c’est qu’il y aurait une barrière pour que les gens fassent “accepter” leur composant de plugin ou de thème, comme la façon dont Microsoft Smartscreen empêche les utilisateurs d’exécuter des logiciels moins connus de développeurs uniques.