BRL-CAD

Les projets qui suivent les meilleures pratiques ci-dessous seront en mesure de s'auto-certifier et de montrer qu'ils ont obtenu le badge de la Core Infrastructure Initiative (CII).

Il n'existe aucun ensemble de pratiques qui garantissent que ce logiciel n'aura jamais de défauts ou de vulnérabilités ; même les méthodes formelles peuvent échouer si les spécifications ou les hypothèses sont fausses. Il n'y a pas non plus de pratiques qui peuvent garantir qu'un projet permettra de maintenir une communauté de développement saine et qui fonctionne bien. Toutefois, suivre les meilleures pratiques peut contribuer à améliorer les résultats des projets. Par exemple, certaines pratiques permettent la revue par plusieurs personnes avant publication, ce qui peut aider à trouver des vulnérabilités techniques difficiles à trouver autrement et à renforcer la confiance et un désir d'interaction répétée entre les développeurs de différentes entreprises. Pour gagner un badge, tous les critères DOIT et NE DOIT PAS doivent être satisfaits, tous les critères DEVRAIT doivent être satisfaits OU non satisfaits avec justification, et tous les critères PROPOSÉ doivent être satisfaits OU non satisfaits (nous voulons au moins qu'ils soient considérés). Les commentaires sont les bienvenus via le site GitHub en tant que problèmes ou pull requests. Il existe également une liste de diffusion pour discussion générale.

