@drakenclimber Voy a presentar un resumen rápido para un documento MAINTAINER_PROCESS.md que podemos discutir / editar, pero todavía estoy tratando de terminar la versión v2.4.0 en este momento, y probablemente necesitaré unos días para atender algunos otros problemas no relacionados y desatendidos :)

@pcmoore - No se preocupe. ¡Buen trabajo en la versión v2.4 por cierto! Hágame saber cómo puedo ayudar.

Siéntete libre de usarme como conejillo de indias mientras arreglamos el proceso :)

¡Buen trabajo en la versión v2.4 por cierto! Hágame saber cómo puedo ayudar.

Cualquier prueba que pueda hacer es útil en este momento. Me siento bastante bien con la calidad de esta versión, pero muchos de los aspectos complicados cambiaron, por lo que no es descabellado imaginar que algún caso de esquina se rompió en alguna aplicación. Espero que no tengamos que hacer un lanzamiento de "bolsa marrón" v2.4.1, pero nunca se sabe.

Siéntete libre de usarme como conejillo de indias mientras arreglamos el proceso :)

Me alegra oírte decir que robaba usted es el conejillo de indias;)

@drakenclimber Estoy reservando este comentario para un borrador del documento MAINTAINER_PROCESS.md (supongo que puedo seguir editándolo aquí en función de los comentarios). Siéntase libre de enviar cualquier idea que tenga en este número y armaré un PR para esto una vez que tengamos algo parecido.

El proceso de mantenimiento de libseccomp

https://github.com/seccomp/libseccomp

Este documento intenta describir los procesos que deben seguir los diversos mantenedores de libseccomp. No pretende ser un requisito estricto, sino más bien un documento de orientación destinado a facilitar la gestión del proyecto libseccomp a varios co-mantenedores.

Reconocemos que este documento, como todas las demás partes del proyecto libseccomp, no es perfecto. Si es necesario realizar cambios, deben realizarse siguiendo las pautas que se describen aquí.

Revisión y fusión de parches

En un mundo perfecto, cada parche sería revisado y ACK de forma independiente por cada mantenedor, pero reconocemos que no es probable que sea práctico para cada parche. En circunstancias normales, cada parche debe recibir ACK por una mayoría simple de mantenedores (en el caso de un número par de mantenedores, N / 2 + 1) antes de fusionarse en el repositorio. Los mantenedores deben ACK los parches usando un formato similar al Kernel de Linux, por ejemplo:

Acked-by: John Smith <[email protected]>

El mantenedor que fusionó el parche en el repositorio debe agregar su aprobación después de asegurarse de que es correcto hacerlo (consulte la documentación sobre el envío de parches); si no es correcto que el mantenedor agregue su firma, es probable que el parche no deba fusionarse. El mantenedor debe agregar su firma utilizando el formato estándar al final de los metadatos del parche, por ejemplo:

Signed-off-by: Jane Smith <[email protected])

Se anima a los mantenedores a que se comuniquen entre sí por muchas razones, una de las cuales es dejar que los demás se mantengan inaccesibles durante un período de tiempo prolongado. Si un parche se retiene debido a la falta de ACK y los otros mantenedores no responden después de un período de tiempo razonable (por ejemplo, un retraso de más de dos semanas), siempre que no haya NACK pendientes, el parche se puede fusionar. sin mayoría simple.

Gestión de informes de vulnerabilidades sensibles

El proceso de informe de vulnerabilidades de libseccomp está documentado en el documento SECURITY.md.

Los mantenedores deben trabajar junto con el informante para evaluar la validez y gravedad de la vulnerabilidad informada. Siempre que sea posible, se deben seguir prácticas responsables de informes y parches, incluida la notificación a las listas de correo _linux-distros_ y _oss-security_.

• https://oss-security.openwall.org/wiki/mailing-lists/distros

Administrar el rastreador de problemas de GitHub

Usamos el rastreador de problemas de GitHub para rastrear errores, solicitudes de funciones y, a veces, preguntas sin respuesta. Las convenciones aquí están destinadas a ayudar a distinguir entre los diferentes usos y priorizar dentro de esas categorías.

Las solicitudes de funciones DEBEN tener un prefijo "RFE:" agregado al nombre del problema y usar la etiqueta de "mejora". Los informes de errores DEBEN agregar un prefijo "BUG:" al nombre del problema y utilizar la etiqueta "error".

Los problemas DEBERÍAN priorizarse utilizando las etiquetas "prioridad / alta", "prioridad / media" y "prioridad / baja". Es de esperar que el significado sea obvio.

Los problemas SE PUEDEN etiquetar adicionalmente con las etiquetas "pendiente / información", "pendiente / revisión" y "pendiente / revisión" para indicar que se necesita información adicional, el problema / parche está pendiente de revisión y / o el parche requiere cambios.

Administrar los hitos de la versión de GitHub

Debe haber al menos dos hitos de GitHub en cualquier momento: uno para la próxima versión principal / secundaria (por ejemplo, v2.5) y otro para la próxima versión del parche (por ejemplo, v2.4.2). A medida que se ingresan problemas en el sistema, se pueden agregar a los hitos a discreción de los encargados del mantenimiento.

