È bello che questo problema sia stato “risolto” per questo repository. Ma il vero problema esiste ancora. Come si firma e qual è la fonte della chiave per verificare la firma.
Quindi il mio primo tentativo per risolvere questo problema sarebbe quello di utilizzare il meccanismo di firma integrato di git. Discourse dovrebbe quindi tenere traccia del firmatario di un plugin installato. Se ciò cambia, dovrebbe avvisare l’amministratore.
Ovviamente, questo ha molti buchi.
Da dove prendere le chiavi del firmatario? Metadati in plugin.rb e about.json. I keyserver sono utili… ma piuttosto complicati. Oppure… meta.discourse.org funge da keyserver, quindi gli autori dovrebbero registrare le loro chiavi pubbliche.
Verificare solo il commit più recente? Probabilmente sufficiente, non si può fare molto per le chiavi rubate.
Ma se una chiave viene rubata, come controllare la revoca? Se meta serve la chiave, quel problema potrebbe essere risolto.
Questo è ottimo per l’interfaccia utente dell’amministratore, ma cosa succede alle installazioni di plugin in un container docker? Salvare le chiavi di firma precedentemente accettate in una condivisione e aggiungere un passaggio di verifica alla ricostruzione. Probabilmente un controllo pre-build per evitare di bloccare il sistema e poi rifiutare il clone; e poi un controllo post-checkout per ogni evenienza se qualcuno ha manomesso il repository nel frattempo?
Cosa fare con i vecchi repository non firmati? Grande avviso che il suo contenuto non può essere verificato. + prompt sì/no/annulla.
ha la responsabilità. Il proprietario del server dovrebbe assicurarsi che alcuni server carichino il codice desiderato. Sia che si tratti di puntare il dito contro GitHub, a monte verso il loro TLD (ad esempio, .com), o ulteriormente a valle
Ma rendi il mio lavoro, come amministratore, più facile. Io, come sviluppatore di plugin, voglio rendere il tuo lavoro più facile.
Attualmente l’aggiornamento ripone assoluta fiducia nell’URI sorgente. Questo mi preoccupa, poiché è stato dimostrato che la sorgente (github) non è affidabile, soprattutto in certi passaggi durante la ricostruzione di un container. Avvisami, come amministratore, quando c’è un cambiamento nelle relazioni di fiducia.
Io, come amministratore, ho esaminato ogni plugin o componente del tema prima di aggiungerlo. Dopodiché, Discourse mi offre poca o nessuna guida nella verifica. Oggi ho dovuto ricostruire il mio container, che clonerà nuovamente tutti i plugin. Sono quasi fuori controllo, a meno che non apporti una modifica avanzata alla configurazione per bloccare una release.
Questo potrebbe funzionare per me, come sviluppatore software ben riposato, nel momento in cui ho bisogno di fare della manutenzione. Ma ci sono parecchi vincoli. Oltre a rendere Discourse una grande piattaforma per il dibattito, dobbiamo anche renderla una piattaforma tecnicamente sicura per il dibattito. Plugin compromessi possono causare seri danni. Componenti del tema compromessi possono causare danni significativi.
Penso che abbia molto senso. Abbiamo SRI per Javascript, MS Authenticode per Windows.
Ci sono stati molti attacchi alla catena di approvvigionamento, ad esempio su NPM e RubyGems.
L’unica cosa che mi preoccupa è che ci sarebbe una barriera per le persone per far “accettare” il loro plugin o componente tematico, come Microsoft Smartscreen impedisce agli utenti di eseguire software meno conosciuto da singoli sviluppatori.