Kea

遵循以下最佳实践的项目将能够自愿的自我认证，并显示他们已经实现了核心基础设施计划（OpenSSF）徽章。

如果这是您的项目，请在您的项目页面上显示您的徽章状态！徽章状态如下所示： 项目98的徽章级别为passing 这里是如何嵌入它：

这些是通过级别条款。您还可以查看白银或黄金级别条款。

        

 基本 13/13 ●

  • 识别

    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.

    用什么编程语言实现项目？

  • 基本项目网站内容


    足够获得徽章！

    项目网站必须简明扼要地描述软件的作用（它解决了什么问题？）。 [description_good]

    KEA is an open source DHCPv4/DHCPv6 server 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.


    足够获得徽章！

    项目网站必须提供有关如何获取和提供反馈（错误报告或增强功能）以及如何贡献的信息。 [interact]

    There is an open issue tracker databaseat https://gitlab.isc.org/isc-projects/kea/-/issues that is read/writeable. Contributor guidelines are here: https://gitlab.isc.org/isc-projects/kea/-/blob/master/CONTRIBUTING.md.


    足够获得徽章！

    关于如何贡献的信息必须解释贡献流程（例如，是否使用拉请求？） (需要网址) [contribution]

    Contributor guidelines are here: https://gitlab.isc.org/isc-projects/kea/-/blob/master/CONTRIBUTING.md. We ask contributors to create an account on our Gitlab repository and request a project allocation. Then they can create a merge request with their contribution. They will have to follow our code review and unit testing guidelines as well as our coding standards. We recommend anyone contemplating a large contribution open an issue first to discuss their proposed design.


    足够获得徽章！

    关于如何贡献的信息应包括对可接受的贡献的要求（例如，引用任何所需的编码标准）。 (需要网址) [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."


  • FLOSS许可证

    项目使用什么许可证发布？


    足够获得徽章！

    项目生产的软件必须作为FLOSS发布。 [floss_license]

    https://www.isc.org/download/#Kea


    足够获得徽章！

    建议由项目生成的软件的任何必需的许可证是由开放源码促进会（OSI）批准的许可证（英文）。 [floss_license_osi]

    足够获得徽章！

    项目必须将其许可证在其源代码存储库中的标准位置发布。 (需要网址) [license_location]

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


  • 文档


    足够获得徽章！

    项目必须为项目生成的软件提供基本文档。 [documentation_basics]

    https://kea.readthedocs.io/en/latest/


    足够获得徽章！

    项目必须提供描述项目生成的软件的外部接口（输入和输出）的参考文档。 [documentation_interface]

    https://kea.readthedocs.io/en/latest/


  • 其他


    足够获得徽章！

    项目网站（网站，存储库和下载URL）必须使用TLS支持HTTPS。 [sites_https]

    https://www.isc.org/download/#Kea https://gitlab.isc.org/isc-projects/kea


    足够获得徽章！

    该项目必须有一个或多个讨论机制（包括建议的更改和问题），可搜索，允许通过URL访问消息和主题，使新人能够参与一些讨论，并且不需要客户端安装专有软件。 [discussion]

    https://gitlab.isc.org/isc-projects/kea/-/issues, https://lists.isc.org/pipermail/kea-users/, also a clone on github: https://github.com/isc-projects/kea/ (although a great majority of discussions happens on our hosted instance of gitlab).


    足够获得徽章！

    项目应该提供英文文档，并能够接受英文的代码的错误报告和评论。 [english]

    https://gitlab.isc.org/isc-projects/kea/-/issues https://kea.readthedocs.io/en/latest/


    足够获得徽章！

    必须维护该项目。 [maintained]


（高级）哪些用户还有额外权限编辑此徽章条目？目前：[9656]



  • 公开的版本控制的源代码存储库


    足够获得徽章！

    该项目必须有一个版本控制的源代码存储库。它必须是公开可读的并可通过URL访问。 [repo_public]

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


    足够获得徽章！

    项目的源代码存储库必须跟踪所做的更改，谁进行了更改，何时进行了更改。 [repo_track]

    https://gitlab.isc.org/isc-projects/kea/-/commits/master


    足够获得徽章！

    为了实现协作检视，项目的源代码存储库必须包括临时版本，以便检视版本之间的变化；它不得仅包括最终版本。 [repo_interim]

    足够获得徽章！

    建议使用通用分布式版本控制软件（例如，git）作为项目的源代码存储库。 [repo_distributed]

    We use git - our primary repository is a self-hosted instance of Gitlab, with a mirror on Github. https://gitlab.isc.org/isc-projects/kea


  • 唯一版本编号


    足够获得徽章！

    项目生成的用于每个用户使用的版本必须具有唯一版本标识符。 [version_unique]

    足够获得徽章！

    建议使用语义版本控制（SemVer）格式进行发布。 [version_semver]

    We have only issued a few versions so far. Those are consistent with the SemVer format.


    足够获得徽章！

    建议项目识别其版本控制系统中的每个版本。例如，建议使用git的项目，使用git标签识别每个版本。 [version_tags]

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


  • 发行说明


    足够获得徽章！

    该项目必须在每个版本中提供发布说明，这是该版本中主要变化的可读的摘要，以帮助用户确定是否应升级，升级影响将如何。发行说明不能是版本控制日志的原始输出（例如，“git log”命令结果不是发行说明）。其产出不适用于多个地点的项目（如单个网站或服务的软件），并采用持续交付，可以选择“N/A”。 (需要网址) [release_notes]

    We issue release notes with every release, which include the changelog for changes since the prior version. https://gitlab.isc.org/isc-projects/kea/-/releases


    足够获得徽章！

    发行说明必须列出每个新版本中修复的每个公开的漏洞。如果没有发行说明或者没有公开的漏洞，选择“不适用”。 [release_notes_vulns]

    We have a pretty mature system for vulnerability handling, documented here: https://kb.isc.org/docs/aa-00861 We have had very few reportable CVEs in Kea, but they are well documented, in the Mitre Database as well as in our own release notes and knowledgebase. ISC is a CNA. Example CVE for Kea: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6474


  • 错误报告流程


    足够获得徽章！

    项目必须为用户提交错误报告（例如，使用问题跟踪器或邮件列表）提供相关流程。 (需要网址) [report_process]

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


    足够获得徽章！

    项目必须使用问题跟踪器来跟踪每个问题。 [report_tracker]

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


    足够获得徽章！

    该项目必须响应过去2-12个月内（含）提交的大多数错误报告；响应不需要包括修复。 [report_responses]

    We address the majority of relevant bug reports much faster than 12 months. We do include a lot of 'to do' items in our issue tracker, it is not only bugs, and some of those linger for a while. We have some reports on the time taken in the various steps in the process here: https://gitlab.isc.org/isc-projects/kea/-/value_stream_analytics


    足够获得徽章！

    该项目应该对过去2-12个月内（包括）的大部分（> 50％）的增强请求作出回应。 [enhancement_responses]

    We address the majority of relevant enhancement requests much faster than 12 months. The project is quite active. We do include a lot of 'to do' items in our issue tracker, it is not only bugs, and some of those linger for a while.


    足够获得徽章！

    该项目必须有一个公开的报告和回复的档案供后续搜索。 (需要网址) [report_archive]

    Our repository is open, if this means issue reports. The following link will give you all the closed issue reports. https://gitlab.isc.org/isc-projects/kea/-/issues?scope=all&utf8=✓&state=closed


  • 漏洞报告流程


    足够获得徽章！

    项目必须在项目网站上发布报告漏洞的流程。 (需要网址) [vulnerability_report_process]

    https://www.isc.org/security-report/


    足够获得徽章！

    如果支持私有漏洞报告，项目必须包括如何以保密的方式发送信息。 (需要网址) [vulnerability_report_private]

    https://www.isc.org/security-report/

    You can email us at security-officer@isc.org, ideally using encrypted email. Reports to this alias are responded to immediately by a member of our security incident team. We would then create an issue in Gitlab, and make that issue 'confidential' until it is published and the issue disclosed as a CVE (if the report turns out to be accurate).


    足够获得徽章！

    该项目在过去6个月收到的任何漏洞报告的初始响应时间必须小于或等于14天。 [vulnerability_report_response]

    Our process is well with this - normally we respond to security issues within the hour. Kea has not had any security reports in the past 6 months however.


  • 可工作的构建系统


    足够获得徽章！

    如果项目生成的软件需要构建使用，项目必须提供可以从源代码自动重新构建软件的可工作的构建系统。 [build]

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

    Our CI build system is integrated with our repo.


    足够获得徽章！

    建议使用通用工具来构建软件。 [build_common_tools]

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

    Our CI build system is integrated with our repo. We do still use an older Jenkins-based system for some testing as well. https://jenkins.isc.org


    足够获得徽章！

    该项目应该仅使用FLOSS工具来构建。 [build_floss_tools]

  • 自动测试套件


    足够获得徽章！

    该项目必须使用至少一个作为FLOSS公开发布的自动测试套件（该测试套件可以作为单独的FLOSS项目维护）。 [test]

    Unit tests are part of the main project repo. https://gitlab.isc.org/isc-projects/kea/-/blob/master/CONTRIBUTING.md


    足够获得徽章！

    测试套件应该以该语言的标准方式进行调用。 [test_invocation]

    We document how to run tests here https://gitlab.isc.org/isc-projects/kea/-/blob/master/CONTRIBUTING.md#running-unit-tests We use "make check". We also developed a system/conformance test suite called ISC Forge, available here: github.com/isc-projects/forge. It is being run as part of our CI system, after each commit. We also have automated perfomance tests using perfdhcp (part of the Kea source tree).


    足够获得徽章！

    建议测试套件覆盖大部分（或理想情况下所有）代码分支，输入字段和功能。 [test_most]

    This is of course a goal. We also have system-level tests, compliance and performance tests. We have developed and published tools for performance tests and protocol compliance testing.


    足够获得徽章！

    建议项目实施持续集成，将新的或更改的代码经常集成到中央代码库中，并对结果进行自动化测试。 [test_continuous_integration]

    We use GitlabCI (https://gitlab.isc.org/isc-projects/kea/-/pipelines) and also have internal Jenkins system that runs additional tests, such as coverage, conformance, negative, performance and other test types.


  • 新功能测试


    足够获得徽章！

    该项目必须有通用的策略（正式或非正式），当主要的新功能被添加到项目生成的软件中，该功能的测试应该同时添加到自动测试套件。 [test_policy]

    We adhere to this strictly, as explained in our Contribution guidelines. (https://gitlab.isc.org/isc-projects/kea/-/blob/master/CONTRIBUTING.md)


    足够获得徽章！

    该项目必须有证据表明，在项目生成的软件的最近重大变化中，已经遵守了添加测试的条款： test_policy 。 [tests_are_added]

    If you look at any major merge request you can see the results of the CI tests. We use danger and other standard tools to check for compliance to our commit requirements.


    足够获得徽章！

    建议您在更改提案的说明文档中添加测试策略要求（请参阅test_policy）。 [tests_documented_added]

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


  • 警告标志


    足够获得徽章！

    该项目必须启用一个或多个编译器警告标志，“安全”语言模式，或者使用单独的“linter”工具查找代码质量错误或常见的简单错误，如果至少有一个FLOSS工具可以在所选择的语言实现此条款。 [warnings]

    Yes, our standard CI process includes linter tools.


    足够获得徽章！

    该项目必须处理警告。 [warnings_fixed]

    We are a bit behind in addressing some of our static analysis results (https://scan.coverity.com/projects/kea?tab=overview).


    足够获得徽章！

    建议在实际情况下，项目以最严格方式对待项目生成的软件中的告警。 [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.


  • 安全开发知识


    足够获得徽章！

    该项目必须至少有一个主要开发人员知道如何设计安全软件。 [know_secure_design]

    足够获得徽章！

    该项目的主要开发人员中，至少有一个必须知道导致这类型软件漏洞的常见错误类型，以及至少有一种方法来对付或缓解这些漏洞。 [know_common_errors]

  • 使用基础的良好加密实践

    请注意，某些软件不需要使用加密机制。

    足够获得徽章！

    项目生成的软件默认情况下，只能使用由专家公开发布和审查的加密协议和算法（如果使用加密协议和算法）。 [crypto_published]

    We use external libraries for our cryptographic requirements. (Botan or OpenSSL)


    足够获得徽章！

    如果项目生成的软件是应用程序或库，其主要目的不是实现加密，那么它应该只调用专门设计实现加密功能的软件，而不应该重新实现自己的。 [crypto_call]

    We use external libraries for our cryptographic requirements. (Botan or OpenSSL)


    足够获得徽章！

    项目所产生的软件中，所有依赖于密码学的功能必须使用FLOSS实现。 [crypto_floss]

    We use external libraries for our cryptographic requirements. (Botan or OpenSSL)


    足够获得徽章！

    项目生成的软件中的安全机制使用的默认密钥长度必须至少达到2030年（如2012年所述）的NIST最低要求。必须提供配置，以使较小的密钥长度被完全禁用。 [crypto_keylength]

    We use external libraries for our cryptographic requirements. (Botan or OpenSSL)


    足够获得徽章！

    项目产生的软件中的默认安全机制不得取决于已被破解的密码算法（例如，MD4，MD5，单DES，RC4，Dual_EC_DRBG）或使用不适合上下文的密码模式（例如，ECB模式几乎不适当，因为它揭示了密文中相同的块，如 ECB企鹅所示。CTR模式通常是不合适的，因为如果重复输入状态，则它不执行认证并导致重复）。 [crypto_working]

    We may MD5 for generating pseudo random numbers, but this is really not a crypto function.


    足够获得徽章！

    由项目产生的软件中的默认安全机制不应该依赖于具有已知严重弱点的加密算法或模式（例如，SHA-1密码散列算法或SSH中的CBC模式）。 [crypto_weaknesses]

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


    足够获得徽章！

    项目产生的软件中的安全机制应该​​对密钥协商协议实施完美的前向保密（PFS），如果长期密钥集合中的一个长期密钥在将来泄露，也不能破坏从一组长期密钥导出的会话密钥。 [crypto_pfs]

    足够获得徽章！

    如果项目产生的软件存储用于外部用户认证的密码，则必须使用密钥拉伸（迭代）算法（例如，PBKDF2，Bcrypt或Scrypt）将密码存储为每用户盐值不同的迭代散列 。 [crypto_password_storage]

    This mainly applies to the authentication of Kea to external database backends. It is possible to build the software so that it does not store the credentials for Kea to authenticate with the external database (it stores an empty password). The result is the user is prompted to enter the password when Kea boots up and connects to the database.


    足够获得徽章！

    由项目生成的软件中的安全机制必须使用密码学安全的随机数生成器生成所有加密密钥和随机数，并且不得使用密码学不安全的生成器。 [crypto_random]

  • 安全交付防御中间人（MITM）的攻击


    足够获得徽章！

    该项目必须使用一种针对MITM攻击的传递机制。使用https或ssh + scp是可以接受的。 [delivery_mitm]

    We sign the tarballs distributed on the web site and the packages distributed from our package repository and our web site is https.


    足够获得徽章！

    不得通过http协议获取加密散列（例如，sha1sum）并直接使用，而不检查密码学签名。 [delivery_unsigned]

    our signatures are stored on our ftp site, they are signed by our private/public key pair https://www.isc.org/pgpkey/


  • 修正公开的漏洞


    足够获得徽章！

    被公开了超过60天的中等或更高严重程度的漏洞，必须被修复。 [vulnerabilities_fixed_60_days]

    https://www.cvedetails.com/product/32807/ISC-KEA.html?vendor_id=64


    足够获得徽章！

    项目在得到报告后应该迅速修复所有致命漏洞。 [vulnerabilities_critical_fixed]

    I am not sure how to prove this, given how extremely rare CVES are in this project.


  • 其他安全问题


    足够获得徽章！

    公共存储库不得泄漏旨在限制公众访问的有效私人凭证（例如，工作密码或私钥）。 [no_leaked_credentials]

  • 静态代码分析


    足够获得徽章！

    如果至少有一个FLOSS工具以所选择的语言实现此条款，则至少需要将一个静态代码分析工具应用于软件发布之前任何提议的主要生成版本。 [static_analysis]

    We use Coverity Scan (https://scan.coverity.com/projects/kea?tab=overview), cppcheck (on internal Jenkins), clang static analyzer (internal Jenkins), shellcheck


    足够获得徽章！

    建议至少有一个用于static_analysis标准的静态分析工具包括在分析语言或环境中查找常见漏洞的规则或方法。 [static_analysis_common_vulnerabilities]

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


    足够获得徽章！

    使用静态代码分析发现的所有中，高严重性可利用漏洞必须在确认后及时修复。 [static_analysis_fixed]

    We do treat all known vulnerabilities seriously. We do have security policy (https://kb.isc.org/docs/aa-00861) and depending on the severity suspend our regular schedule to work on fix asap ("all hands on deck" scenario for high severity), including fix in a monthly release, backporting fix to older stable releases, or issue operational notifications for low severity issues with easily applicable workarounds.


    足够获得徽章！

    建议每次提交或至少每天执行静态源代码分析。 [static_analysis_often]

    We do have an extensive CI environment. The static and dynamic analysis is run on each commit. While there are days without commits (holidays etc.), this approach ensures we have checks on every change.


  • 动态代码分析


    足够获得徽章！

    建议在发布之前，至少将一个动态分析工具应用于软件任何发布的主要生产版本。 [dynamic_analysis]

    We do use AFL. The fuzzing could definitely be improved and expanded, but it's being conducted in an automated and continuous way (the fuzzer hardware is shared between several projects, each running a certain number of days per month). We also run unit-tests with a thread sanitizer.


    足够获得徽章！

    建议如果项目生成的软件包含使用内存不安全语言编写的软件（例如C或C++），则至少有一个动态工具（例如，fuzzer或web应用扫描程序）与检测缓冲区覆盖等内存安全问题的机制例行应用。如果该项目生成的软件没有以内存不安全语言编写，请选择“不适用”（N / A）。 [dynamic_analysis_unsafe]

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


    足够获得徽章！

    建议由项目生成的软件包括许多运行时断言，在动态分析期间检查。 [dynamic_analysis_enable_assertions]

    Kea production code handles error situations with C++ exceptions. There's a configuration (--with-gtests or --with-gtest-source) available that validates the exceptions with massive amounts of asserts. A quick grep showed 17000+ asserts in our source code. Note we're using ASSERT_NO_THROW, ASSERT_THROW and similar macros from gtest suite.


    足够获得徽章！

    通过动态代码分析发现的所有严重性为中，高的可利用漏洞必须在确认后及时修复。 [dynamic_analysis_fixed]

    Yes, see the answer about medium and higher severity exploitable vulnerabilities above. We use the same process, regardless of the source of the vulnerability (found by dynamic code analysis, discovered by QA team, reported externally etc).



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.

项目徽章条目拥有者： Vicky Risk.
最后更新于 2016-05-03 15:46:35 UTC, 最后更新于 2025-02-06 12:43:24 UTC。 最后在 2021-03-22 15:34:49 UTC 获得通过徽章。

后退