Gestión de la lista de distribución pública

La lista de correo está alojada actualmente en Grupos de Google y, si bien es posible participar en discusiones sin una cuenta de Google, se requiere una cuenta de Google para moderar / administrar el grupo. Aquellos mantenedores que tienen una cuenta de Google y desean ser agregados a la lista de moderadores deben ser agregados, pero no hay ningún requisito para hacerlo.

A pesar del término "moderador", la lista no está moderada actualmente y debería seguir siendo la forma.

Lanzamientos de nuevos proyectos

El proceso de publicación de libseccomp está documentado en el documento RELEASE_PROCESS.md.

Idealmente, creo que sería bueno obtener un ACK de cada mantenedor en cada parche / PR, pero no estoy seguro de si eso sería demasiado obstáculo. Mi intuición es que los parches / PR de libseccomp tienen un volumen lo suficientemente bajo como para que esto no debería ser un problema importante, pero tengo curiosidad por saber qué piensas

Acordado. Creo que esforzarse por obtener un ACK para cada parche sería bueno, pero es posible que queramos dejar la flexibilidad abierta para omitirlo en parches realmente simples u otras circunstancias atenuantes (vacaciones largas, etc.). Sin embargo, obviamente, omitir los otros ACK debería ser la excepción, no la norma.

Independientemente de lo anterior, creo que los parches de cualquier mantenedor deben ser ACK y confirmados por un mantenedor diferente.

Definitivamente sería un buen hábito. Debería ayudar a evitar errores tontos.

También necesitamos documentar cómo manejar la combinación de PR y parches, por ejemplo, la aprobación del mantenedor, hacerlo a mano y sin usar las herramientas de GitHub, etc.

Me interesaría ver el proceso que recomienda. ¿Hay alguna razón por la que deberíamos evitar las herramientas integradas de github?

Creo que la clave aquí es enumerar a todos los mantenedores en la sección correspondiente de README.md y mencionar que los mantenedores deben trabajar juntos para resolver el problema y seguir los procesos de divulgación responsable apropiados. Deberíamos incluir enlaces a las listas de linux-distros y oss-security.

Sí, proporcionar un método fácil y seguro para que otros informen problemas es fundamental. Estoy de acuerdo.

Acordado. Creo que esforzarse por obtener un ACK para cada parche sería bueno, pero es posible que queramos dejar la flexibilidad abierta para omitirlo en parches realmente simples u otras circunstancias atenuantes (vacaciones largas, etc.). Sin embargo, obviamente, omitir los otros ACK debería ser la excepción, no la norma.

Buenos puntos, estoy de acuerdo.

También necesitamos documentar cómo manejar la combinación de PR y parches, por ejemplo, la aprobación del mantenedor, hacerlo a mano y sin usar las herramientas de GitHub, etc.

Me interesaría ver el proceso que recomienda. ¿Hay alguna razón por la que deberíamos evitar las herramientas integradas de github?

Realmente me gusta la idea de que todos los que toquen un parche, ya sea al crearlo o al enviarlo al repositorio principal, agreguen explícitamente su aprobación al archivo. También creo que los mantenedores deberían hacer un make check en su sistema local antes de enviar algo al repositorio principal. La combinación de PR directamente desde la interfaz de GitHub no permite realmente hacer ninguna de esas cosas.

Me imagino que si el volumen de relaciones públicas aumentara drásticamente, podríamos reconsiderar esto, pero en este momento el volumen es lo suficientemente bajo como para que los pasos manuales adicionales realmente no sean significativos en mi opinión.

Opiniones @drakenclimber?

Acabo de buscar en la lista de correo de Grupos de Google y parece que no puedo usar su cuenta / dirección de oracle.com como cuenta de administrador / moderador, debe ser una cuenta de Google. En este punto, creo que depende de ti @drakenclimber; si desea acceso de administrador / moderador, deberá suscribirse con una cuenta de Google.

Vale la pena señalar que actualmente no modero la lista y no creo que deba ser moderada. En la actualidad, las únicas publicaciones que no se envían inmediatamente a la lista son aquellas que Google cree que son SPAM.

Tampoco vale la pena que el tráfico en la lista de correo fuera de las notificaciones de confirmación se esté acercando a cero, la mayor parte de la interacción ocurre en GitHub ahora. Si bien creo que deberíamos mantener la lista de correo, no sienta que necesita ser un administrador / moderador de la lista para "compartir la carga", no hay "carga" en este caso.

Me imagino que si el volumen de relaciones públicas aumentara drásticamente, podríamos reconsiderar esto, pero en este momento el volumen es lo suficientemente bajo como para que los pasos manuales adicionales realmente no sean significativos en mi opinión. Opiniones @drakenclimber?

Acordado. Estoy bien con un paso manual en esta etapa del proyecto. De hecho, eso es exactamente lo que he estado haciendo durante un tiempo.

En este punto, creo que depende de ti @drakenclimber; si desea acceso de administrador / moderador, deberá suscribirse con una cuenta de Google.

