t3x-universal-messenger

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

没有一套可以保证软件永远不会有缺陷或漏洞的做法；如果规范或假设是错误的，即使合适的方法也可能失败。也没有哪些做法可以保证一个项目能够维持健康和运作良好的开发者社区。但是，遵循最佳做法可以帮助改善项目的成果。例如，一些做法可以在发布之前进行多人评估，这可以帮助您找到其他难以找到的技术漏洞，并帮助建立信任，并希望不同公司的开发人员之间进行重复的交互。要获得徽章，必须满足所有“必须”和“禁止”的条款，满足所有“应该”条款或有合适的理由，和所有“建议”条款必须满足或未满足（至少希望考虑）。欢迎通过 GitHub网站创建问题或提出请求进行反馈。另外还有一个一般讨论邮件列表。

如果这是您的项目，请在您的项目页面上显示您的徽章状态！徽章状态如下所示： 项目15063的徽章级别为in_progress 这里是如何嵌入它：
您可以通过将其嵌入在您的Markdown文件中：
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/15063/badge)](https://www.bestpractices.dev/projects/15063)
或将其嵌入到HTML中来显示您的徽章状态：
<a href="https://www.bestpractices.dev/projects/15063"><img src="https://www.bestpractices.dev/projects/15063/badge"></a>


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

Baseline Series: 基准等级1 基准等级2 基准等级3

        

 基本 12/13 ●

 变更控制 8/9 ●

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


    足够获得徽章！

    该项目必须有一个版本控制的源代码存储库。它必须是公开可读的并可通过URL访问。 [repo_public]
    该URL可以与项目URL相同。该项目可能在特定情况下使用私人（非公开）分支，而更改不会公开发布（例如，在向公众披露漏洞之前修复漏洞）。

    The public Git repository records intermediate commits, authors, timestamps, and changes. Current inspected revision is e7a143415befb913cd35bed8e58b03f5389224b3. Evidence: https://github.com/netresearch/t3x-universal-messenger https://github.com/netresearch/t3x-universal-messenger/commits/main


    足够获得徽章！

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

    The public Git repository records intermediate commits, authors, timestamps, and changes. Current inspected revision is e7a143415befb913cd35bed8e58b03f5389224b3. Evidence: https://github.com/netresearch/t3x-universal-messenger https://github.com/netresearch/t3x-universal-messenger/commits/main


    足够获得徽章！

    为了实现协作检视，项目的源代码存储库必须包括临时版本，以便检视版本之间的变化；它不得仅包括最终版本。 [repo_interim]
    项目可以选择从其公共源代码库中删除特定的临时版本（例如，修复特定的未公开安全漏洞，可能永远不会公开发布的内容，或者包括不能合法发布而且不是最终版本的内容）。

    The public Git repository records intermediate commits, authors, timestamps, and changes. Current inspected revision is e7a143415befb913cd35bed8e58b03f5389224b3. Evidence: https://github.com/netresearch/t3x-universal-messenger https://github.com/netresearch/t3x-universal-messenger/commits/main


    足够获得徽章！

    建议使用通用分布式版本控制软件（例如，git）作为项目的源代码存储库。 [repo_distributed]
    Git不是必须，项目在合适场景可以使用集中版本控制软件（如subversion）。

    The public Git repository records intermediate commits, authors, timestamps, and changes. Current inspected revision is e7a143415befb913cd35bed8e58b03f5389224b3. Evidence: https://github.com/netresearch/t3x-universal-messenger https://github.com/netresearch/t3x-universal-messenger/commits/main


  • 唯一版本编号


    足够获得徽章！

    项目生成的用于每个用户使用的版本必须具有唯一版本标识符。 [version_unique]
    本条款可以通过各种方式来满足，包括提交ID（例如git提交ID或者Mercurial 更改列表id）或版本号（包括使用语义版本或基于日期的方案，如YYYYMMDD的版本号）。

    Published release/tag identifiers uniquely identify source snapshots; assets are associated with the corresponding GitHub release. Recent identifiers: v3.0.5, v3.0.4, v3.0.3, v3.0.2, v3.0.1. Evidence: https://github.com/netresearch/t3x-universal-messenger/tags https://github.com/netresearch/t3x-universal-messenger/releases


    足够获得徽章！

    建议使用语义版本控制（SemVer）格式进行发布。 [version_semver]
    其他版本编号方案，如提交ID（例如git commit id或mercurial changeset id）或基于日期的方案，如YYYYMMDD，可以用作版本号，因为它们是唯一的。一些备选方案可能会导致问题，因为用户可能无法轻松确定是否是最新的。如果所有目标客户仅运行最新版本，则SemVer可能不太有助于识别软件版本（例如，它是通过持续交付不断更新的单个网站或互联网服务的代码）。

    Recent published tags use semantic-version numbering: v3.0.5, v3.0.4, v3.0.3, v3.0.2, v3.0.1. Evidence: https://github.com/netresearch/t3x-universal-messenger/tags


    足够获得徽章！

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

    Published release/tag identifiers uniquely identify source snapshots; assets are associated with the corresponding GitHub release. Recent identifiers: v3.0.5, v3.0.4, v3.0.3, v3.0.2, v3.0.1. Evidence: https://github.com/netresearch/t3x-universal-messenger/tags https://github.com/netresearch/t3x-universal-messenger/releases


  • 发行说明


    足够获得徽章！

    该项目必须在每个版本中提供发布说明，这是该版本中主要变化的可读的摘要，以帮助用户确定是否应升级，升级影响将如何。发行说明不能是版本控制日志的原始输出（例如，“git log”命令结果不是发行说明）。其产出不适用于多个地点的项目（如单个网站或服务的软件），并采用持续交付，可以选择“N/A”。 (需要网址) [release_notes]
    发行说明可以以各种方式实施。许多项目将它们添加到名为“NEWS”，“CHANGELOG”或“ChangeLog”的文件中，可选的包含“.txt”，“.md”或“.html”等扩展名。历史上，术语“更改日志”是指每个更改的日志，但为了满足这些条款，需要的是可读取的摘要。发行说明可以由版本控制系统机制提供，例如 GitHub发布工作流程。

    Versioned human-readable changelog entries describe functional/security changes and include the latest release v3.0.5. This uses the maintained changelog rather than a raw merge-commit list. Evidence: https://github.com/netresearch/t3x-universal-messenger/blob/e7a143415befb913cd35bed8e58b03f5389224b3/CHANGELOG.md https://github.com/netresearch/t3x-universal-messenger/releases/tag/v3.0.5


    未知的所需信息，不足以用于徽章。

    发行说明必须列出每个新版本中修复的每个公开的漏洞。如果没有发行说明或者没有公开的漏洞，选择“不适用”。 [release_notes_vulns]
    如果用户通常不能在自己的计算机上实际更新软件，而必须依靠中间人来执行升级（对于内核和与内核交织的底层软件通常是这种情况），项目可以选择“不适用”（N/A）。

    GitHub lists no public project advisory, but absence from this one channel does not establish that no publicly known project vulnerability exists. Confirm whether N/A applies. Evidence: https://github.com/netresearch/t3x-universal-messenger/security/advisories https://github.com/netresearch/t3x-universal-messenger/releases


 报告 5/8 ●

  • 错误报告流程


    足够获得徽章！

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

    Public GitHub issues and pull requests provide an addressable, searchable discussion and bug-report archive. Private security reports use a separate channel. Evidence: https://github.com/netresearch/t3x-universal-messenger/issues https://github.com/netresearch/t3x-universal-messenger/pulls


    足够获得徽章！

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

    Public GitHub issues and pull requests provide an addressable, searchable discussion and bug-report archive. Private security reports use a separate channel. Evidence: https://github.com/netresearch/t3x-universal-messenger/issues https://github.com/netresearch/t3x-universal-messenger/pulls


    未知的所需信息，不足以用于徽章。

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

    Public issue samples have not established acknowledgments for the majority of all qualifying bug reports over a defined complete 2-12 month period. Evidence: https://github.com/netresearch/t3x-universal-messenger


    未知的所需信息，不足以用于徽章。

    该项目应该对过去2-12个月内（包括）的大部分（> 50％）的增强请求作出回应。 [enhancement_responses]
    答复可能是“不”或有关其价值的讨论。目的只是对某些请求有一些回应，这表明项目还活着。为了该条款的目的，项目不需要计数无效请求（例如，来自垃圾邮件发送者或自动系统）。如果项目不再进行增强，请选择“未满足”，并将介绍此情况的URL包含在内。如果一个项目有超出处理能力的增强需求数量，请选择“未满足”并解释。

    Public issue samples have not established responses to the majority of all qualifying enhancement requests over a defined complete 2-12 month period. Evidence: https://github.com/netresearch/t3x-universal-messenger


    足够获得徽章！

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

    Public GitHub issues and pull requests provide an addressable, searchable discussion and bug-report archive. Private security reports use a separate channel. Evidence: https://github.com/netresearch/t3x-universal-messenger/issues https://github.com/netresearch/t3x-universal-messenger/pulls


  • 漏洞报告流程


    足够获得徽章！

    项目必须在项目网站上发布报告漏洞的流程。 (需要网址) [vulnerability_report_process]
    例如，https://PROJECTSITE/security 上的一个明确指定的邮箱地址，通常以 security@example.org 的形式。这可能与其错误报告流程相同。漏洞报告可能一直是公开的，但是许多项目都有一个私密漏洞报告机制。

    The published security policy gives concrete vulnerability-reporting contact instructions. Evidence: https://github.com/netresearch/t3x-universal-messenger/blob/e7a143415befb913cd35bed8e58b03f5389224b3/SECURITY.md


    足够获得徽章！

    如果支持私有漏洞报告，项目必须包括如何以保密的方式发送信息。 (需要网址) [vulnerability_report_private]
    示例包括使用HTTPS（TLS）或使用OpenPGP加密的电子邮件在网络上提交的私密缺陷报告。如果漏洞报告总是公开的（从来没有私密漏洞报告），请选择“不适用”（N/A）。

    The policy provides a private reporting channel; GitHub private vulnerability reporting is enabled. Evidence: https://github.com/netresearch/t3x-universal-messenger/blob/e7a143415befb913cd35bed8e58b03f5389224b3/SECURITY.md https://github.com/netresearch/t3x-universal-messenger/security/advisories


    未知的所需信息，不足以用于徽章。

    该项目在过去6个月收到的任何漏洞报告的初始响应时间必须小于或等于14天。 [vulnerability_report_response]
    如果过去6个月没有报告漏洞，请选择“不适用”（N/A）。

    The published reporting policy does not establish actual initial-response times for all private reports in the last six months. Confirm the report history, including whether there were no reports. Evidence: https://github.com/netresearch/t3x-universal-messenger


 质量 7/13 ●

  • 可工作的构建系统


    足够获得徽章！

    如果项目生成的软件需要构建使用，项目必须提供可以从源代码自动重新构建软件的可工作的构建系统。 [build]
    构建系统确定重建软件（以及以什么顺序）需要执行哪些操作，然后执行这些步骤。例如，它可以调用编译器来编译源代码。如果从源代码创建可执行文件，则必须可以修改项目的源代码，然后通过这些修改生成更新的可执行文件。如果项目生成的软件取决于外部库，则构建系统不必构建那些外部库。如果在修改源代码之后不需要构建任何使用该软件的软件，请选择“不适用”（N/A）。

    The delivered PHP/scripts are interpreted directly; no native or transpiled application build is required for these source results. Dependency installation and archive packaging are separate. Evidence: https://github.com/netresearch/t3x-universal-messenger/blob/e7a143415befb913cd35bed8e58b03f5389224b3/composer.json


    足够获得徽章！

    建议使用通用工具来构建软件。 [build_common_tools]
    例如，Maven，Ant，cmake，自动工具，make，rake（Ruby）或devtools （R）。

    The repository uses standard FLOSS source/dependency tooling: PHP and Composer. Evidence: https://github.com/netresearch/t3x-universal-messenger/blob/e7a143415befb913cd35bed8e58b03f5389224b3/composer.json


    足够获得徽章！

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

    The repository uses standard FLOSS source/dependency tooling: PHP and Composer. Evidence: https://github.com/netresearch/t3x-universal-messenger/blob/e7a143415befb913cd35bed8e58b03f5389224b3/composer.json


  • 自动测试套件


    不足以获得徽章。

    该项目必须使用至少一个作为FLOSS公开发布的自动测试套件（该测试套件可以作为单独的FLOSS项目维护）。 [test]
    该项目可以使用多个自动测试套件（例如，一个是快速运行的测试套件，而另一个更为彻底但需要特殊设备）。

    A PHPUnit suite exists, but the project license explicitly restricts its redistribution/use. The criterion requires a publicly released FLOSS test suite; no separate FLOSS license for these tests was found. Evidence: https://github.com/netresearch/t3x-universal-messenger/blob/e7a143415befb913cd35bed8e58b03f5389224b3/LICENSE https://github.com/netresearch/t3x-universal-messenger/tree/e7a143415befb913cd35bed8e58b03f5389224b3/Tests/


    未知的所需信息，不足以用于徽章。

    测试套件应该以该语言的标准方式进行调用。 [test_invocation]
    例如“make check”，“mvn test”或“rake test”。

    Current public evidence does not establish the complete requirement: A test suite MUST be invocable in a standard way for that language. Evidence: https://github.com/netresearch/t3x-universal-messenger


    未知的所需信息，不足以用于徽章。

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

    No current comprehensive mapping of tests to branches, inputs, and functionality establishes majority coverage. Evidence: https://github.com/netresearch/t3x-universal-messenger


    未知的所需信息，不足以用于徽章。

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

    Current public evidence does not establish the complete requirement: The project MUST implement continuous integration, where new or changed code is frequently integrated into a central code repository and automated tests are run on the result. Evidence: https://github.com/netresearch/t3x-universal-messenger


  • 新功能测试


    足够获得徽章！

    该项目必须有通用的策略（正式或非正式），当主要的新功能被添加到项目生成的软件中，该功能的测试应该同时添加到自动测试套件。 [test_policy]
    只要有相应的策略，即使是通过口头传播，也就是说开发人员应该为主要的新功能在自动化测试套件中添加测试，选择“Met”。

    The documented change-proposal/developer checklist requires adding or updating automated tests for new/changed functionality. Evidence: https://github.com/netresearch/t3x-universal-messenger/blob/e7a143415befb913cd35bed8e58b03f5389224b3/AGENTS.md


    未知的所需信息，不足以用于徽章。

    该项目必须有证据表明，在项目生成的软件的最近重大变化中，已经遵守了添加测试的条款： test_policy 。 [tests_are_added]
    主要功能通常在发行说明中提及。不需要完美，只需证明，当新的主要功能添加到项目生成的软件时，测试通常会在实践中被添加到自动化测试套件中。

    Existing tests and a contribution policy do not establish that the most recent major functionality changes added matching tests; change-to-test evidence is needed. Evidence: https://github.com/netresearch/t3x-universal-messenger


    足够获得徽章！

    建议您在更改提案的说明文档中添加测试策略要求（请参阅test_policy）。 [tests_documented_added]
    但是，只要在实践中添加了测试，即使是非正式规则也是可以接受的。

    The documented change-proposal/developer checklist requires adding or updating automated tests for new/changed functionality. Evidence: https://github.com/netresearch/t3x-universal-messenger/blob/e7a143415befb913cd35bed8e58b03f5389224b3/AGENTS.md


  • 警告标志


    足够获得徽章！

    该项目必须启用一个或多个编译器警告标志，“安全”语言模式，或者使用单独的“linter”工具查找代码质量错误或常见的简单错误，如果至少有一个FLOSS工具可以在所选择的语言实现此条款。 [warnings]
    编译器警告标志的例子包括gcc/clang “-Wall”。 “安全”语言模式的示例包括JavaScript “use strict”和perl5的“使用警告”。一个单独的“linter”工具用于检查源代码以查找代码质量错误或常见的简单错误。这些通常在源代码或构建指令中启用。

    Actual CI jobs execute language lint/code-quality checks. PHP source additionally uses strict typing where configured. Evidence: https://github.com/netresearch/t3x-universal-messenger/blob/e7a143415befb913cd35bed8e58b03f5389224b3/.github/workflows/ci.yml https://github.com/netresearch/t3x-universal-messenger/actions/runs/36528581259/job/109277856510


    足够获得徽章！

    该项目必须处理警告。 [warnings_fixed]
    告警是通过执行warnings条款确定的。该项目应该修复告警或在源代码中将其标记为误报。理想情况下，不会有告警，但项目可能会接受一些告警（通常每100行小于1个告警，或整体少于10个告警）。

    The inspected recent lint/code-style jobs completed successfully; their workflow fails rather than silently accepting reported lint/style errors. Evidence: https://github.com/netresearch/t3x-universal-messenger/actions/runs/36528581259/job/109277856510 https://github.com/netresearch/t3x-universal-messenger/blob/e7a143415befb913cd35bed8e58b03f5389224b3/.github/workflows/ci.yml


    未知的所需信息，不足以用于徽章。

    建议在实际情况下，项目以最严格方式对待项目生成的软件中的告警。 [warnings_strict]
    某些项目无法有效启用某些警告。需要证明的是，项目正在努力的启用警告标志，以便早期发现错误。

    Current public evidence does not establish the complete requirement: Projects MUST be maximally strict with warnings in the software produced by the project, where practical. Evidence: https://github.com/netresearch/t3x-universal-messenger


 安全 2/16 ●

  • 安全开发知识


    未知的所需信息，不足以用于徽章。

    该项目必须至少有一个主要开发人员知道如何设计安全软件。 [know_secure_design]
    这需要了解以下设计原则，包括 Saltzer和Schroeder 中的8项原则：
    • 机制经济（保持设计简单实用，例如采用彻底简化）
    • 故障安全默认（默认情况下，访问决策应拒绝），项目安装应默认安全）
    • 完全仲裁（必须检查每个可能被限制的访问权限，并且不可绕过）
    • 开放式设计（安全机制不应该依赖于攻击者对其设计的无知，而应该更容易地保护和更改信息，例如密钥和密码）
    • 特权分离（理想情况下，对重要对象的访问应该取决于多个条件，从而破坏一个保护系统将无法实现完全访问。如，多因子身份验证，要求密码和硬件令牌，比单因子认证安全性更高）
    • 最小权限（进程应该以最少的权限运行）
    • 最少的公共机制（设计应该最大限度地减少所有用户所依赖的，涉及到多个用户的共同机制，如，临时文件的目录）
    • 心理可接受性（人机接口必须设计为易于使用 —— 设计为“最不惊讶”）
    • 有限的攻击面（攻击面 —— 一组不同的入口，其​​中攻击者可以尝试输入或提取数据 —— 应该受到限制）
    • 输入验证与白名单（输入通常应该在被接受之前检查以确定是否有效；此验证应使用白名单（仅接受已知的有效值），而不是黑名单（尝试列出已知的非法值））。
    项目中的“主要开发人员”的定义是熟悉项目代码的任何人，很乐意对其进行更改，并被项目中大多数其他参与者确认。主要开发人员通常会在过去一年中通过代码，文档或回答问题提供一些贡献。开发人员通常被认为是主要开发人员，如果他们启动项目（并且还没有离开项目满三年），可以选择在私人漏洞报告渠道（如果有的话）上接收信息，可以代表项目接受提交，或执行项目软件的最终版本发布。如果只有一个开发者，那个人是主要开发人员。

    Source safeguards alone do not establish that a primary developer knows all secure-design principles required by this criterion. Maintainer attestation or training evidence is needed. Evidence: https://github.com/netresearch/t3x-universal-messenger


    未知的所需信息，不足以用于徽章。

    该项目的主要开发人员中，至少有一个必须知道导致这类型软件漏洞的常见错误类型，以及至少有一种方法来对付或缓解这些漏洞。 [know_common_errors]
    示例（取决于软件的类型）包括SQL注入，操作系统注入，经典缓冲区溢出，跨站点脚本（XSS），缺少认证和缺少授权。请参阅 CWE/SANS 25种最常见漏洞或 OWASP十大漏洞类型项目。

    Tool configuration alone does not establish a primary developer's knowledge of the relevant vulnerability classes and mitigations. Maintainer attestation or attributable review evidence is needed. Evidence: https://github.com/netresearch/t3x-universal-messenger


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

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

    未知的所需信息，不足以用于徽章。

    项目生成的软件默认情况下，只能使用由专家公开发布和审查的加密协议和算法（如果使用加密协议和算法）。 [crypto_published]
    这些加密条款并不总是适用，因为某些软件不需要直接使用加密功能。

    Cryptographic behavior inherited from providers/framework components needs a complete protocol-and-algorithm inventory before every default can be confirmed as published and reviewed. Evidence: https://github.com/netresearch/t3x-universal-messenger


    未知的所需信息，不足以用于徽章。

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

    A complete inventory of security-sensitive cryptographic operations and library delegation was not established for this project. Evidence: https://github.com/netresearch/t3x-universal-messenger


    未知的所需信息，不足以用于徽章。

    项目所产生的软件中，所有依赖于密码学的功能必须使用FLOSS实现。 [crypto_floss]
    请参阅OSI （开放源代码促进会）发布的软件开放标准需求。

    FLOSS source licensing alone does not establish that every cryptography-dependent function is implementable using FLOSS, including dependencies and providers. Evidence: https://github.com/netresearch/t3x-universal-messenger


    未知的所需信息，不足以用于徽章。

    项目生成的软件中的安全机制使用的默认密钥长度必须至少达到2030年（如2012年所述）的NIST最低要求。必须提供配置，以使较小的密钥长度被完全禁用。 [crypto_keylength]
    这些最小位长度是：对称密钥112，因式分解模数2048，离散对数密钥224，离散对数组2048，椭圆曲线224和散列224（密码散列不涉及该位长度），关于密码散列的更多信息可以在 crypto_password_storage 条款）。请参阅 http://www.keylength.com 以比较不同组织的密钥长度建议。在某些配置中，软件可能允许较小的密钥长度（理想情况下不会，因为这允许降级攻击，但是互操作性有时需要较短的密钥长度）。

    No verified inventory of every default key length and the ability to disable weaker configurations was obtained. Evidence: https://github.com/netresearch/t3x-universal-messenger


    未知的所需信息，不足以用于徽章。

    项目产生的软件中的默认安全机制不得取决于已被破解的密码算法（例如，MD4，MD5，单DES，RC4，Dual_EC_DRBG）或使用不适合上下文的密码模式（例如，ECB模式几乎不适当，因为它揭示了密文中相同的块，如 ECB企鹅所示。CTR模式通常是不合适的，因为如果重复输入状态，则它不执行认证并导致重复）。 [crypto_working]
    在许多情况下，最好选择设计用于组合保密和认证的块密码算法模式，例如Galois / Counter Mode（GCM）和EAX。项目可以允许用户为必要的兼容性启用已被破解的加密机制，但是需要用户知道他们正在这么做。

    The public evidence does not establish that every default cryptographic mechanism avoids broken algorithms and context-inappropriate modes. Evidence: https://github.com/netresearch/t3x-universal-messenger


    未知的所需信息，不足以用于徽章。

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

    The public evidence does not establish that every default security mechanism avoids algorithms and modes with known serious weaknesses. Evidence: https://github.com/netresearch/t3x-universal-messenger


    未知的所需信息，不足以用于徽章。

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

    Forward secrecy depends on the actual key-agreement protocols and deployment configuration; supporting HTTPS alone is insufficient. Evidence: https://github.com/netresearch/t3x-universal-messenger


    未知的所需信息，不足以用于徽章。

    如果项目产生的软件存储用于外部用户认证的密码，则必须使用密钥拉伸（迭代）算法（例如，PBKDF2，Bcrypt或Scrypt）将密码存储为每用户盐值不同的迭代散列 。 [crypto_password_storage]
    此条款仅适用于软件强制使用密码验证用户身份的情况（如服务器端Web应用程序）。在软件存储用于认证到其他系统的密码（例如，该软件实现某个其他系统的客户端）的情况下，这是不适用的，因为该软件的至少某个部分必须经常访问未散列加密的密码。

    Password handling across the extension and its delegated authentication components was not completely verified against the required salted iterative hashing. Evidence: https://github.com/netresearch/t3x-universal-messenger


    未知的所需信息，不足以用于徽章。

    由项目生成的软件中的安全机制必须使用密码学安全的随机数生成器生成所有加密密钥和随机数，并且不得使用密码学不安全的生成器。 [crypto_random]
    密码安全的随机数生成器可以是硬件随机数生成器，或者它可以是使用诸如Hash_DRBG，HMAC_DRBG，CTR_DRBG，Yarrow或Fortuna之类的算法的加密安全的伪随机数生成器（CSPRNG）。对安全性随机数生成器的调用示例包括Java的java.security.SecureRandom和JavaScript的window.crypto.getRandomValues。调用不安全随机数生成器的示例包括Java的java.util.Random和JavaScript的Math.random。

    The complete set of key and nonce generation sites was not verified against CSPRNG requirements. Evidence: https://github.com/netresearch/t3x-universal-messenger


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


    足够获得徽章！

    该项目必须使用一种针对MITM攻击的传递机制。使用https或ssh + scp是可以接受的。 [delivery_mitm]
    一个更强大的机制是使用数字签名的软件包发布软件，因为这样可以减轻对分发系统的攻击，但只有在用户确信签名的公钥是否正确的情况下才可以确定。用户实际上会检查签名。

    The canonical repository and GitHub release/download endpoints use authenticated HTTPS. No release process in the reviewed configuration trusts an unsigned digest obtained over HTTP. Evidence: https://github.com/netresearch/t3x-universal-messenger https://github.com/netresearch/t3x-universal-messenger/releases


    足够获得徽章！

    不得通过http协议获取加密散列（例如，sha1sum）并直接使用，而不检查密码学签名。 [delivery_unsigned]
    这些散列可以在传输过程中修改。

    The canonical repository and GitHub release/download endpoints use authenticated HTTPS. No release process in the reviewed configuration trusts an unsigned digest obtained over HTTP. Evidence: https://github.com/netresearch/t3x-universal-messenger https://github.com/netresearch/t3x-universal-messenger/releases


  • 修正公开的漏洞


    未知的所需信息，不足以用于徽章。

    被公开了超过60天的中等或更高严重程度的漏洞，必须被修复。 [vulnerabilities_fixed_60_days]
    该漏洞必须由项目本身修补和发布（修补程序可能在其他地方开发）。一旦漏洞具有公开发布的非付费信息的CVE（例如，在国家漏洞数据库）或项目已被通知，且信息已经发布给公众（可能是项目自己发布），则视为漏洞已经公众所知。如果其 CVSS 2.0 基本分数为4或更高，则漏洞是中等到高的严重性。 注意：这意味着全世界的所有攻击者可能会对用户造成长达60天的伤害。这个标准通常比Google在重新启动负责任的披露中所推荐的容易得多。因为Google建议，如果报告不是公开的，那么当项目得到通知，甚至报告尚未公开时，60天的时间段就会开始。

    A policy or dependency-audit workflow does not prove that no project or dependency vulnerability of medium or higher severity has remained unpatched for more than sixty days. A dated complete vulnerability inventory is needed. Evidence: https://github.com/netresearch/t3x-universal-messenger


    未知的所需信息，不足以用于徽章。

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

    A remediation target does not prove actual prompt handling of every critical vulnerability; historical security incident evidence is needed. Evidence: https://github.com/netresearch/t3x-universal-messenger


  • 其他安全问题


    未知的所需信息，不足以用于徽章。

    公共存储库不得泄漏旨在限制公众访问的有效私人凭证（例如，工作密码或私钥）。 [no_leaked_credentials]
    项目可以泄漏测试和不重要数据库的“样本”凭据，只要它们不旨在限制公共访问。

    The presence of secret scanning and synthetic fixtures does not establish that every public ref is free of valid credentials. No active credential was observed in the reviewed files, but full-history scan and finding disposition are unverified. Evidence: https://github.com/netresearch/t3x-universal-messenger


 分析 4/8 ●


您可以使用工具和AI系统通过简单的URL提交变更建议，例如 https://www.bestpractices.dev/zh-CN/projects/15063/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced。请参阅我们的自动化提案系统，了解具体操作方法。 该数据可在社区数据许可协议 – 许可性，版本 2.0 (CDLA-Permissive-2.0)下获取。这意味着数据接收方可以共享数据，无论是否经过修改，只要数据接收方在共享数据时提供本协议文本。请注明Sebastian Mendel和OpenSSF最佳实践徽章贡献者。

项目徽章条目拥有者： Sebastian Mendel.
最后更新于 2026-09-29 06:06:51 UTC, 最后更新于 2026-09-29 15:19:32 UTC。