Nous fournissons volontiers l'information dans plusieurs langues, cependant, s'il existe un conflit ou une contradiction entre les traductions, la version anglaise est la version qui fait autorité.
Si c'est votre projet, veuillez indiquer votre statut de badge sur votre page de projet ! Le statut du badge ressemble à ceci : Le niveau de badge pour le projet 66 est passing Voici comment l'intégrer :
Vous pouvez afficher votre statut de badge en incorporant ceci dans votre fichier markdown :
[![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/66/badge)](https://bestpractices.coreinfrastructure.org/projects/66)
ou en incorporant ceci dans votre HTML :
<a href="https://bestpractices.coreinfrastructure.org/projects/66"><img src="https://bestpractices.coreinfrastructure.org/projects/66/badge"></a>


Ce sont les critères du niveau Or. Vous pouvez également afficher les critères des niveaux Basique ou Argent.



 Notions de base 0/5

  • Identification

    Notez que d'autres projets peuvent utiliser le même nom.

    BRL-CAD is an open source solid modeling system with interactive 3D geometry editing, high-performance ray tracing for rendering, hybrid representation geometry conversion, and processing for geometric analysis.

  • Conditions préalables


    Pas assez pour un badge.

    Le projet DOIT atteindre un badge de niveau argent. [achieve_silver]
  • Supervision du projet


    Informations inconnues requises, pas assez pour un badge.

    Le projet DOIT avoir un « facteur bus » de 2 ou plus. [bus_factor]
    Un « bus factor » (aussi connu en tant que « truck factor ») est le nombre minimum de membres du projet qui doivent disparaître soudainement d'un projet (« écrasé par un bus ») avant que le projet ne se bloque en raison du manque de personnel compétent. L'outil truck-factor peut l'estimer pour des projets sur GitHub. Pour plus d'informations, voir Évaluation du « bus factor » des dépôts Git par Cosentino et al.


    Informations inconnues requises, pas assez pour un badge.

    Le projet DOIT avoir au moins deux contributeurs significatifs non associés. [contributors_unassociated]
    Les contributeurs sont associés s'ils sont payés pour leur travail par la même organisation (en tant qu'employé ou contractuel) et si l'organisation bénéficie des résultats du projet. Les subventions financières ne comptent pas comme provenant de la même organisation si elles passent par d'autres organisations (par exemple, les subventions scientifiques versées à différentes organisations par un même gouvernement ou ONG ne rendent pas les contributeurs associés). Quelqu'un est un contributeur significatif s'il a apporté des contributions non triviales au projet au cours de la dernière année. Des exemples de bons indicateurs d'un contributeur significatif sont : écrit au moins 1 000 lignes de code, a contribué à 50 commits ou au moins 20 pages de documentation.

  • Autre


    Informations inconnues requises, pas assez pour un badge.

    Le projet DOIT inclure une déclaration de licence dans chaque fichier source. Cela PEUT être fait en incluant ce qui suit dans un commentaire près du début de chaque fichier : SPDX-License-Identifier : [expression d'une licence SPDX pour le projet] . [license_per_file]
    Cela PEUT également être fait en incluant une déclaration en langage naturel identifiant la licence. Le projet PEUT également inclure une URL stable indiquant le texte de la licence ou directement le texte complet de la licence. Notez que le critère license_location requiert que la licence du projet soit dans un emplacement standard. Voir ce didacticiel SPDX pour plus d'informations sur les expressions de licence SPDX. Notez la relation avec copyright_per_file, dont le contenu devrait généralement précéder les informations sur la licence.

 Contrôle des modifications 1/4

  • Dépôt source public sous contrôle de version


    Assez pour un badge !

    Le dépôt source du projet DOIT utiliser un logiciel courant de contrôle de version distribué (par exemple, git ou mercurial). [repo_distributed]
    Git n'est pas spécifiquement requis et les projets peuvent utiliser un logiciel de contrôle de version centralisé (comme subversion) avec justification.

    BRL-CAD uses both centralized and decentralized development, intentionally using centralized (SVN on Sourceforge) for primary development where we have strict validation and verification (V&V) requirements and a desire for enforced developer interaction inherent with the centralized model. We used decentralized (GIT on GitHub) for all our other work including website infrastructure, model management, and experimental projects.



    Informations inconnues requises, pas assez pour un badge.

    Le projet DOIT identifier clairement les petites tâches qui peuvent être effectuées par des contributeurs nouveaux ou occasionnels. [small_tasks]
    Cette identification se fait typiquement en marquant les problèmes sélectionnés dans un outil de suivi de problèmes avec une ou plusieurs étiquettes que le projet utilise à cet effet, par exemple up-for-grabs, first-timers-only, « Small fix », microtask ou IdealFirstBug. Ces nouvelles tâches n'ont pas besoin d'ajouter des fonctionnalités ; elles peuvent améliorer la documentation, ajouter des cas de test ou toute autre chose qui aide le projet et aide le contributeur à en comprendre davantage sur le projet.


    Informations inconnues requises, pas assez pour un badge.

    Le projet DOIT exiger l'authentification à deux facteurs (2FA) des développeurs pour changer un dépôt central ou accéder à des données sensibles (telles que des signalements de vulnérabilités privés). Ce mécanisme 2FA PEUT utiliser des mécanismes sans mécanismes cryptographiques tels que SMS, mais cela n'est pas recommandé. [require_2FA]

    Informations inconnues requises, pas assez pour un badge.

    L'authentification à deux facteurs du projet (2FA) DOIT utiliser des mécanismes cryptographiques pour empêcher l'emprunt d'identité. Une 2FA basée sur un service de messages courts (SMS), par elle-même, ne satisfait PAS à ce critère, car elle n'est pas chiffrée. [secure_2FA]
    Un mécanisme 2FA qui répond à ce critère serait une application de mot de passe à usage unique basé sur le temps (TOTP) qui génère automatiquement un code d'authentification qui change après un certain laps de temps. Notez que GitHub prend en charge TOTP.

 Qualité 2/7

  • Normes de codage


    Informations inconnues requises, pas assez pour un badge.

    Le projet DOIT documenter ses exigences en matière de revue de code, y compris la façon dont la revue de code est menée, ce qui doit être vérifié et ce qui est requis pour être acceptable. (URL requise) [code_review_standards]
    Voir aussi two_person_review et contribution_requirements.


    Informations inconnues requises, pas assez pour un badge.

    Le projet DOIT avoir au moins 50% de toutes les modifications proposées revues avant la sortie par une personne autre que l'auteur, afin de déterminer s'il s'agit d'une modification valable et sans problèmes connus qui risqueraient de s'opposer à son inclusion. [two_person_review]
  • Système de construction opérationnel


    Pas assez pour un badge.

    Le projet DOIT avoir une construction reproductible. Si aucune construction ne se produit (par exemple, les langages de script où le code source est utilisé directement au lieu d'être compilé), sélectionnez « non applicable » (N/A). (URL requise) [build_reproducible]
    Une construction reproductible signifie que plusieurs parties peuvent refaire indépendamment le processus de génération d'informations à partir de fichiers source et obtenir exactement le même résultat bit-à-bit. Dans certains cas, cela peut être résolu en forçant un ordre de tri. Les développeurs JavaScript peuvent envisager d'utiliser npm shrinkwrap et webpack OccurenceOrderPlugin. Les utilisateurs GGC et clang peuvent trouver l'option -frandom-seed utile. L'environnement de construction (y compris le jeu d'outils) peut souvent être défini pour les parties externes en spécifiant le hachage cryptographique d'un conteneur spécifique ou d'une machine virtuelle qu'ils peuvent utiliser pour la reconstruction. Le projet de construction reproductible dispose de documentation sur la façon de le faire.

    Reproducible builds are not currently supported as timestamps are intentionally embedded into all libraries and (by extension) all binaries.


  • Suite de tests automatisée


    Assez pour un badge !

    Une suite de tests DOIT être invocable d'une manière standard pour ce langage. [test_invocation]
    Par exemple, « make check », « mvn test » ou « rake test ».


    Assez pour un badge !

    Le projet DOIT utiliser une intégration continue, où le code nouveau ou modifié est fréquemment intégré dans un dépôt de code central et des tests automatisés sont exécutés sur le résultat. [test_continuous_integration]
    Dans la plupart des cas, cela signifie que chaque développeur qui travaille à plein temps sur le projet intègre son code au moins tous les jours.

    BuildBot is used for CI. The "distcheck-full" target in BRL-CAD's build system are run on BRL-CAD's central (SVN) code repository.



    Informations inconnues requises, pas assez pour un badge.

    Le projet DOIT avoir une ou des suites de tests automatisées FLOSS qui fournissent une couverture d'instructions d'au moins 90% s'il existe au moins un outil FLOSS qui peut mesurer ce critère dans le langage sélectionné. [test_statement_coverage90]

    Informations inconnues requises, pas assez pour un badge.

    Le projet DOIT avoir une ou des suites de tests automatisées FLOSS qui fournissent une couverture de branche d'au moins 80% s'il existe au moins un outil FLOSS qui peut mesurer ce critère dans le langage sélectionné. [test_branch_coverage80]

 Sécurité 3/5

  • Utiliser de bonnes pratiques de base de cryptographie

    Notez que certains logiciels n'ont pas besoin d'utiliser des mécanismes cryptographiques.

    Assez pour un badge !

    Le logiciel produit par le projet DOIT supporter des protocoles sécurisés pour toutes ses communications réseau, tels que SSHv2 ou ultérieur, TLS1.2 ou ultérieur (HTTPS), IPsec, SFTP et SNMPv3. Les protocoles non sûrs tels que FTP, HTTP, telnet, SSLv3 ou antérieur, et SSHv1 DOIVENT être désactivés par défaut et uniquement activés si l'utilisateur le configure spécifiquement. Si le logiciel produit par le projet ne prend pas en charge les communications réseau, sélectionnez « non applicable » (N/A). [crypto_used_network]

    There is un unencrypted network communication with an encrypted equivalent.



    Assez pour un badge !

    Le logiciel produit par le projet DOIT, s'il prend en charge ou utilise TLS, prendre en charge au moins TLS version 1.2. Notez que le prédécesseur de TLS s'appelait SSL. Si le logiciel n'utilise pas TLS, sélectionnez « non applicable » (N/A). [crypto_tls12]

    There is no SSL / TLS communication in BRL-CAD.


  • Livraison sécurisée contre les attaques man-in-the-middle (MITM)


    Pas assez pour un badge.

    Le site Web du projet, le dépôt (s'il est accessible via le Web) et le site de téléchargement (si séparé) DOIVENT inclure des en-têtes clés de durcissement avec des valeurs non admises. (URL requise) [hardened_site]
    Notez que GitHub est connu pour le faire. Des sites tels que https://securityheaders.io/ peuvent le vérifier rapidement. Les en-têtes clés de durcissement sont : Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (comme « nosniff »), X-Frame-Options et X-XSS-Protection.

    SourceForge supports X-Content-Type-Options nosniff. GitHub supports multiple. Project website and download site support none.


  • Autres problèmes de sécurité


    Informations inconnues requises, pas assez pour un badge.

    Le projet DOIT avoir effectué une évaluation de la sécurité au cours des 5 dernières années. Cette revue DOIT prendre en considération les exigences de sécurité et les limites de sécurité. [security_review]
    Cela PEUT être fait par les membres du projet et/ou une évaluation indépendante. Cette évaluation PEUT être soutenue par des outils d'analyse statiques et dynamiques, mais il doit aussi y avoir une revue par des humains pour identifier les problèmes (en particulier dans la conception) que les outils ne peuvent pas détecter.


    Assez pour un badge !

    Des mécanismes de durcissement DOIVENT être utilisés dans le logiciel produit par le projet afin que les défauts du logiciel soient moins susceptibles d'entraîner des vulnérabilités de sécurité. [hardening]
    Les mécanismes de durcissement peuvent inclure des en-têtes HTTP comme Content Security Policy (CSP), des options de compilation pour atténuer les attaques (telles que -fstack-protector) ou des options de compilation pour éliminer les comportements indéfinis. Pour nos besoins, le principe de plus faible privilège n'est pas considéré comme un mécanisme de durcissement (le principe de plus faible privilège est important, mais séparé).

    BRL-CAD extensively uses compiler flags (including -fstack-protector) and static analysis tools (Coverity) to minimize or eliminate undefined behavior. BRL-CAD has extensive testing strategies in place to detect security issues and unexpected behavior.


 Analyse 1/2

  • Analyse dynamique de code


    Pas assez pour un badge.

    Le projet DOIT appliquer au moins un outil d'analyse dynamique à tout candidat pour une version majeure du logiciel produit par le projet avant sa sortie. [dynamic_analysis]
    Un outil d'analyse dynamique examine le logiciel en l'exécutant avec des entrées spécifiques. Par exemple, le projet PEUT utiliser un outil de fuzzing (par exemple, American Fuzzy Lop) ou un scanner d'application Web (par exemple, OWASP ZAP ou w3af). Dans certains cas, le projet OSS-Fuzz peut être prêt à appliquer des tests de fuzzing à votre projet. Aux fins de ce critère, l'outil d'analyse dynamique doit varier les entrées d'une manière ou d'une autre pour rechercher différents types de problèmes ou être une suite de test automatisée avec au moins 80% de couverture de branche. La page Wikipedia sur l'analyse dynamique et la page OWASP sur le fuzzing identifient certains outils d'analyse dynamique. Le ou les outils d'analyse PEUVENT être axés sur la recherche de vulnérabilités de sécurité, mais cela n'est pas nécessaire.

    Dynamic analysis is not currently part of BRL-CAD's release repertoire, but several tools are used periodically and have been used in the past including gcov, valgrind, dmalloc, and purify.



    À peine suffisant pour un badge.

    Le projet DEVRAIT inclure de nombreuses assertions à l'exécution dans le logiciel qu'il produit, et vérifier ces assertions lors d'une analyse dynamique. [dynamic_analysis_enable_assertions]

    Dynamic analysis is not currently part of BRL-CAD's release repertoire, but several tools are used periodically and have been used in the past including gcov, valgrind, dmalloc, and purify.



Ces données sont disponibles sous licence Creative Commons Attribution version 3.0 (CC-BY-3.0) comme indiqué dans les conditions d'utilisation de la Core Infrastructure Initiative. Chacun peut librement partager et adapter les données, à condition de créditer leur origine. Veuillez créditer Christopher Sean Morrison et les contributeurs du badge des meilleures pratiques de la CII.

Soumission du badge du projet appartenant à : Christopher Sean Morrison.
Soumission créée le 2016-02-16 19:22:11 UTC, dernière mise à jour le 2016-08-26 22:10:07 UTC. Le dernier badge obtenu l'a été le 2016-08-22 03:14:40 UTC.

Retour