@drakenclimber Je vais lancer un aperçu rapide d'un document MAINTAINER_PROCESS.md que nous pouvons discuter/modifier, mais j'essaie toujours de terminer la version 2.4.0 en ce moment, et j'aurai probablement besoin de quelques jours pour tendance à quelques autres problèmes non liés et négligés :)

@pcmoore - Pas de soucis. Beau travail sur la version 2.4 en passant ! Faites-moi savoir comment je peux vous aider.

N'hésitez pas à m'utiliser comme cobaye pendant que nous clarifions le processus :)

Beau travail sur la version 2.4 en passant ! Faites-moi savoir comment je peux vous aider.

Quels que soient les tests que vous pouvez faire, ils sont utiles à ce stade. Je me sens plutôt bien quant à la qualité de cette version, mais beaucoup de points délicats ont changé, il n'est donc pas déraisonnable d'imaginer qu'un cas d'angle se soit cassé dans une application. J'espère que nous n'aurons pas à faire une version "sac brun" v2.4.1, mais on ne sait jamais.

N'hésitez pas à m'utiliser comme cobaye pendant que nous clarifions le processus :)

Content de t'entendre dire ça parce que tu es le cobaye ;)

@drakenclimber Je réserve ce commentaire pour un brouillon du document MAINTAINER_PROCESS.md (je

Le processus de maintenance de libseccomp

https://github.com/seccomp/libseccomp

Ce document tente de décrire les processus qui devraient être suivis par les divers mainteneurs de libseccomp. Il n'est pas conçu comme une exigence stricte, mais plutôt comme un document d'orientation destiné à faciliter la gestion du projet libseccomp par plusieurs co-mainteneurs.

Nous reconnaissons que ce document, comme toutes les autres parties du projet libseccomp, n'est pas parfait. Si des modifications doivent être apportées, elles doivent être effectuées en suivant les directives décrites ici.

Examen et fusion des correctifs

Dans un monde parfait, chaque correctif serait examiné indépendamment et ACK par chaque mainteneur, mais nous reconnaissons que ce n'est probablement pas pratique pour chaque correctif. Dans des circonstances normales, chaque correctif devrait être ACK par une simple majorité de mainteneurs (dans le cas d'un nombre pair de mainteneurs, N/2+1) avant d'être fusionné dans le référentiel. Les responsables doivent ACK les correctifs en utilisant un format similaire au noyau Linux, par exemple :

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

Le mainteneur qui a fusionné le correctif dans le référentiel doit ajouter sa signature après s'être assuré qu'il est correct de le faire (voir la documentation sur la soumission de correctifs) ; s'il n'est pas correct pour le mainteneur d'ajouter son approbation, il est probable que les correctifs ne doivent pas être fusionnés. Le responsable doit ajouter sa signature en utilisant le format standard à la fin des métadonnées du correctif, par exemple :

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

Les mainteneurs sont encouragés à communiquer les uns avec les autres pour de nombreuses raisons, dont l'une est de laisser les autres lorsque l'un d'entre eux sera inaccessible pendant une période prolongée. Si un correctif est suspendu en raison d'un manque d'ACK et que les autres responsables ne répondent pas après une période de temps raisonnable (par exemple, un délai de plus de deux semaines), tant qu'il n'y a pas de NACK en attente, le correctif peut être fusionné sans majorité simple.

Gestion des rapports de vulnérabilité sensibles

Le processus de rapport de vulnérabilité libseccomp est documenté dans le document SECURITY.md.

Les responsables doivent travailler avec le rapporteur pour évaluer la validité et la gravité de la vulnérabilité signalée. Dans la mesure du possible, des pratiques de reporting et de correctifs responsables doivent être suivies, y compris la notification aux listes de diffusion _linux-distros_ et _oss-security_.

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

Gestion du suivi des problèmes GitHub

