É bom que este problema tenha sido “resolvido” para este repositório. Mas o problema real ainda existe. Como assinar e qual é a fonte da chave para verificar a assinatura.
Então, minha primeira tentativa para resolver esse problema seria usar o mecanismo de assinatura integrado do git. O Discourse precisaria então rastrear o signatário de um plugin instalado. Se isso mudar, ele deve alertar o administrador.
Isso obviamente tem muitas falhas.
De onde obter as chaves do signatário? Metadados em plugin.rb e about.json. Servidores de chaves são bons… mas bastante complicados. Ou… meta.discourse.org serve como servidor de chaves, então os autores devem registrar suas chaves públicas.
Verificar apenas o commit mais recente? Provavelmente suficiente, não se pode fazer muito sobre chaves roubadas.
Mas se uma chave for roubada, como verificar a revogação? Se meta servir a chave, esse problema pode ser resolvido.
Isso é ótimo para a interface do administrador, mas e as instalações de plugins em um contêiner docker? Salvar chaves de assinatura previamente aceitas em um local compartilhado e adicionar uma etapa de verificação à reconstrução. Provavelmente uma verificação pré-construção para evitar que o sistema seja desativado e, em seguida, rejeitar o clone; e depois uma verificação pós-checkout apenas no caso de alguém ter mexido no repositório nesse ínterim?
E quanto a repositórios antigos não assinados? Grande aviso de que seu conteúdo não pode ser verificado. + prompt sim/não/cancelar
tem responsabilidade. O Proprietário do Servidor deve garantir que algum Servidor carregue o código desejado. Seja apontando a culpa para o GitHub, para cima para seu TLD (por exemplo, .com) ou mais para baixo.
Mas torne meu trabalho, como admin, mais fácil. Eu, como desenvolvedor de plugins, quero tornar seu trabalho mais fácil.
Atualmente, a atualização deposita confiança absoluta no URI de origem. Isso me preocupa, pois foi demonstrado que a origem (github) não é confiável, especialmente em certas etapas na reconstrução de um contêiner. Avise-me, como admin, que há uma mudança nas relações de confiança.
Eu, como admin, verifiquei cada plugin ou componente de tema antes de adicioná-lo. Depois disso, o Discourse me dá pouca ou nenhuma orientação na verificação. Hoje precisei reconstruir meu contêiner, o que clonará novamente todos os plugins. Estou bastante fora de controle, a menos que faça uma alteração avançada na configuração para fixar uma versão.
Isso pode funcionar para mim, como um desenvolvedor de software bem descansado no momento em que preciso fazer alguma manutenção. Mas essas são muitas restrições. Além de tornar o Discourse uma ótima plataforma para discourse. Também precisamos torná-lo uma plataforma tecnicamente segura para discourse. Plugins comprometidos podem causar sérios danos. Componentes de tema comprometidos podem causar danos significativos.
Acho que isso faz muito sentido. Temos SRI para Javascript, MS Authenticode para Windows.
Houve muitos ataques à cadeia de suprimentos, por exemplo, no NPM e no RubyGems.
A única coisa que me preocupa é que haveria uma barreira para as pessoas terem seu plugin ou componente de tema “aceito”, como o Microsoft Smartscreen impede que os usuários executem softwares menos conhecidos de desenvolvedores individuais.