oisf/suricataMoteur open-source IDS/IPS/NSM réseau pour l'inspection du trafic en temps réel, la détection et la prévention d'intrusions, l'analyse des protocoles et la chasse aux menaces basée sur des règles.
Suricata est un moteur réseau IDS, IPS et NSM développé par l'OISF et la communauté Suricata.
Nous acceptons avec plaisir les correctifs et autres contributions. Veuillez consulter notre processus de contribution pour savoir comment commencer.
Suricata est un logiciel complexe qui traite des entrées généralement non fiables. Une mauvaise gestion de ces entrées peut avoir de graves conséquences :
En d'autres termes, nous pensons que les enjeux sont très élevés, d'autant plus que dans de nombreux cas courants, l'IDS/IPS sera directement accessible par un attaquant.
Pour cette raison, nous avons mis en place un processus de QA assez étendu. Une conséquence est que contribuer à Suricata peut être un processus quelque peu long.
À un niveau élevé, les étapes sont :
Les membres de l'équipe OISF peuvent soumettre des builds à notre configuration QA privée. Elle exécutera une série de tests de compilation et une suite de régression pour confirmer qu'aucune fonctionnalité existante ne casse.
Les exécutions de QA finales prennent au minimum quelques heures et s'exécutent généralement pendant la nuit. Elles comprennent actuellement :
En plus de ces tests, selon le type de modification du code, d'autres tests peuvent être exécutés manuellement :
Il est important de comprendre que presque tous les tests ci-dessus sont utilisés comme tests d'acceptation. Si quelque chose échoue, c'est à vous de traiter ce problème dans votre code.
Une étape de la QA est actuellement exécutée après la fusion. Nous soumettons des builds au programme Coverity Scan. En raison des limitations de ce service (gratuit), nous ne pouvons soumettre qu'une fois par jour maximum. Bien sûr, il peut arriver qu'après la fusion, la communauté trouve des problèmes. Dans les deux cas, nous vous demandons d'aider à traiter les problèmes lorsqu'ils surviennent.
Q : Accepterez-vous ma PR ?
R : Cela dépend de plusieurs choses, notamment la qualité du code. Pour les nouvelles fonctionnalités, cela dépend aussi de savoir si l'équipe et/ou la communauté pensent que la fonctionnalité est utile, à quel point elle affecte d'autres codes et fonctionnalités, le risque de régressions de performance, etc.
Q : Quand ma PR sera-t-elle fusionnée ?
R : Cela dépend. S'il s'agit d'une fonctionnalité majeure ou d'un changement considéré à haut risque, il ira probablement dans la prochaine version majeure.
Q : Pourquoi ma PR a-t-elle été fermée ?
R : Comme documenté dans le workflow GitHub de Suricata, nous attendons une nouvelle pull request pour chaque changement.
Normalement, l'équipe (ou la communauté) donnera son retour sur une pull request, après quoi celle-ci doit être remplacée par une PR améliorée. Regardez donc les commentaires. Si vous n'êtes pas d'accord avec les commentaires, nous pouvons toujours en discuter dans la PR fermée.
Si la PR a été fermée sans commentaires, c'est probablement dû à un échec de la QA. Si les contrôles GitHub-CI ont échoué, la PR doit être corrigée immédiatement. Pas besoin d'en discuter, sauf si vous pensez que l'échec de la QA est incorrect.
Q : Le compilateur / analyseur de code / outil a tort, que faire ?
R : Pour faciliter l'automatisation de la QA, nous n'acceptons pas que des avertissements ou erreurs subsistent. Dans certains cas, cela peut signifier que nous ajoutons une suppression si l'outil le permet (par exemple valgrind, DrMemory). Certains avertissements peuvent être désactivés. Dans certains cas exceptionnels, la seule « solution » est de refactoriser le code pour contourner une limitation de l'analyseur statique ou un faux positif. Bien que frustrant, nous préférons cela plutôt que de laisser des avertissements dans la sortie. Les avertissements ont tendance à être ignorés et augmentent alors le risque de masquer d'autres avertissements.
Q : Je pense que votre test QA est erroné
R : Si vous le pensez vraiment, nous pouvons discuter de la façon de l'améliorer. Mais ne tirez pas cette conclusion trop rapidement : le plus souvent, c'est le code qui s'avère être en tort.
Q : Exigez-vous la signature d'un accord de licence de contributeur ?
R : Oui, nous le faisons pour garder la propriété de Suricata entre les mains d'une seule entité : l' Open Information Security Foundation. Voir http://suricata.io/about/open-source/ et http://suricata.io/about/contribution-agreement/