Nous utilisons le suivi des problèmes GitHub pour suivre les bogues, les demandes de fonctionnalités et parfois les questions sans réponse. Les conventions ici sont destinées à aider à distinguer les différentes utilisations et à établir des priorités au sein de ces catégories.

Les demandes de fonctionnalités DOIVENT avoir un préfixe « RFE : » ajouté au nom du problème et utiliser l'étiquette « amélioration ». Les rapports de bogues DOIVENT ajouter un préfixe « BUG : » au nom du problème et utiliser l'étiquette « bogue ».

Les problèmes DEVRAIENT être hiérarchisés en utilisant les étiquettes "priorité/élevée", "priorité/moyenne" et "priorité/faible". Le sens devrait, espérons-le, être évident.

Les problèmes PEUVENT en outre être étiquetés avec les étiquettes « en attente/info », « en attente/révision » et « en attente/révision » pour indiquer que des informations supplémentaires sont nécessaires, que le problème/le correctif est en attente de révision et/ou que le correctif nécessite des modifications.

Gérer les jalons de la version GitHub

Il doit y avoir au moins deux jalons GitHub à tout moment : un pour la prochaine version majeure/mineure (par exemple, v2.5) et un pour la prochaine version de correctif (par exemple, v2.4.2). Au fur et à mesure que les problèmes sont entrés dans le système, ils peuvent être ajoutés aux jalons à la discrétion des responsables.

Gestion de la liste de diffusion publique

La liste de diffusion est actuellement hébergée sur Google Groupes, et bien qu'il soit possible de participer aux discussions sans compte Google, un compte Google est requis pour modérer/administrer le groupe. Les responsables qui ont un compte Google et souhaitent être ajoutés à la liste des modérateurs doivent être ajoutés, mais ce n'est pas obligatoire.

Malgré le terme « modérateur », la liste n'est actuellement pas modérée et devrait rester la même.

Nouvelles versions du projet

Le processus de publication de libseccomp est documenté dans le document RELEASE_PROCESS.md.

Idéalement, je pense que ce serait bien d'obtenir un ACK de chaque mainteneur sur chaque patch/PR, mais je ne suis pas sûr que ce serait trop un obstacle ? Mon intuition est que les correctifs/PR de libseccomp ont un volume suffisamment bas pour que cela ne devrait pas être un problème majeur, mais je suis curieux de savoir ce que vous en pensez

D'accord. Je pense qu'il serait bon de rechercher un ACK pour chaque patch, mais nous pouvons vouloir laisser la flexibilité de contourner cela pour des patchs vraiment simples, ou d'autres circonstances atténuantes (longues vacances, etc.). De toute évidence, le contournement des autres ACK devrait être l'exception et non la norme.

Indépendamment de ce qui précède, je pense que les correctifs d'un responsable donné doivent être ACK et validés par un responsable différent.

Ce serait certainement une bonne habitude à prendre. Cela devrait aider à éviter les erreurs stupides.

Nous devons également documenter comment gérer la fusion des PR et des correctifs, par exemple la signature du responsable, le faire à la main et sans utiliser les outils GitHub, etc.

Je serais intéressé de voir le processus que vous recommandez. Y a-t-il une raison pour laquelle nous devrions éviter les outils github intégrés ?

Je pense que la clé ici est de lister tous les responsables dans la section appropriée du fichier README.md et de mentionner que les responsables doivent travailler ensemble pour résoudre le problème et suivre les processus de divulgation responsables appropriés. Nous devrions inclure des liens vers les listes linux-distros et oss-security.

Oui, il est essentiel de fournir aux autres une méthode simple et sûre pour signaler des problèmes. Je suis d'accord.

D'accord. Je pense qu'il serait bon de rechercher un ACK pour chaque patch, mais nous pouvons vouloir laisser la flexibilité de contourner cela pour des patchs vraiment simples, ou d'autres circonstances atténuantes (longues vacances, etc.). De toute évidence, le contournement des autres ACK devrait être l'exception et non la norme.

Bons points, je suis d'accord.

