TUF (The Update Framework)

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

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

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

        

 基本 17/17 ●

  • 识别

    A framework for securing software update systems.

  • 先决条件


    足够获得徽章！

    项目必须拥有通过徽章。 [achieve_passing]

  • 基本项目网站内容


    足够获得徽章！

    关于如何贡献的信息必须包括对可接受的贡献的要求（例如，引用任何所需的编码标准）。 (需要网址) [contribution_requirements]

    The contribution process is covered in below documents. It prescribes following a custom style guide, based on well-known public style guides. https://github.com/theupdateframework/python-tuf/contribute https://github.com/theupdateframework/python-tuf/blob/develop/docs/GOVERNANCE.md#contributions https://github.com/secure-systems-lab/code-style-guidelines/blob/master/python.md


  • 项目监督


    足够获得徽章！

    该项目应该有一个合法机制，所有对项目软件做出显著贡献的开发人员都声明他们有合法授权作出这些贡献。最常用且易于实施的方法是使用开发者原产地证书（DCO），用户可以在其提交中添加“signed-off-by”，另外，项目链接到DCO网站。本条款也可以使用贡献者许可协议（CLA）或其他法律机制实现。 (需要网址) [dco]

    https://github.com/theupdateframework/python-tuf/contribute

    In addition, an automatic DCO check is performed on all pull requests to the repository.


    足够获得徽章！

    该项目必须明确定义和记录其项目治理模式（决策方式，包括关键角色）。 (需要网址) [governance]

    The project clearly defines and documents its governance model in GOVERNANCE.md https://github.com/theupdateframework/python-tuf/blob/develop/docs/GOVERNANCE.md


    足够获得徽章！

    该项目必须采取行为守则，并将其发布在标准的位置。 (需要网址) [code_of_conduct]

    The project follows the CNCF code of conduct: https://github.com/theupdateframework/python-tuf/blob/develop/docs/CODE-OF-CONDUCT.md


    足够获得徽章！

    该项目必须明确定义和公开记录项目中的关键角色及其职责，包括这些角色必须执行的任务。必须清楚指出谁是什么角色，尽管这可能没有以相同的方式记录下来。 (需要网址) [roles_responsibilities]

    The project's GOVERNANCE.md and MAINTAINERS.txt clearly define the different roles and their responsibilities. https://github.com/theupdateframework/python-tuf/blob/develop/docs/GOVERNANCE.md https://github.com/theupdateframework/python-tuf/blob/develop/docs/MAINTAINERS.txt


    足够获得徽章！

    如果任何一个开发者丧失工作能力或丧生，该项目必须能够继续保持最小的中断。特别是，在确认个人无行为能力或死亡的一周内，项目必须能够创建和关闭问题，接受提议的更改和发布软件版本。这可以通过确保其他人有任何必要的密钥，密码和合法权利来继续该项目。运行FLOSS项目的个人可以通过在锁箱中提供密钥，并提供任何所需的合法权利（例如DNS名称）来实现。 (需要网址) [access_continuity]

    The project has more than three people with admin rights to the GitHub repository and multiple maintainers that can create and close issues, accept proposed changes, and release new versions of the software. https://github.com/theupdateframework/python-tuf/blob/develop/docs/MAINTAINERS.txt https://github.com/orgs/theupdateframework/people


    足够获得徽章！

    项目必须具有2个或更多的“公交车因子”。 (需要网址) [bus_factor]

    The project has a bus factor of over 2. https://github.com/theupdateframework/python-tuf/blob/develop/docs/MAINTAINERS.txt https://github.com/orgs/theupdateframework/people


  • 文档


    足够获得徽章！

    该项目必须有一个文档化的路线图，描述项目打算做什么，至少在下一年做什么。 (需要网址) [documentation_roadmap]

    The current roadmap is documented as GitHub project "TUF refactor towards 1.0.0" https://github.com/theupdateframework/python-tuf/projects

    Note: At the time of revising the badge criteria (January 2022), the project is reaching the end of the current long-term roadmap. Once finalized, a new roadmap will be published.


    足够获得徽章！

    该项目必须包括项目生成的软件的架构（也称为高级别设计）的文档。如果项目不产生软件，请选择“不适用”（N/A）。 (需要网址) [documentation_architecture]

    project specification: https://theupdateframework.github.io/specification/latest/ published papers: https://theupdateframework.io/publications/


    足够获得徽章！

    该项目必须书面记录用户从项目生成的软件的安全性上可以获得和不能指望的内容（其“安全需求”）。 (需要网址) [documentation_security]

    The project's security page and research papers document what users can expect in terms of security and threat model. https://theupdateframework.io/security/ https://theupdateframework.io/publications/ https://theupdateframework.io/papers/survivable-key-compromise-ccs2010.pdf?raw=true


    足够获得徽章！

    该项目必须为新用户提供“快速启动”指南，以帮助他们快速使用该软件。 (需要网址) [documentation_quick_start]

    The project provides excessively commented and easy-to-read Python code as usage examples for different usage scenarios. The examples are easy to find in the documentation. https://theupdateframework.readthedocs.io/en/latest/ (usage examples)


    足够获得徽章！

    项目必须努力使文档与当前版本的项目结果（包括项目生成的软件）保持一致。任何已知的文档缺陷使其不一致必须修正。如果文档基本是最新的，但是错误地包括一些不再是真实的旧信息，那么将其视为缺陷，然后像往常一样进行跟踪和修复。 [documentation_current]

    The project makes an effort to keep documentation up to date and encourages contributors to verify that any pull requests also update documentation for things that are modified. https://github.com/theupdateframework/tuf/blob/develop/.github/PULL_REQUEST_TEMPLATE.md


    足够获得徽章！

    项目存储代码库首页和/或网站必须在获得成就的48小时内标识并超链接任何成就，包括此最佳实践徽章。 (需要网址) [documentation_achievements]

    https://github.com/theupdateframework/python-tuf#-a-framework-for-securing-software-update-systems


  • 无障碍和国际化


    足够获得徽章！

    该项目（项目网站和项目成果）都应遵循无障碍最佳做法，使残疾人仍然可以参与项目，并在合理的情况下使用项目成果。 [accessibility_best_practices]

    The project website is built with the go Hugo static site generator and Bulma CSS framework, which does not require JavaScript and is 100% responsive. https://theupdateframework.io/ https://bulma.io/

    The reference documentation is hosted on readthedocs using the standard Sphinx RTD Theme, which has several accessibility features. https://theupdateframework.readthedocs.io/ https://sphinx-rtd-theme.readthedocs.io/en/stable/changelog.html

    The project source code repository is hosted on GitHub, which can be used by several alternate ways, with different degrees of documented accessibility: https://government.github.com/accessibility/ https://github.com/theupdateframework/python-tuf

    The software produced by the project is an API for software developers. Accessibility is provided by extensive standardized (napoleon/sphinx) code documentation and a focus on mnemonic naming. https://www.sphinx-doc.org/en/master/usage/extensions/napoleon.html


    足够获得徽章！

    该项目产生的软件应该被国际化，以便为目标受众的文化，地区或语言进行简单的本地化。如果国际化（i18n）不适用（例如，该软件不会生成针对最终用户的文本，并且不排序可读文本），请选择“不适用”（N/A）。 [internationalization]

    Our specification and reference library are meant to be used by developers and integrated into a new or preexisting updater.

    This criteria is not applicable if the end user is the person running the updater, because they are not expected to read text that originate from our library (TUF exceptions should be caught by the adopter and a suitable error message given to the user). But if the end user is the repo maintainer or adopter, then translations are probably needed for the code. However, our project's documentation, papers, website haven't been translated and are unreadable by non-English speakers, so it's unlikely they can even get started using the repo tools.


  • 其他


    足够获得徽章！

    如果项目站点（网站，存储库和下载URL）存储用于外部用户认证的密码，则必须使用密钥拉伸（迭代）算法将密码存储为具有每用户盐值的迭代散列（例如，PBKDF2，Bcrypt或Scrypt）。如果项目站点不存储密码，请选择“不适用”（N/A）。 [sites_password_security]

    GitHub meets this criterion.


  • 之前的版本


    足够获得徽章！

    该项目必须维护最常用的旧版本的产品或提供较新版本的升级路径。如果升级路径很困难，项目必须记录如何执行升级（例如，给出更改的接口描述和详细的建议步骤以帮助升级）。 [maintenance_or_update]

    Python's standard packaging and installation tools make it easy to use older versions of the project and provide upgrade paths to newer versions.


  • 错误报告流程


    足够获得徽章！

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

    The project uses GitHub's issue tracker to track individual issues.

    https://github.com/theupdateframework/python-tuf/issues


  • 漏洞报告流程


    足够获得徽章！

    除了要求匿名的报告者外，该项目必须对过去12个月内解决的所有漏洞报告的报告者表示感谢。如果过去12个月没有修复漏洞，请选择“不适用”（N/A）。 (需要网址) [vulnerability_report_credit]

    The published security advisories give credit to reporters of vulnerabilities, unless anonymity is requested: https://github.com/theupdateframework/python-tuf/security/advisories?state=published


    足够获得徽章！

    该项目必须有一个书面的流程来响应漏洞报告。 (需要网址) [vulnerability_response_process]

    The project documents the process for responding to vulnerability reports. https://github.com/theupdateframework/python-tuf/#security-issues-and-bugs


  • 编码标准


    足够获得徽章！

    该项目必须确定其使用的主要语言的具体编码风格指南，并要求贡献一般情况下符合此要求。 (需要网址) [coding_standards]

    The project encourages contributors to follow its coding style guidelines in the governance document and in a template automatically applied to pull requests: https://github.com/theupdateframework/python-tuf/blob/develop/docs/GOVERNANCE.md#contributions https://github.com/theupdateframework/python-tuf/blob/develop/.github/PULL_REQUEST_TEMPLATE.md

    The linked-to guidelines are here: https://github.com/secure-systems-lab/code-style-guidelines


    足够获得徽章！

    如果至少有一个FLOSS工具可以应用于所选择的语言，项目必须自动执行其选定的编码风格。 [coding_standards_enforced]

    The project automatically enforces its coding style guidelines via Pylint, black and isort.


  • 可工作的构建系统


    足够获得徽章！

    本地二进制文件的构建系统必须遵守传递给它们的相关编译器和链接器（环境）变量（例如CC，CFLAGS，CXX，CXXFLAGS和LDFLAGS），并将它们传递给编译器和链接器。构建系统可以使用附加标志来扩展它们，但不能简单地用自己的替换提供的值。如果没有生成本地二进制文件，请选择“不适用”（N/A）。 [build_standard_variables]

    No native binaries are being generated by the project.


    足够获得徽章！

    构建和安装系统在在相关标志中要求时，应该保留调试信息（例如，“install -s”未被使用）。如果没有构建或安装系统（例如典型的JavaScript库），请选择“不适用”（N/A）。 [build_preserve_debug]

    The standard Python build and installation system can be freely configured by users as they wish. The project does not restrict the user of relevant flags.


    足够获得徽章！

    如果子目录中存在交叉依赖关系，则由项目生成的软件的构建系统必须不能递归地构建子目录。如果没有构建或安装系统（例如典型的JavaScript库），请选择“不适用”（N/A）。 [build_non_recursive]

    The project does not recursively build subdirectories. All of its dependencies are external to its installation.


    足够获得徽章！

    该项目必须能够重复从源代码文件生成的过程，并获得完全相同的比特位结果。如果没有发生构建（例如，直接使用源代码而不是编译使用的脚本语言），请选择“不适用”（N/A）。 [build_repeatable]

    No true building occurs since the project uses Python.


  • 安装系统


    足够获得徽章！

    该项目必须提供一种使用常用惯例轻松安装和卸载由项目生成的软件的方法。 [installation_common]

    The project's releases can be installed and uninstalled with pip (Python's recommended tool to install Python packages).


    足够获得徽章！

    最终用户的安装系统必须遵守用于在安装时选择构建工件写入位置的标准约定。例如，如果在POSIX系统上安装文件，它必须遵守DESTDIR环境变量。如果没有安装系统或没有标准惯例，请选择“不适用”（N/A）。 [installation_standard_variables]

    Python's recommended tool to install Python packages, which the project supports, does honor standard conventions for selecting the location where built artifacts are written to at installation time.


    足够获得徽章！

    该项目必须为潜在开发人员提供一种快速安装所有项目成果和支持环境所必需的环境，包括测试套件和测试环境。必须通过常规惯例执行。 [installation_development_quick]

    The project's instructions for contributors explains how they can quickly install the project, it's dependencies, set up the environment, and run the unit tests. https://github.com/theupdateframework/python-tuf/contribute


  • 外部维护的组件


    足够获得徽章！

    项目必须以计算机可处理的方式列出外部依赖关系。 (需要网址) [external_dependencies]

    The project's setup.cfg specify's its external dependencies. https://github.com/theupdateframework/python-tuf/blob/develop/setup.cfg


    足够获得徽章！

    项目必须监视或定期检查其外部依赖（包括便利副本）以检测已知的漏洞，并修复可利用的漏洞或将其验证为不可利用的漏洞。 [dependency_monitoring]

    The project monitors dependency updates using GitHub native dependabot

    https://github.com/dependabot


    足够获得徽章！

    该项目必须满足下述情况之一：
    1. 可以轻松识别和更新重用的外部维护组件; 或
    2. 使用系统或编程语言提供的标准组件。
    这样，如果在重用的组件中发现了一个漏洞，将容易更新该组件。 [updateable_reused_components]

    The project monitors dependency updates using GitHub native dependabot and automatically performs updates when they become available.


    足够获得徽章！

    该项目应避免使用已弃用或过时的功能和API，如果FLOSS替代品在其使用的技术集合（“技术堆栈”）中以及项目支持的大多数用户中可用（以便用户可以随时访问该替代品）。 [interfaces_current]

    The project makes an honest attempt to make sure that it doesn't use deprecated or obsolete functions. Python versions that are marked as no longer maintained are also unsupported.


  • 自动测试套件


    足够获得徽章！

    必须将自动测试套件应用于至少一个分支的共享代码库的每次签入。该测试套件必须生成关于测试成功或失败的报告。 [automated_integration_testing]

    The project uses GitHub Actions to run the automated test suite on each pull request and push to the main branch.

    https://github.com/theupdateframework/python-tuf/actions https://github.com/theupdateframework/python-tuf/blob/develop/.github/workflows/ci.yml


    足够获得徽章！

    该项目必须为过去六个月内修复的至少50％的错误，在自动化测试套件中添加回归测试。 [regression_tests_added50]

    The project makes an honest effort to make sure that tests are added for all bugs that are fixed. It enforces at least 97% test coverage.

    https://github.com/theupdateframework/python-tuf/blob/develop/tox.ini


    足够获得徽章！

    如果有至少一个FLOSS工具可以以所选语言度量此条款，该项目的FLOSS自动测试套件必须具有至少80％语句覆盖率。 [test_statement_coverage80]

    The project's tox.ini config and continuous integration system requires 97% coverage of the source code, otherwise a build failure results. Its policy is captured in the GOVERNANCE.md and pull request template.

    https://github.com/theupdateframework/python-tuf/blob/develop/docs/GOVERNANCE.md#contributions https://github.com/theupdateframework/python-tuf/blob/develop/.github/PULL_REQUEST_TEMPLATE.md


  • 新功能测试


    足够获得徽章！

    该项目必须具有正式的书面策略，一旦添加了主要的新功能，新功能的测试必须被添加到自动测试套件中。 [test_policy_mandated]

    The project provides a formal written policy on testing of new functionality. https://github.com/theupdateframework/python-tuf/blob/develop/docs/GOVERNANCE.md#contributions https://github.com/theupdateframework/python-tuf/blob/develop/.github/PULL_REQUEST_TEMPLATE.md


    足够获得徽章！

    该项目必须在其关于变更建议的书面指导中包括要为主要新功能添加测试的策略。 [tests_documented_added]

    The project's pull request template documents the policy of verifying that tests have been added to the change. https://github.com/theupdateframework/python-tuf/blob/develop/.github/PULL_REQUEST_TEMPLATE.md

    In addition, tests are performed prominently and automatically for any pull request, and failures are flagged. https://github.com/theupdateframework/python-tuf/actions

    These policies are also explained in the contributors pages: https://github.com/theupdateframework/python-tuf/blob/develop/docs/GOVERNANCE.md#contributions https://github.com/theupdateframework/python-tuf/contribute


  • 警告标志


    足够获得徽章！

    在实际允许时，项目必须最大限度地严格修复项目生成的软件中的警告。 [warnings_strict]

    The project does not accept Pull Requests with pyint, bandit, black or isort warnings.

    https://github.com/theupdateframework/python-tuf/blob/develop/tox.ini https://github.com/theupdateframework/python-tuf/blob/develop/.github/workflows/ci.yml


  • 安全开发知识


    足够获得徽章！

    该项目必须实施安全设计原则（来自“know_secure_design”）（如适用）。如果项目不生产软件，请选择“不适用”（N/A）。 [implement_secure_design]

    The project strives to implement secure design principles.


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

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

    足够获得徽章！

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

    The project's default security mechanisms do not depend on weak algorithms or modes.


    足够获得徽章！

    该项目应该支持多种加密算法，如果一个被破解，用户可以快速切换。普通的对称密钥算法包括AES，Twofish和Serpent。通用密码散列算法的选择包括SHA-2（包括SHA-224，SHA-256，SHA-384和SHA-512）和SHA-3。 [crypto_algorithm_agility]

    The project supports multiple cryptographic algorithms, where applicable.


    足够获得徽章！

    该项目必须支持在与其他信息（如配置文件，数据库和日志）分离的文件中存储身份验证凭据（如密码和动态令牌）以及私有加密密钥，并允许用户更新和替换它们，而无需重新编译代码。如果项目从不处理身份验证凭据和私有加密密钥，请选择“不适用”（N/A）。 [crypto_credential_agility]

    The project supports the storage of private cryptographic keys and dynamic tokens.


    足够获得徽章！

    该项目产生的软件应该支持所有网络通信的安全协议，如SSHv2或更高版本，TLS1.2或更高版本（HTTPS），IPsec，SFTP和SNMPv3。默认情况下，FTP，HTTP，Telnet，SSLv3或更早版本和SSHv1等不安全协议将被禁用，只有在用户专门配置时才启用。如果项目生成的软件不支持网络通信，请选择“不适用”（N/A）。 [crypto_used_network]

    The project supports TLS for all of its network communications.


    足够获得徽章！

    项目生成的软件（如果支持或使用TLS）应该至少支持TLS版本1.2。请注意，TLS的前身称为SSL。如果软件不使用TLS，请选择“不适用”（N/A）。 [crypto_tls12]

    The project supports at TLS version 1.2, as provided by standard Python.


    足够获得徽章！

    由项目生成的软件必须，如果它支持TLS，则在使用TLS（包括子资源）时默认执行TLS证书验证。如果软件不使用TLS，请选择“不适用”（N / A）。 [crypto_certificate_verification]

    The project performs TLS certificate verification by default.


    足够获得徽章！

    项目生成的软件（如果支持TLS）必须在发送具有私有信息（如安全Cookie）的HTTP头之前执行证书验证。如果软件不使用TLS，请选择“不适用”（N/A）。 [crypto_verification_private]

    The project performs certificate verification, and before sending HTTP headers, but it does not need to send private information.


  • 安全发布


    足够获得徽章！

    该项目必须加密签名旨在广泛使用的项目结果的发布，并且必须有一个书面流程，向用户解释如何获取公共签名密钥并验证签名。这些签名的私钥不得在项目网站上直接向公众发布。如果发行版本不适用于广泛使用，请选择“不适用”（N/A）。 [signed_releases]

    The project documents to process for obtaining public signing keys and verifying releases of the project.


    足够获得徽章！

    建议在版本控制系统中，每个重要版本标签（作为主要版本的一部分的标签，次要版本或修复公开提到的漏洞）都按照signed_releases中的要求进行加密签名，并可验证。 [version_tags_signed]

    All of the project's release tags are cryptographically signed. https://github.com/theupdateframework/python-tuf/tags


  • 其他安全问题


    足够获得徽章！

    项目结果必须检查来自潜在不受信任来源的所有输入，以确保它们有效（ *白名单*），如果对数据有限制，则拒绝无效输入。 [input_validation]

    Input validation is of utmost importance for the update framework. See discussion in: https://github.com/theupdateframework/python-tuf/pull/1301

    All inputs are validated at the user boundary, i.e. when deserializing metadata from untrusted sources.


    足够获得徽章！

    加固机制应该用于项目生产的软件，以便软件缺陷不太可能导致安全漏洞。 [hardening]

    The project tries to use hardening mechanisms whenever possible. Given that the software is a security product, developers and reviewers have a focus on secure programming. Reviewing guidelines are documented in: https://github.com/secure-systems-lab/lab-guidelines/blob/master/code-review.md


    足够获得徽章！

    该项目必须提供一个保证案例，证明其满足安全要求。保证案例必须包括：对威胁模型的描述，明确确定信任边界，确定设计原则得到适用，以及常见安全弱点已经被消减。 (需要网址) [assurance_case]

    The project's research papers provide a description of the threat model, clear identification of trust boundaries, an argument that secure design principles have been applied, and an argument that common implementation security weaknesses have been countered.
    https://theupdateframework.io/security/ https://theupdateframework.io/publications/


  • 静态代码分析


    足够获得徽章！

    如果至少有一个FLOSS工具能够以所选择的语言实现此条款，则该项目必须至少使用一个具有规则或方式的静态分析工具来查找分析语言或环境中的常见漏洞。 [static_analysis_common_vulnerabilities]

    The project uses Floss tools pylint and Bandit (security linter) for static analysis and black and isort for uniform auto-format, which are all run in CI.

    https://github.com/theupdateframework/python-tuf/blob/develop/tox.ini https://github.com/theupdateframework/python-tuf/blob/develop/.github/workflows/ci.yml


  • 动态代码分析


    足够获得徽章！

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

    The project does not produce software written in a memory-unsafe language.



此数据在知识共享署名3.0或更高版本许可证（CC-BY-3.0 +） 下可用。所有内容都可以自由分享和演绎，但必须给予适当的署名。请署名为Justin Cappos和OpenSSF最佳实践徽章贡献者。

项目徽章条目拥有者： Justin Cappos.
最后更新于 2017-10-26 19:09:52 UTC, 最后更新于 2022-02-09 14:13:41 UTC。 最后在2017-11-17 17:46:04 UTC丢失通过徽章。 最后在 2017-11-20 19:26:07 UTC 获得通过徽章。

后退