Es bueno que este problema se haya “resuelto” para este repositorio. Pero el problema real aún existe. ¿Cómo se firma y cuál es la fuente de la clave para verificar la firma?
Así que mi primer intento para resolver ese problema sería hacer uso del mecanismo de firma incorporado de git. Discourse necesitaría entonces hacer un seguimiento del firmante de un plugin instalado. Si eso cambia, debería advertir al administrador.
Esto obviamente tiene muchos agujeros.
¿De dónde obtener las claves del firmante? Metadatos en plugin.rb y about.json. Los servidores de claves son agradables… pero bastante complicados. O… meta.discourse.org sirve como servidor de claves, por lo que los autores deberían registrar sus claves públicas.
¿Verificar solo el commit más reciente? Probablemente sea suficiente, no se puede hacer mucho sobre las claves robadas.
Pero si se roba una clave, ¿cómo verificar la revocación? Si meta sirve la clave, ese problema podría resolverse.
Esto es genial para la interfaz de administración, pero ¿qué pasa con las instalaciones de plugins en un contenedor Docker? Guardar las claves de firma previamente aceptadas en un recurso compartido y agregar un paso de verificación a la reconstrucción. Probablemente una verificación previa a la compilación para evitar que el sistema se caiga y luego rechazar el clon; ¿y luego una verificación posterior al checkout por si acaso alguien manipuló el repositorio mientras tanto?
¿Qué pasa con los repositorios antiguos sin firmar? Gran advertencia de que su contenido no se puede verificar. + aviso de sí/no/cancelar.
tiene responsabilidad. El propietario del servidor debe asegurarse de que algún servidor cargue el código deseado. Ya sea culpando a GitHub, a su TLD (por ejemplo, .com), o más abajo.
Pero haz mi trabajo, como administrador, más fácil. Yo, como desarrollador de plugins, quiero hacer tu trabajo más fácil.
Actualmente, la actualización deposita una confianza absoluta en la URI de origen. Esto me preocupa, ya que se ha demostrado que la fuente (github) no es confiable, especialmente en ciertos pasos de la reconstrucción de un contenedor. Adviérteme, como administrador, que hay un cambio en las relaciones de confianza.
Yo, como administrador, he revisado cada plugin o componente de tema antes de añadirlo. Después de eso, Discourse me da poca o ninguna orientación para la revisión. Hoy necesité reconstruir mi contenedor, lo que volverá a clonar todos los plugins. Estoy bastante fuera de control, a menos que haga un cambio avanzado en la configuración para fijar una versión.
Esto podría funcionar para mí, como un desarrollador de software bien descansado, en el momento en que necesite hacer algún mantenimiento. Pero son bastantes restricciones. Además de hacer de Discourse una gran plataforma para el debate. También necesitamos hacer de ella una plataforma técnicamente segura para el debate. Los plugins comprometidos pueden causar daños graves. Los componentes de temas comprometidos pueden causar daños significativos.
Creo que esto tiene mucho sentido. Tenemos SRI para Javascript, MS Authenticode para Windows.
Ha habido muchos ataques a la cadena de suministro en, por ejemplo, NPM y RubyGems.
Lo único que me preocupa es que haya una barrera para que la gente acepte sus plugins o componentes de temas, como cuando Microsoft Smartscreen impide a los usuarios ejecutar software menos conocido de desarrolladores individuales.