Nous devons également documenter comment gérer la fusion des PR et des correctifs, par exemple la signature du responsable, le faire à la main et sans utiliser les outils GitHub, etc.

Je serais intéressé de voir le processus que vous recommandez. Y a-t-il une raison pour laquelle nous devrions éviter les outils github intégrés ?

J'aime beaucoup l'idée que tous ceux qui touchent à un correctif, soit en le créant, soit en le validant dans le référentiel principal, ajoutent explicitement leur signature au fichier. Je pense aussi vraiment que les mainteneurs devraient faire un make check sur leur système local avant de pousser quoi que ce soit vers le dépôt principal. La fusion des PR directement depuis l'interface GitHub ne permet pas vraiment de faire l'une ou l'autre de ces choses.

J'imagine que si le volume des relations publiques augmentait considérablement, nous pourrions reconsidérer cela, mais pour le moment, le volume est suffisamment bas pour que les étapes manuelles supplémentaires ne soient pas vraiment importantes à mon avis.

Avis @drakenclimber?

Je viens de consulter la liste de diffusion Google Groupes et il semble que je ne puisse pas utiliser votre compte/adresse oracle.com en tant que compte de gestionnaire/modérateur, il doit s'agir d'un compte Google. À ce stade, je pense que c'est à vous de décider @drakenclimber; si vous souhaitez un accès administrateur/modérateur, vous devrez vous inscrire avec un compte Google.

Il convient de noter que je ne modère pas actuellement la liste, et je ne pense pas qu'elle devrait être modérée. À l'heure actuelle, les seuls messages qui ne sont pas immédiatement envoyés à la liste sont des choses que Google pense être du SPAM.

Cela ne vaut également rien que le trafic sur la liste de diffusion en dehors des notifications de commit approche de zéro, la plupart des interactions se produisent maintenant sur GitHub. Bien que je pense que nous devrions conserver la liste de diffusion, ne pensez pas que vous devez être un gestionnaire/modérateur de la liste afin de "partager le fardeau", il n'y a pas de "fardeau" dans ce cas.

J'imagine que si le volume des relations publiques augmentait considérablement, nous pourrions reconsidérer cela, mais pour le moment, le volume est suffisamment bas pour que les étapes manuelles supplémentaires ne soient pas vraiment importantes à mon avis. Avis @drakenclimber?

D'accord. Je suis d'accord avec une étape manuelle à ce stade du projet. En fait, c'est exactement ce que je fais depuis un moment maintenant.

À ce stade, je pense que c'est à vous de décider @drakenclimber; si vous souhaitez un accès administrateur/modérateur, vous devrez vous inscrire avec un compte Google.

Bien que je pense que nous devrions conserver la liste de diffusion, ne pensez pas que vous devez être un gestionnaire/modérateur de la liste afin de "partager le fardeau", il n'y a pas de "fardeau" dans ce cas.

Logique. Vous pouvez ajouter mon adresse gmail si cela vous convient ; Je ne vois pas vraiment d'inconvénient, mais cela pourrait s'avérer utile plus tard. tom point hromatka sur gmail.

Je viens de remarquer que sous l'onglet "Sécurité" du projet, GitHub semble gérer le fichier SECURITY.md d'une manière spéciale (voir CONTRIBUTING.md comme exemple). Nous devrions envisager d'utiliser ce fichier dans le cadre de ce processus.

L'onglet "Sécurité" permet également de créer un fork privé du projet afin de pouvoir travailler sur des patchs en privé ; cela pourrait être une grande victoire dans la mesure où cela nous permet de mieux collaborer sur les correctifs de sécurité sans rendre le problème public avant que le correctif ne soit prêt.

C'est une fonctionnalité vraiment cool. Bonne trouvaille !

@drakenclimber Je viens de mettre à jour le document dans le commentaire ci-dessus, consultez-le et dites-moi ce que vous en pensez. Nous avons encore besoin de bricoler un doc SECURITY.md, mais cela devrait être assez rapide (quelques phrases); Je préparerai un brouillon une fois que vous serez satisfait du document principal ci-dessus.