Si bien creo que deberíamos mantener la lista de correo, no sienta que necesita ser un administrador / moderador de la lista para "compartir la carga", no hay "carga" en este caso.

Tiene sentido. Puedes agregar mi dirección de Gmail si te parece bien; Realmente no veo un inconveniente, pero podría resultar útil más adelante. tom dot hromatka en gmail.

Acabo de notar que en la pestaña "Seguridad" del proyecto, GitHub parece manejar el archivo SECURITY.md de una manera especial (ver CONTRIBUTING.md como ejemplo). Deberíamos considerar el uso de este archivo como parte de este proceso.

La pestaña "Seguridad" también le permite crear una bifurcación privada del proyecto para que pueda trabajar en parches en privado; esto podría ser una gran ventaja ya que nos permite colaborar mejor en las correcciones de seguridad sin hacer público el problema antes de que la corrección esté lista.

Esa es una característica realmente genial. ¡Buen descubrimiento!

@drakenclimber Acabo de actualizar el documento en el comentario anterior, échale un vistazo y déjame saber lo que piensas. Todavía necesitamos improvisar un documento SECURITY.md, pero eso debería ser bastante rápido (solo unas pocas oraciones); Haré un borrador juntos una vez que esté satisfecho con el documento principal anterior.

@drakenclimber Acabo de suscribir su dirección de gmail al grupo de Google y le di acceso de administrador / moderador, si no funciona, avíseme.

Acabo de suscribir su dirección de Gmail al grupo de Google y le di acceso de administrador / moderador, si no funciona, avíseme.

Parece que está funcionando. Pude iniciar sesión y acceder a la configuración de la lista de correo. ¡Gracias!

Acabo de actualizar el documento en el comentario anterior, échale un vistazo y déjame saber lo que piensas.

Me queda muy bien.

@drakenclimber aquí hay un borrador rápido de un documento SECURITY.md, ¿pensamientos?

El proceso de manejo de vulnerabilidades de seguridad de libseccomp

https://github.com/seccomp/libseccomp

Este documento intenta describir los procesos a través de los cuales los errores sensibles de seguridad relevantes pueden ser divulgados de manera responsable al proyecto libseccomp y cómo los encargados del mantenimiento del proyecto deben manejar estos informes. Al igual que los otros documentos del proceso libseccomp, este documento debe tratarse como un documento guía y no como un conjunto de regulaciones estrictas e inflexibles; Se alienta a los informadores de errores y a los encargados del mantenimiento del proyecto a trabajar juntos para abordar los problemas lo mejor que puedan, de la manera que funcione mejor para todas las partes involucradas.

Informar problemas

Los problemas con la biblioteca libseccomp que no sean adecuados para la divulgación pública inmediata deben enviarse por correo electrónico a los encargados del mantenimiento actual de libseccomp; la lista se encuentra a continuación. Por lo general, solicitamos como máximo un período de 90 días para abordar el problema antes de que se haga público, pero haremos todo lo posible para abordar el problema lo más rápido posible y acortar el período de divulgación.

• Paul Moore, [email protected]
• Tom Hromatka, tom. [email protected]

Resolución de problemas de seguridad delicados

Tras la divulgación de un error, los encargados del mantenimiento deben trabajar juntos para investigar el problema y decidir una solución. Para evitar una divulgación temprana del problema, quienes trabajen en la solución deben hacerlo de forma privada y fuera de las prácticas tradicionales de desarrollo de libseccomp. Una posible solución a esto es aprovechar la funcionalidad de "Seguridad" de GitHub para crear una bifurcación de desarrollo privada que se pueda compartir entre los encargados del mantenimiento y, opcionalmente, el informador. Se puede crear un problema de marcador de posición de GitHub, pero los detalles deben permanecer extremadamente limitados hasta que el problema se haya solucionado y se haya divulgado de manera responsable. Si se ha asignado un CVE u otra etiqueta al problema, el título del problema de GitHub debe incluir la etiqueta de vulnerabilidad una vez que se haya revelado el problema.

Revelación pública

Siempre que sea posible, se deben seguir prácticas responsables de informes y parches, incluida la notificación a las listas de correo de linux-distros y oss-security.

• https://oss-security.openwall.org/wiki/mailing-lists/distros

de la manera que mejor les funcione.

nitpick - Me sentiría tentado a cambiar esto a in a manner which works best for all parties involved.

Creo que el documento de vulnerabilidad de seguridad se ve muy bien. ¡Buen trabajo!

de la manera que mejor les funcione.

nitpick - Me sentiría tentado a cambiar esto a in a manner which works best for all parties involved.

Me gusta eso, actualizando el borrador ahora.

Creo que estamos lo suficientemente de acuerdo en que vale la pena armar un PR con las actualizaciones de documentos / procesos, lo haré ahora y publicaré un enlace aquí.

Enlace de relaciones públicas (también incluido en el historial de GH anterior): https://github.com/seccomp/libseccomp/pull/158

Creo que ya estás listo @drakenclimber , si notas algo mal, avísame.