Kea

Les projets qui suivent les meilleures pratiques ci-dessous peuvent s'auto-certifier et montrer qu'ils ont obtenu le badge de la Open Source Security Foundation (OpenSSF).

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 98 est passing Voici comment l'intégrer :

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

        

 Notions de base 15/17 ●

  • Identification

    KEA is an open source DHCPv4/DHCPv6 server being developed and maintained by ​Internet Systems Consortium. The objective of this project is to provide a very high-performance, extensible DHCP server engine for use by enterprises and service providers, either as is or with extensions and modifications.

  • Conditions préalables


    Assez pour un badge !

    Le projet DOIT atteindre un badge de niveau basique. [achieve_passing]

  • Contenu basique du site Web du projet


    Assez pour un badge !

    Les informations sur la façon de contribuer DOIVENT inclure les exigences pour des contributions acceptables (par exemple, une référence à toute règle de codage requise). (URL requise) [contribution_requirements]

    Contributor guidelines are here: https://gitlab.isc.org/isc-projects/kea/-/blob/master/CONTRIBUTING.md. Coding standards are covered there, including this excerpt: "Placed in the root of the repository are files that formally describe the coding guidelines above as close as possible. They are .clang-format and .uncrustify.cfg used by clang-format and uncrustify respectively. If you want to format code automatically, you will need to have at least one of these tools installed. Since by default, these tools look for the closest style file located in one of the parent directories or, otherwise, in a default location, there are a a couple of helpful scripts i.e. ./tools/clang-format.sh and ./tools/uncrustify.sh to assure you that the Kea-owned file is used. They accept any number of customized parameters that would be passed to the underlying tool followed by any number of files and/or directories. Passing directories will have all non-generated C++ files under it formatted."


  • Supervision du projet


    Assez pour un badge !

    Le projet DEVRAIT avoir un mécanisme juridique par lequel tous les développeurs de quantités non triviales de logiciel du projet affirment qu'ils sont légalement autorisés à effectuer ces contributions. L'approche la plus commune et facilement mise en œuvre pour ce faire est d'utiliser un Certificat d'origine du développeur (DCO), où les utilisateurs ajoutent une information « sign-off-by » dans leurs commits et le projet pointe vers le site Web du DCO. Cependant, cela PEUT être mis en œuvre en tant que contrat de licence de contributeur (CLA), ou tout autre mécanisme juridique. (URL requise) [dco]

    DCO is included in the Contributing.md document in the top of the tree: https://gitlab.isc.org/isc-projects/kea/-/blob/master/CONTRIBUTING.md?ref_type=heads.


    Informations inconnues requises, pas assez pour un badge.

    Le projet DOIT définir et documenter clairement son modèle de gouvernance de projet (la façon dont il prend ses décisions, y compris les rôles clés). (URL requise) [governance]

    Assez pour un badge !

    Le projet DOIT adopter un code de conduite et le publier dans un lieu standard. (URL requise) [code_of_conduct]

    We do have Code of Conduct. It's a slightly modified Django CoC: https://gitlab.isc.org/isc-projects/kea/-/blob/master/code_of_conduct.md


    Informations inconnues requises, pas assez pour un badge.

    Le projet DOIT clairement définir et documenter publiquement les rôles clés dans le projet et leurs responsabilités, y compris les tâches que ces rôles doivent accomplir. Il DOIT être clairement exprimé qui a quel(s) rôle(s), mais cela pourrait ne pas être documenté de la même manière. (URL requise) [roles_responsibilities]

    Assez pour un badge !

    Le projet DOIT pouvoir continuer avec une interruption minimale si une personne décède, est invalidée ou ne peut/veut plus continuer à maintenir le projet. En particulier, le projet DOIT être en mesure de créer et de fermer des problèmes, d'accepter les modifications proposées et de publier des versions du logiciel, dans un délai d'une semaine après confirmation du retrait d'un individu du projet. Cela PEUT être fait en s'assurant que quelqu'un d'autre possède les clés, les mots de passe et les droits juridiques nécessaires pour poursuivre le projet. Les personnes qui exécutent un projet FLOSS PEUVENT faire cela en fournissant des clés dans un coffre-fort et un testament fournissant les droits légaux nécessaires (par exemple, pour les noms DNS). (URL requise) [access_continuity]

    There are several users who have admin rights for the gitlab Kea repository. They live in different regions (US, Czechia, Poland, UK). See Senior management tab on https://www.isc.org/team/


    Assez pour un badge !

    Le projet DEVRAIT avoir un « bus factor » de 2 ou plus. (URL requise) [bus_factor]

    Our bus factor is somewhere around 5. Here's a section about it: https://kea.readthedocs.io/en/kea-1.9.7/arm/security.html#bus-factor


  • Documentation


    Assez pour un badge !

    Le projet DOIT avoir une feuille de route documentée qui décrit ce que le projet a l'intention de faire et ne pas faire pour au moins l'année suivante. (URL requise) [documentation_roadmap]

    Kea operates on milestones. For the next couple (2-4) months, we have very detailed milestones with specific tasks for each monthly release. We have milestones for major releases (e.g. 2.x). List of milestones: https://gitlab.isc.org/isc-projects/kea/-/milestones


    Assez pour un badge !

    Le projet DOIT inclure la documentation de l'architecture (aussi appelée conception de haut niveau) du logiciel produit par le projet. Si le projet ne produit pas de logiciel, sélectionnez « non applicable » (N/A). (URL requise) [documentation_architecture]

    We do have Kea Developer's guide that discusses each Kea component, its architecture, major design choices and much more. Although this is generated with oxygen, we have a lot of text there explaining the big picture. https://jenkins.isc.org/job/Kea_doc/doxygen/


    Assez pour un badge !

    Le projet DOIT documenter ce à quoi l'utilisateur peut et ne peut pas s'attendre en termes de sécurité à partir du logiciel produit par le projet (ses « exigences de sécurité »). (URL requise) [documentation_security]

    See Section 23: Kea Security: https://kea.readthedocs.io/en/kea-1.9.7/arm/security.html


    Assez pour un badge !

    Le projet DOIT fournir un guide de « démarrage rapide » pour les nouveaux utilisateurs afin de les aider à faire rapidement quelque chose avec le logiciel. (URL requise) [documentation_quick_start]

    We do have Quick Start section in the Kea ARM: https://kea.readthedocs.io/en/kea-1.8.2/arm/quickstart.html


    Assez pour un badge !

    Le projet DOIT faire un effort pour maintenir la documentation conforme à la version actuelle des résultats du projet (y compris les logiciels produits par le projet). Tous les défauts de la documentation connus la rendant incohérente DOIVENT être corrigés. Si la documentation est généralement à jour, mais inclut de manière erronée certaines informations antérieures qui ne sont plus vraies, considérez cela comme un défaut, puis faites le suivi et corrigez comme d'habitude. [documentation_current]

    We maintain multiple doc versions, one per release. See https://kea.readthedocs.io/en/kea-1.8.2/index.html (click on version in the lower left corner to switch between doc versions). We have mark tickets that address doc problems or require doc problems with a dedicated label. As of time of writing, there were 201 closed doc tickets, with 68 still open. Up to date list: https://gitlab.isc.org/isc-projects/kea/-/boards/18?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=doc


    Assez pour un badge !

    La page d'accueil et/ou le site Web du dépôt du projet DOIVENT identifier et pointer tous les accomplissements, y compris ce badge sur les meilleures pratiques, dans les 48 heures suivant la reconnaissance publique que l'accomplissement a été atteint. (URL requise) [documentation_achievements]

    We show several badges, including CII: https://gitlab.isc.org/isc-projects/kea


  • Accessibilité et internationalisation


    Assez pour un badge !

    Le projet (à la fois les sites du projet et les résultats du projet) DEVRAIT suivre les meilleures pratiques d'accessibilité afin que les personnes handicapées puissent encore participer au projet et utiliser les résultats du projet où il est raisonnable de le faire. [accessibility_best_practices]

    Kea is a command-line tool, so in principle is accessibility friendly. Our website and documentation use basic technologies that should be screen reader friendly. We use industry standards (github, gitlab, mailman mailing list) for providing a variety of access methods.


    Assez pour un badge !

    Le logiciel produit par le projet DEVRAIT être internationalisé pour permettre une localisation facile pour la culture, la région ou la langue du public cible. Si l'internationalisation (i18n) ne s'applique pas (par exemple, le logiciel ne génère pas de texte destiné aux utilisateurs finaux et ne trie pas de texte lisible par les humains), sélectionnez « non applicable » (N/A). [internationalization]

    Kea software uses .mes files that list all possible messages Kea can print. Those files can be translated, including the descriptive paragraphs for each message. However, due to massive complexity of the software, so far we are not aware of any translation attempts. Details here: https://kea.readthedocs.io/en/kea-1.8.2/kea-messages.html


  • Autre


    Assez pour un badge !

    Si les sites du projet (site Web, dépôt et URL de téléchargement) entreposent des mots de passe pour l'authentification d'utilisateurs externes, les mots de passe DOIVENT être entreposés comme hachages itérés avec salage par utilisateur en utilisant un algorithme d'étirement des clés (itéré) (par exemple, Argon2id, Bcrypt, Scrypt, ou PBKDF2). Si les sites du projet n'entreposent pas de mots de passe à cette fin, sélectionnez « non applicable » (N/A). [sites_password_security]

    We use github and gitlab.


  • Versions précédentes


    Assez pour un badge !

    Le projet DOIT maintenir les anciennes versions les plus utilisées du produit ou fournir un chemin de mise à niveau vers des versions plus récentes. Si le chemin de mise à niveau est difficile, le projet DOIT documenter comment effectuer la mise à niveau (par exemple, les interfaces qui ont changé et une suggestion d'étapes détaillées pour aider la mise à niveau). [maintenance_or_update]

    We do have 3 stable branches. As of time writing, this was stable 1.6, stable 1.8 and development 1.9. All versions are available as sources on our FTP site (http://ftp.isc.org/isc/kea/) and native packages (cloudsmith.io/~isc/repos/). The general upgrade procedure is well documented in the Kea ARM, especially the kea-admin tool section that involves database upgrades (https://kea.readthedocs.io/en/kea-1.8.2/arm/admin.html). We recently started adding section in the release notes to warn about potential pitfalls and incompatible changes (https://gitlab.isc.org/isc-projects/kea/-/wikis/release%20notes/release-notes-1.9.4#incompatible-changes). Our changelog lists incompatible changes with an asterisk. For ancient (pre 1.6 versions), we do have a migration document: https://gitlab.isc.org/isc-projects/kea/-/wikis/migrating-to-kea-1.6


  • Procédure de signalement des bogues


    Assez pour un badge !

    Le projet DOIT utiliser un suivi des problèmes pour le suivi des problèmes individuels. [report_tracker]

    https://gitlab.isc.org/isc-projects/kea/-/issues


  • Processus de signalement de vulnérabilité


    Assez pour un badge !

    Le projet DOIT créditer les auteurs de tous les signalements de vulnérabilité résolus au cours des 12 derniers mois, à l'exception des auteurs qui demandent l'anonymat. S'il n'y a pas eu de vulnérabilité résolue au cours des 12 derniers mois, sélectionnez « non applicable » (N/A). (URL requise) [vulnerability_report_credit]

    Kea enjoys very thorough, massive testing process (6000 unit-tests, 1500 system tests) and multiple automated tools (coverity scan, cppcheck, valgrind, thread sanitizer, shellcheck, danger, etc), fuzzing (afl) and stability tests (perfdhcp). We haven't had a security incident in well over a year.


    Assez pour un badge !

    Le projet DOIT avoir un processus documenté pour répondre aux signalements de vulnérabilité. (URL requise) [vulnerability_response_process]

    We do have it: https://kb.isc.org/docs/aa-00861 and https://www.isc.org/reportbug/. Also, our gitlab has a note how to report vulnerability reports, see the bug template: https://gitlab.isc.org/isc-projects/kea/-/blob/master/.gitlab/issue_templates/bug_report.md We do have similar note for github.


  • Normes de codage


    Assez pour un badge !

    Le projet DOIT identifier les guides de style de codage spécifiques pour les langages principaux qu'il utilise, et exiger que les contributions le respectent en général. (URL requise) [coding_standards]

    Sure we do. I can't imagine having a large project without coding guidelines: https://gitlab.isc.org/isc-projects/kea/-/wikis/Processes/coding-guidelines


    Pas assez pour un badge.

    Le projet DOIT imposer automatiquement son ou ses styles de codage sélectionnés s'il existe au moins un outil FLOSS qui peut le faire dans le(s) langage(s) sélectionné(s). [coding_standards_enforced]

    We don't enforce it yet, because of large amounts of legacy code and lots of merge requests being constantly in progress.


  • Système de construction opérationnel


    Assez pour un badge !

    Les systèmes de construction pour les binaires natifs DOIVENT honorer les variables (d'environnement) pertinentes du compilateur et du lieur qui leur sont transmises (par exemple, CC, CFLAGS, CXX, CXXFLAGS et LDFLAGS) et les transmettre aux invocations du compilateur et du lieur. Un système de construction PEUT les étendre avec des options supplémentaires ; il NE DOIT PAS simplement remplacer les valeurs fournies par les siennes. Si aucun fichier binaire natif n'est généré, sélectionnez « non applicable » (N/A). [build_standard_variables]

    We're using autotools (autoconf, automake and friends) and do our best to play by the rules. Details here: https://kea.readthedocs.io/en/kea-1.8.2/arm/install.html#configure-before-the-build


    Assez pour un badge !

    Le système de construction et d'installation DEVRAIT préserver les informations de débogage si elles sont demandées dans les options correspondants (par exemple, « install -s » n'est pas utilisé). S'il n'y a pas de système de construction ou d'installation (par exemple, les bibliothèques JavaScript typiques), sélectionnez « non applicable » (N/A). [build_preserve_debug]

    We try to provide flexible environment. The user can specify whatever debugging options for g++ he/she wishes. We also have --enable-debug that conveniently enables -O0 -g and couple other things. It's by no means mandatory and user can specify or tweak flags as desired.


    Informations inconnues requises, pas assez pour un badge.

    Le système de construction pour le logiciel produit par le projet NE DOIT PAS reconstruire de manière récursive des sous-répertoires s'il existe des dépendances croisées dans les sous-répertoires. S'il n'y a pas de système de construction ou d'installation (par exemple, les bibliothèques JavaScript typiques), sélectionnez « non applicable » (N/A). [build_non_recursive]

    Assez pour un badge !

    Le projet DOIT pouvoir répéter le processus de génération d'informations à partir de fichiers source et obtenir exactement le même résultat bit-à-bit. Si aucune construction ne se produit (par exemple, dans les langages de script où le code source est utilisé directement au lieu d'être compilé), sélectionnez « non applicable » (N/A). [build_repeatable]

    running make distcheck is part of our build process and it's verified after each commit that's merged on master.


  • Système d'installation


    Assez pour un badge !

    Le projet DOIT fournir un moyen d'installer et de désinstaller facilement le logiciel produit par le projet en utilisant une convention couramment utilisée. [installation_common]

    User who like to compile can do the usual make install, make uninstall. We also provide native (DEB, RPM, APK) packages for many distros that make the installation and removal easy. The nature of this project (DHCP server) implies that some manual configuration is necessary.


    Assez pour un badge !

    Le système d'installation pour les utilisateurs finaux DOIT honorer les conventions standard pour sélectionner l'emplacement où les artefacts construits sont écrits au moment de l'installation. Par exemple, s'il installe des fichiers sur un système POSIX, il DOIT honorer la variable d'environnement DESTDIR. S'il n'y a pas de système d'installation ou pas de convention standard, sélectionnez « non applicable » (N/A). [installation_standard_variables]

    Yes, we're using normal autoconf/automake regime. --prefix and more detailed switches (--bindir, --sbindir, --libexecdir, --runstatedir and more) are available.


    Assez pour un badge !

    Le projet DOIT fournir un moyen pour les développeurs potentiels d'installer rapidement tous les résultats du projet ainsi que l'environnement nécessaire pour apporter des modifications, y compris les tests et l'environnement de test. Cela DOIT être effectué avec une convention couramment utilisée. [installation_development_quick]

    We do have a Developer's guide that explains how to set up the test environment to run unit-tests. Also have a dedicated tool named hammer that can automate installing Kea on bare metal or spin up VMs with requested mandatory and optional dependencies. For details, see https://gitlab.isc.org/isc-projects/kea/-/blob/master/hammer.py.


  • Composants maintenus à l'extérieur


    Assez pour un badge !

    Le projet DOIT afficher ses dépendances externes de manière analysable par ordinateur. (URL requise) [external_dependencies]

    Kea can be compiled using GNU autotools (with using automated configure script) or installed using native (DEB, RPM or APK) packages. The autotools automatically detect presence or absence of external dependencies. The packages have listed external dependencies, so they're installed automatically. Details in the package scripts: https://gitlab.isc.org/isc-projects/kea-packaging


    Informations inconnues requises, pas assez pour un badge.

    Les projets DOIVENT surveiller ou vérifier périodiquement leurs dépendances externes (y compris les copies de commodité) pour détecter les vulnérabilités connues, et corriger les vulnérabilités exploitables ou les vérifier comme inexploitables. [dependency_monitoring]

    Assez pour un badge !

    Le projet DOIT :
    1. rendre facile l'identification et la mise à jour des composants maintenus extérieurement au projet ; ou
    2. utiliser des composants standards fournis par le système ou le langage de programmation.
    Ensuite, si une vulnérabilité se trouve dans un composant réutilisé, il sera facile de mettre à jour ce composant. [updateable_reused_components]

    Kea has a -W option that lists external dependencies used during compilation, including their versions. The configure script (typical GNU autotools) provide an option to use alternative components (such as patched dependency in non-standard location). The dependencies are well documented in the Kea ARM document (see https://kea.readthedocs.io/en/kea-1.8.2/arm/intro.html#required-software-at-run-time).


    Assez pour un badge !

    Le projet DEVRAIT éviter d'utiliser des fonctions et des API obsolètes quand des alternatives FLOSS sont disponibles dans l'ensemble de technologies qu'il utilise (sa « pile de technologies ») et disponibles à une large majorité des utilisateurs supportés par le projet (afin que les utilisateurs puissent avoir accès à l'alternative). [interfaces_current]

    We try to not use deprecated or obsolete functions and APIs. When possible, we print out a warning that a dependency (e.g. openssl) is too old and we disable TLS support in Kea. For some cases, e.g. CentOS 7, which still is popular, we attempt to provide alternatives, e.g. you need to install newer openssl. all the technology stack is open source (mostly gcc, but also flex, bison, and other smaller open source tools).


  • Suite de tests automatisée


    Assez pour un badge !

    Une suite de tests automatisée DOIT être appliquée à chaque commit dans un dépôt partagé pour au moins une branche. Cette suite de tests DOIT produire un rapport sur le succès ou l'échec du test. [automated_integration_testing]

    We do have a massive (6000+ unit-tests, 1500 system tests) test farm. It is run after each check-in.


    Assez pour un badge !

    Le projet DOIT ajouter des tests de régression à une suite de tests automatisée pour au moins 50% des bogues corrigés au cours des six derniers mois. [regression_tests_added50]

    We try to live by the TDD (test driven development) philosophy. Except some rare corner cases, each fix or new functionality has new unit tests. For non-trivial features or bugfixes system tests are frequently developed by an independent QA. Often the system tests are ready before the functionality is ready.


    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 80% s'il existe au moins un outil FLOSS qui peut mesurer ce critère dans le langage sélectionné. [test_statement_coverage80]

    We have developed a generic DHCP/DNS testing suite called ISC Forge. It's published under ISC license. See https://github.com/isc-projects/forge


  • Nouveau test de fonctionnalité


    Assez pour un badge !

    Le projet DOIT avoir une politique écrite formelle, que dès qu'une nouvelle fonctionnalité majeure est ajoutée, des tests pour la nouvelle fonctionnalité DOIVENT être ajoutés à une suite de tests automatisée. [test_policy_mandated]

    Yes, it's part of out coding guidelines: https://gitlab.isc.org/isc-projects/kea/-/wikis/Processes/coding-guidelines and https://gitlab.isc.org/isc-projects/kea/-/blob/master/CONTRIBUTING.md


    Assez pour un badge !

    Le projet DOIT inclure, dans ses instructions documentées pour les propositions de changement, la politique selon laquelle des tests doivent être ajoutés pour toute nouvelle fonctionnalité majeure. [tests_documented_added]

    https://gitlab.isc.org/isc-projects/kea/-/blob/master/CONTRIBUTING.md


  • Options d'avertissement


    Assez pour un badge !

    Les projets DOIVENT être maximalement stricts avec les avertissements dans le logiciel produit par le projet, quand cela est approprié. [warnings_strict]

    By default, our configure script enables the following extra switches in g++: -Wall -Wextra -Wnon-virtual-dtor -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -pthread -Wno-missing-field-initializers -fPIC. Note the -Wall and -Wextra. Many of our builds are run with -Werror. We do experiments with -Wpedantic sometimes, but we're not fully committed to that idea yet.


  • Connaissance du développement sécurisé


    Informations inconnues requises, pas assez pour un badge.

    Le projet DOIT implémenter des principes de conception sécurisés (à partir de « know_secure_design »), quand cela est approprié. Si le projet ne produit pas de logiciel, sélectionnez « non applicable » (N/A). [implement_secure_design]

  • Utiliser de bonnes pratiques de base de cryptographie

    Notez que certains logiciels n'ont pas besoin d'utiliser des mécanismes cryptographiques. Si votre projet produit un logiciel qui (1) inclut ou active la fonctionnalité de chiffrement, et (2) peut être publié des États-Unis (US) vers l'extérieur des États-Unis ou vers un citoyen autre qu'américain, vous pouvez être légalement obligé à faire quelques étapes supplémentaires. En règle générale, cela implique simplement l'envoi d'un email. Pour plus d'informations, consultez la section sur le chiffrement de Comprendre la technologie Open Source et les contrôles à l'exportation américains .

    Assez pour un badge !

    Les mécanismes de sécurité par défaut dans le logiciel produit par le projet NE DOIVENT PAS dépendre d'algorithmes ou de modes cryptographiques avec des faiblesses sérieuses connues (par exemple, l'algorithme de hachage cryptographique SHA-1 ou le mode CBC en SSH). [crypto_weaknesses]

    We use security for TSIG, but there is no default algorithm, it must be positively specified.


    Assez pour un badge !

    Le projet DEVRAIT supporter plusieurs algorithmes cryptographiques, afin que les utilisateurs puissent rapidement changer si l'un deux est cassé. Les algorithmes à clés symétriques courants incluent AES, Twofish et Serpent. Les alternatives d'algorithme de hachage cryptographique courantes incluent SHA-2 (y compris SHA-224, SHA-256, SHA-384 ET SHA-512) et SHA-3. [crypto_algorithm_agility]

    We support HMAC-MD5 (for backward compatibility), HMAC-SHA1, HMAC-SHA224, HMAC-SHA256, HMAC-SHA384 and HMAC-SHA512 in our TSIG implementation.


    Informations inconnues requises, pas assez pour un badge.

    Le projet DOIT supporter le stockage des informations d'authentification (comme les mots de passe et les jetons dynamiques) et des clés cryptographiques privées dans des fichiers distincts des autres informations (fichiers de configuration, bases de données et journaux) et permettre aux utilisateurs de les mettre à jour et de les remplacer sans recompilation de code. Si le projet ne traite jamais d'informations d'authentification et de clés cryptographiques privées, sélectionnez « non applicable » (N/A). [crypto_credential_agility]

    Assez pour un badge !

    Le logiciel produit par le projet DEVRAIT 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 DEVRAIENT ê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]

    As of April 2021, we have implemented TLS support in Kea.


    Assez pour un badge !

    Le logiciel produit par le projet DEVRAIT, 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]

    We support TLS 1.3. Details: https://kea.readthedocs.io/en/kea-1.9.7/arm/security.html#tls-https-support


    Assez pour un badge !

    Le logiciel produit par le projet DOIT, s'il prend en charge TLS, effectuer la vérification des certificats TLS par défaut lors de l'utilisation de TLS, y compris sur les sous-ressources. Si le logiciel n'utilise pas TLS, sélectionnez « non applicable » (N/A). [crypto_certificate_verification]

    Assez pour un badge !

    Le logiciel produit par le projet DOIT, s'il supporte TLS, effectuer une vérification de certificat avant d'envoyer des en-têtes HTTP avec des informations privées (telles que des cookies sécurisés). Si le logiciel n'utilise pas TLS, sélectionnez « non applicable » (N/A). [crypto_verification_private]

  • Livraison sécurisée


    Assez pour un badge !

    Le projet DOIT signer cryptographiquement les versions des résultats du projet destinées à une utilisation répandue, et il DOIT y avoir un processus documenté expliquant aux utilisateurs comment ils peuvent obtenir les clés de signature publique et vérifier la ou les signatures. La clé privée pour ces signature(s) NE DOIT PAS être sur le(s) site(s) utilisé(s) pour distribuer directement le logiciel au public. Si les versions ne sont pas destinées à une utilisation répandue, sélectionnez « non applicable » (N/A). [signed_releases]

    All releases are signed and each release notes document has a note about how to check them. See example here: https://gitlab.isc.org/isc-projects/kea/-/wikis/release%20notes/release-notes-1.9.5#download and a general instructions how to check the signatures: https://www.isc.org/pgpkey/


    Assez pour un badge !

    Il est PROPOSÉ que, dans le système de contrôle de la version, chaque tag d'une version importante (un tag faisant partie d'une version majeure, d'une version mineure ou qui corrige des vulnérabilités notées publiquement) soit cryptographiquement signé et vérifiable comme décrit dans signed_releases. [version_tags_signed]

    We use the standard capabilities of GITLAB. See details here: https://gitlab.isc.org/isc-projects/kea/-/releases


  • Autres problèmes de sécurité


    Assez pour un badge !

    Les résultats du projet DOIVENT vérifier toutes les entrées provenant de sources potentiellement non fiables pour s'assurer qu'elles sont valides (une liste blanche) et rejeter les entrées non valides, en cas de restrictions sur les données. [input_validation]

    DHCP often being the first packets exchanged with an unknown new device entering the network, we pay strict attention to data sanitization, including truncated, malformed, oversized fields, options and packets etc. The requests received over Kea management API undergo sanity checks before they're processed. We have substantial amount of system and unit tests that check for broken input. We also do fuzz testing for incoming packets and configuration files.


    Informations inconnues requises, pas assez pour un badge.

    Les 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]

    Informations inconnues requises, pas assez pour un badge.

    Le projet DOIT fournir une analyse de fiabilité qui justifie pourquoi ses exigences de sécurité sont respectées. L'analyse de fiabilité DOIT inclure : une description du modèle de menace, une identification claire des limites de confiance, un argument selon lequel des principes de conception sécurisés ont été appliqués et un argument selon lequel les faiblesses de sécurité courantes de l'implémentation ont été contrées. (URL requise) [assurance_case]

  • Analyse statique de code


    Assez pour un badge !

    Le projet DOIT utiliser au moins un outil d'analyse statique avec des règles ou des approches pour rechercher des vulnérabilités courantes dans le langage ou l'environnement analysé, s'il existe au moins un outil FLOSS qui peut mettre en œuvre ce critère dans le langage sélectionné. [static_analysis_common_vulnerabilities]

    Coverity Scan, cppcheck, danger, clang static analyzer, shellcheck


  • Analyse dynamique de code


    Assez pour un badge !

    Si le logiciel produit par le projet inclut un logiciel écrit à l'aide d'un langage non sûr pour les accès mémoire (par exemple C ou C++), alors le projet DOIT utiliser au moins un outil dynamique (par exemple, un fuzzer ou un scanneur d'application Web) utilisé de manière routinière en combinaison avec un mécanisme permettant de détecter des problèmes de sécurité mémoire tels que les dépassement mémoire. Si le projet ne produit pas de logiciel écrit dans un langage non sûr pour les accès mémoire, sélectionnez « non applicable » (N/A). [dynamic_analysis_unsafe]

    We run valgrind tests under Jenkins, use cppcheck, and thread sanitizer from clang.



This data is available under the Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). This means that a Data Recipient may share the Data, with or without modifications, so long as the Data Recipient makes available the text of this agreement with the shared Data. Please credit Vicky Risk and the OpenSSF Best Practices badge contributors.

Soumission du badge du projet appartenant à : Vicky Risk.
Soumission créée le 2016-05-03 15:46:35 UTC, dernière mise à jour le 2025-02-06 12:43:24 UTC. Le dernier badge obtenu l'a été le 2021-03-22 15:34:49 UTC.

Retour