@drakenclimber Je viens d'inscrire votre adresse gmail au groupe Google et de vous donner un accès administrateur/modérateur, si cela ne fonctionne pas, faites-le moi savoir.

Je viens d'inscrire votre adresse gmail au groupe Google et je vous ai donné un accès administrateur/modérateur, si cela ne fonctionne pas, faites-le moi savoir.

On dirait que ça marche. J'ai pu me connecter et accéder aux paramètres de la liste de diffusion. Merci!

Je viens de mettre à jour la doc dans le commentaire ci-dessus, consultez-la et dites-moi ce que vous en pensez.

Ça m'a l'air vraiment bien.

@drakenclimber voici une ébauche rapide d'un document SECURITY.md, des pensées?

Le processus de gestion des vulnérabilités de sécurité de libseccomp

https://github.com/seccomp/libseccomp

Ce document tente de décrire les processus par lesquels les bogues sensibles liés à la sécurité peuvent être divulgués de manière responsable au projet libseccomp et comment les responsables du projet doivent gérer ces rapports. Tout comme les autres documents de processus libseccomp, ce document doit être traité comme un document d'orientation et non comme un ensemble de réglementations strictes et inflexibles ; les rapporteurs de bogues et les responsables du projet sont encouragés à travailler ensemble pour résoudre les problèmes du mieux qu'ils peuvent, d'une manière qui fonctionne le mieux pour toutes les parties impliquées.

Signaler des problèmes

Les problèmes avec la bibliothèque libseccomp qui ne conviennent pas à une divulgation publique immédiate doivent être envoyés par courrier électronique aux mainteneurs actuels de libseccomp, la liste est ci-dessous. Nous demandons généralement au plus 90 jours pour résoudre le problème avant qu'il ne soit rendu public, mais nous ferons tout notre possible pour résoudre le problème le plus rapidement possible et raccourcir la fenêtre de divulgation.

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

Résolution des problèmes de sécurité sensibles

Lors de la divulgation d'un bogue, les responsables doivent travailler ensemble pour enquêter sur le problème et décider d'une solution. Afin d'éviter une divulgation précoce du problème, ceux qui travaillent sur la solution doivent le faire en privé et en dehors des pratiques traditionnelles de développement de libseccomp. Une solution possible consiste à tirer parti de la fonctionnalité "Sécurité" de GitHub pour créer un fork de développement privé qui peut être partagé entre les responsables et éventuellement le rapporteur. Un problème d'espace réservé GitHub peut être créé, mais les détails doivent rester extrêmement limités jusqu'à ce que le problème soit résolu et divulgué de manière responsable. Si une balise CVE, ou une autre balise, a été attribuée au problème, le titre du problème GitHub doit inclure la balise de vulnérabilité une fois que le problème a été divulgué.

Divulgation publique

Dans la mesure du possible, des pratiques de rapport et de correctifs responsables doivent être suivies, y compris la notification aux listes de diffusion linux-distros et oss-security.

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

d'une manière qui leur convient le mieux.

pinaille - je serais tenté de changer cela en in a manner which works best for all parties involved.

Je pense que la doc sur la vulnérabilité de sécurité a l'air vraiment bien. Bon travail!

d'une manière qui leur convient le mieux.

pinaille - je serais tenté de changer cela en in a manner which works best for all parties involved.

J'aime ça, mettre à jour le brouillon maintenant.

Je pense que nous sommes suffisamment d'accord pour dire qu'il vaut la peine de mettre en place un PR avec les mises à jour de la documentation / du processus, je vais le faire maintenant et poster un lien ici.

Lien PR (également inclus dans l'historique GH ci-dessus) : https://github.com/seccomp/libseccomp/pull/158

Je pense que vous êtes prêt maintenant @drakenclimber , si vous remarquez quelque chose de mal, faites-le moi savoir.