¿Cómo debería un proyecto de código abierto con un repositorio público manejar mejor las solicitudes de extracción (RP) que abordan vulnerabilidades de seguridad informadas de forma segura pero aún no divulgadas públicamente?
Estoy involucrado en un proyecto de código abierto con varios cientos de contribuyentes. Publicamos avisos de seguridad y vulnerabilidades varias veces al año como parte de un lanzamiento mensual programado regularmente. No publicamos información sobre las vulnerabilidades hasta que la versión parcheada esté disponible. Podemos gestionar de forma segura los problemas de seguridad en nuestro sistema de gestión de proyectos (JIRA). Pero no tenemos un buen proceso para ocultar los RP que corrigen las vulnerabilidades de seguridad a medida que se envían a GitHub. Nos preocupa que las personas puedan encontrar estas soluciones antes de su lanzamiento y crear vulnerabilidades de día cero.
Hemos considerado el uso de repositorios privados que bifurcan el repositorio principal, pero gran parte de nuestra revisión actual y el flujo de trabajo de control de calidad ocurre en los RP. Si trasladamos el flujo de trabajo a un repositorio privado solo del equipo de seguridad, eso reduciría la ventana cuando la solución sea pública a las horas que lleva generar los tarballs y publicarlos en sourceforge, lo que sería una gran mejora. También es probable que debamos evitar fusionar los RP en nuestra versión beta pública.
Antes de ir en esa dirección, me gustaría saber cuál es la mejor práctica para manejar parches de corrección de errores de seguridad previos al lanzamiento en proyectos de código abierto con repositorios abiertos. Si el problema puede abordarse mejor utilizando una plataforma diferente a GitHub, debo mencionar que estamos evaluando la migración a GitLab.