Mbed TLS 贡献指南PR 流程、生成式测试体系、后向兼容约束与 LTS 回移规则【免费下载链接】mbedtlsAn open source, portable, easy to use, readable and flexible TLS library, and reference implementation of the PSA Cryptography API. Releases are on a varying cadence, typically around 3 - 6 months between releases.项目地址: https://gitcode.com/GitHub_Trending/mb/mbedtls本文为 Mbed TLS 开源项目贡献者编写的技术指南以仓库中的 CONTRIBUTING.md 为核心依据系统讲解从提交 PR 前的四项检查清单、测试体系的 function/data 文件生成机制到 API/ABI 后向兼容约束与 LTS 分支回移backport规则并补充 ChangeLog 条目格式、Git 钩子与 DCO 签署等源码级证据帮助贡献者在动手前完整掌握 Mbed TLS 的协作规范与工程边界。贡献 PR 前的快速检查清单CONTRIBUTING.md 开篇给出了一个Quick Checklist for PR contributors所有 PR 都需要逐项通过这也是后文各章节的总索引检查项说明Sign-off签署每个 commit 都必须带有 DCO 签署见许可证与版权一节Tests测试PR 必须包含充分的测试用例Changelog变更日志如有用户可见变更需提交 ChangeLog 条目Backports回移如缺陷同时存在于 LTS 分支需要提供回移也可以等主 PR 被接受后再做原文强调所有 PR 都会经过项目团队/社区评审可能需要若干轮修改才能被接受因此建议在提交前就按此清单自查。编码标准Coding StandardsCONTRIBUTING.md 对代码质量提出了四条硬性要求必须包含测试贡献在提交前应通过基础测试并在发出 PR 后跟踪 CI 结果风格干净、可读代码必须符合 Mbed TLS 官方编码规范该规范发布在 Mbed TLS 知识库中仓库内不随附全文可移植、通用代码应以利于整个社区而非仅满足个人需求的方式编写安全性代码会同时从安全角度进行评审因此安全属性与功能正确性同等重要。从仓库结构看这些要求有具体的落点公开接口集中在 include/mbedtls/ 目录如 ssl.h、x509_crt.h实现位于 library/示例程序在 programs/测试在 tests/——贡献者修改任一模块时对应目录下的示例与测试往往也需要同步更新CONTRIBUTING.md 明确要求如有需要示例程序也要一并修改。贡献流程五步走CONTRIBUTING.md 定义的正式贡献流程如下每一步都有明确的验证依据确认需求先在 issue 列表或社区邮件列表中检索是否已有相关议题避免重复工作基于正确的分支开发以development分支为基线进行改动该分支用于准备下一个 4.x 小版本包含新功能、缺陷修复与安全修复见 BRANCHES.md先写测试写一个能证明 bug 已修复或新功能按预期工作的测试提交 PR 并配合评审根据评审意见迭代修改直至合并发布控制规模能够快速合并的贡献应当短小、聚焦单一功能或主题贡献越大评审与合并周期越长。这里的关键约束是第 2 步的分支选择bug 修复类改动应基于development而不是mainmain只包含最新已发布版本而修复是否需要回移到 LTS 分支则由下文的回移规则决定。后向兼容性API 只能扩展不能修改这是 CONTRIBUTING.md 中约束力最强的部分直接决定了贡献的可合并窗口目标将用户升级新版库时的影响降到最低。除非用户主动采用新特性、跨代升级或因安全缺陷必须修改否则用户代码不应需要任何改动。为此main开发分支与 LTS 分支之间都维护 API 兼容性详见 BRANCHES.md 中Backwards Compatibility for application code一节接口变更必须可辩护即使是主开发分支上任何 ABI/API 变更都必须是显著增强、新功能或最能通过接口变更解决的 bug 修复。若贡献包含 API 变更只有在发生 major release 时才会被合并只扩展、不修改公共接口中函数的定义不允许做改变 API 的修改只能通过扩展接口来变更。确实需要改动已有函数时将其标记为deprecated弃用若要用一个接口略有不同的新函数替代旧函数原型不同或文档化行为不同应创建带新名称的新函数保留旧函数并标记弃用计划性移除库会定期移除弃用函数这构成 API 破坏性变更但只在有计划、有结构、给用户充分预告的情况下进行。BRANCHES.md 进一步补充了可操作的细节项目采用语义化版本Semantic Versioning同一 major 版本内的小版本升级保证 API 向后兼容4.(x1) 的 API 向后兼容 4.x只在 major 变更如 3.x 到 4.0时允许打破 API 兼容而 LTS 分支在此之上还要尽量维持 ABI 兼容重链接而非重编译级别并避免代码体积、RAM 用量或构建工具最低版本的增加——唯一例外是安全修复优先但仍会尽量提供兼容选项。该文档还列举了若干不算破坏兼容的常见小版本变更例如向结构体添加或重排字段、向枚举添加条目、对原有失败场景改为成功作为合理功能扩展等。LTS 分支与回移Backport三条规则Mbed TLS 维护若干 LTS 分支其存在价值是让嵌入式/资源敏感平台的用户获得一个只有安全修复和缺陷修复、没有新特性的稳定版本——新特性可能带来代码体积或 RAM 用量的变化这在部分平台上是重大考量。因此 LTS 分支同时维护公共 API 与 ABI 的向后兼容。贡献者回移到 LTS 分支时必须遵守三条规则任何改变 API 或 ABI 的变更都不得回移凡修复了 LTS 分支中也存在的缺陷的 bug 修复必须回移到该 LTS 分支如果该修复引入了 API 变更如新增函数应重构修复方式以规避 API 变更——缺乏强理由的 API 变更不太可能被接受新功能或增强不需要回移例外包括新增测试用例、构建/测试脚本的质量改进等。CONTRIBUTING.md 同时鼓励贡献者主动将贡献回移到 LTS 分支在development分支之外。当前维护中的分支列表可在 BRANCHES.md 的Current Branches一节查询目前包括main、development、mbedtls-3.6支持至 2027 年 3 月与mbedtls-4.1支持至 2029 年 3 月项目按 18 个月节奏发布 LTS 版本每个 LTS 支持期为三年。测试function 与 data 文件驱动的生成式测试套件CONTRIBUTING.md 的 Tests 一节揭示了 Mbed TLS 测试体系的核心机制测试套件位于tests/目录是动态生成出来的。每个套件由两类文件驱动function 文件如suites/test_suite_ssl.function包含实际的测试函数代码data 文件如suites/test_suite_ssl.data包含测试用例以参数形式传递给测试函数。以 tests/suites/ 目录为例可以清楚看到.function与.data成对出现的组织方式。test_suite_error.data 展示了一个典型的 data 文件格式——标题行、depends_on:配置依赖声明、以及函数名:参数1:参数2:...形式的用例行Single low error depends_on:MBEDTLS_NET_C error_strerror:-0x0042:NET - Failed to open a socket Non existing high error error_strerror:-0x8880:UNKNOWN ERROR CODE (8880)data 文件中的depends_on:机制让测试能根据编译期配置include/mbedtls/mbedtls_config.h中的宏自动跳过不适用的用例这也解释了为何同一套测试在不同配置下可用测试数量会浮动。CONTRIBUTING.md 还给出两条测试相关硬性要求测试覆盖仓库提供测试脚本tests/scripts/basic-build-test.sh用于展示库的测试覆盖情况新代码贡献应提供与现有代码相当的覆盖率。查看 tests/scripts/basic-build-test.sh 可看到它的具体职责先以--coverage插桩构建然后依次执行单元测试tests/scripts/run-test-suites.pl、系统测试tests/ssl-opt.sh与互操作性测试tests/compat.sh最后生成覆盖率报告示例程序同步如需修改示例程序programs/下的 ssl/x509 等 demo应一并更新。此外Mbed TLS 网站知识库上有关于如何为测试套件新增测试的专门文章CONTRIBUTING.md 中的链接指向该知识库贡献者可参考。持续集成测试与 Git 钩子PR 提交后会触发 CI 测试贡献者的义务是跟踪 CI 结果并修复失败。CONTRIBUTING.md 建议在推送前启用 githooks 脚本以便尽早暴露问题。结合仓库中的 tests/git-scripts/ 目录可以了解其安装与工作方式钩子脚本存放于tests/git-scripts/需要软链接到.git/hooks才能生效。tests/git-scripts/README.md 给出了 Linux 下的安装命令ln -s ../../tests/git-scripts/pre-push.sh pre-push注意该 README 明确提示目前钩子仅在 GNU 平台上可用非 GNU 平台不要启用tests/git-scripts/pre-push.sh 的核心逻辑很简洁——它调用tests/scripts/all.sh -q -k check_*即执行所有以check_*命名的检查项如已提交的生成文件检查等。脚本以非零状态退出时阻止推送该脚本也可以脱离 git 独立运行适合手动预检。文档要求与 ChangeLog 条目规范CONTRIBUTING.md 的 Documentation 一节列出五条要求所有接口都应通过 Doxygen 文档化新 API 必须引入 Doxygen 注释Doxygen 输入文件位于 doxygen/input/复杂代码段应包含注释如需要建议添加 Readme 文件如需新增知识库KB文章请在 PR 描述中以评论形式写明必须为本贡献添加 ChangeLog 条目。第 5 条的完整规范在 ChangeLog.d/00README.md 中值得贡献者细读何时需要写条目——存在用户可见变更时库或示例程序的 bug 修复安全漏洞、行为破坏、特定配置/平台下的构建修复等、新特性/新示例程序/新平台支持、既有行为变更应少见。通常不需要的文档改进、非显著的性能改进、测试代码等用户不直接接触的部分、普通编译器告警修复。条目文件格式——文件扩展名为*.txt放在ChangeLog.d/目录类别头加缩进条目Security * Change description. * Another change description. Features * Yet another change description. This is a long change description that spans multiple lines.允许的类别共 9 个API changes、Default behavior changes、Requirement changes、New deprecations、Removals、Features、Security、Bugfix、Changes无法归类时用 Changes。书写规则每条以3 个空格 星号 空格开头续行缩进 5 个空格行宽 79 字符换行使用完整英文句子、现在时、适用时使用祈使句相关时附上 issue 编号#1234格式与 CVE 等外部引用适当致谢 bug 报告者核心原则是解释为什么而不是怎么做——面向的读者是库用户而非开发者例如 bug 修复应说明该 bug 的影响而非修复手法。仓库当前就有一个符合该格式的真实示例ChangeLog.d/serialized-data-load-hardening.txtBugfix * Reject serialized TLS 1.2 sessions whose session ID length exceeds 32, instead of accepting an out-of-range length that is later used to read past the end of the 32-byte session ID buffer.条目写好之后通过运行framework/scripts/assemble_changelog.py需从 Git 工作副本执行将ChangeLog.d中的条目合并进主 ChangeLog 文件。许可证与版权SPDX 标识与 DCO 签署CONTRIBUTING.md 对知识产权的规定与 Mbed TLS 的双重许可模式紧密相关双重许可除非文件中另有说明Mbed TLS 的文件同时提供 Apache-2.0 与 GPL-2.0-or-later 两种许可完整文本见 LICENSE 文件用户可选择以其中任一许可证取用代码贡献者的义务贡献者必须接受其贡献同时以 Apache-2.0和GPL-2.0-or-later 双许可发布SPDX 标识所有新文件在可行处都应包含标准 SPDX 许可证标识即文件头注释中的SPDX-License-Identifier: Apache-2.0 OR GPL-2.0-or-later版权归属贡献代码的版权仍归原作者新文件尽量在文件头以Copyright The Mbed TLS Contributors形式注明可在 tests/git-scripts/pre-push.sh 等脚本文件中看到该头部的标准写法DCO 签署提交代码时提交者与所有作者必须按照 dco.txt 中的《Developer Certificate of Origin》DCO 1.1声明提交内容可以合法成为项目一部分并以上述双许可提交。操作层面就是在每个 commit message 中加入标准的Signed-off-by:行若有多人贡献同一 commit每个人都应添加自己的Signed-off-by:行。dco.txt 完整收录了 DCO 1.1 的四条声明条款a–d可作为签署时的法律依据对照。小结Mbed TLS 的贡献规范可以概括为一条主线与四个硬约束主线是基于development分支、先写测试、小步提交、配合评审四个硬约束分别是——API 只能扩展不能破坏API 变更只能随 major release 合并、LTS 分支只回移不改接口的缺陷修复、用户可见变更必须有 ChangeLog 条目、每个 commit 必须带Signed-off-by签署。贡献者在动手前对照 CONTRIBUTING.md 的快速清单自查再结合 BRANCHES.md 确认目标分支与支持周期、用tests/scripts/basic-build-test.sh验证覆盖、用tests/git-scripts钩子做推送前预检即可满足仓库对 PR 的全部工程要求。【免费下载链接】mbedtlsAn open source, portable, easy to use, readable and flexible TLS library, and reference implementation of the PSA Cryptography API. Releases are on a varying cadence, typically around 3 - 6 months between releases.项目地址: https://gitcode.com/GitHub_Trending/mb/mbedtls创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Mbed TLS 贡献指南：PR 流程、生成式测试体系、后向兼容约束与 LTS 回移规则
Mbed TLS 贡献指南PR 流程、生成式测试体系、后向兼容约束与 LTS 回移规则【免费下载链接】mbedtlsAn open source, portable, easy to use, readable and flexible TLS library, and reference implementation of the PSA Cryptography API. Releases are on a varying cadence, typically around 3 - 6 months between releases.项目地址: https://gitcode.com/GitHub_Trending/mb/mbedtls本文为 Mbed TLS 开源项目贡献者编写的技术指南以仓库中的 CONTRIBUTING.md 为核心依据系统讲解从提交 PR 前的四项检查清单、测试体系的 function/data 文件生成机制到 API/ABI 后向兼容约束与 LTS 分支回移backport规则并补充 ChangeLog 条目格式、Git 钩子与 DCO 签署等源码级证据帮助贡献者在动手前完整掌握 Mbed TLS 的协作规范与工程边界。贡献 PR 前的快速检查清单CONTRIBUTING.md 开篇给出了一个Quick Checklist for PR contributors所有 PR 都需要逐项通过这也是后文各章节的总索引检查项说明Sign-off签署每个 commit 都必须带有 DCO 签署见许可证与版权一节Tests测试PR 必须包含充分的测试用例Changelog变更日志如有用户可见变更需提交 ChangeLog 条目Backports回移如缺陷同时存在于 LTS 分支需要提供回移也可以等主 PR 被接受后再做原文强调所有 PR 都会经过项目团队/社区评审可能需要若干轮修改才能被接受因此建议在提交前就按此清单自查。编码标准Coding StandardsCONTRIBUTING.md 对代码质量提出了四条硬性要求必须包含测试贡献在提交前应通过基础测试并在发出 PR 后跟踪 CI 结果风格干净、可读代码必须符合 Mbed TLS 官方编码规范该规范发布在 Mbed TLS 知识库中仓库内不随附全文可移植、通用代码应以利于整个社区而非仅满足个人需求的方式编写安全性代码会同时从安全角度进行评审因此安全属性与功能正确性同等重要。从仓库结构看这些要求有具体的落点公开接口集中在 include/mbedtls/ 目录如 ssl.h、x509_crt.h实现位于 library/示例程序在 programs/测试在 tests/——贡献者修改任一模块时对应目录下的示例与测试往往也需要同步更新CONTRIBUTING.md 明确要求如有需要示例程序也要一并修改。贡献流程五步走CONTRIBUTING.md 定义的正式贡献流程如下每一步都有明确的验证依据确认需求先在 issue 列表或社区邮件列表中检索是否已有相关议题避免重复工作基于正确的分支开发以development分支为基线进行改动该分支用于准备下一个 4.x 小版本包含新功能、缺陷修复与安全修复见 BRANCHES.md先写测试写一个能证明 bug 已修复或新功能按预期工作的测试提交 PR 并配合评审根据评审意见迭代修改直至合并发布控制规模能够快速合并的贡献应当短小、聚焦单一功能或主题贡献越大评审与合并周期越长。这里的关键约束是第 2 步的分支选择bug 修复类改动应基于development而不是mainmain只包含最新已发布版本而修复是否需要回移到 LTS 分支则由下文的回移规则决定。后向兼容性API 只能扩展不能修改这是 CONTRIBUTING.md 中约束力最强的部分直接决定了贡献的可合并窗口目标将用户升级新版库时的影响降到最低。除非用户主动采用新特性、跨代升级或因安全缺陷必须修改否则用户代码不应需要任何改动。为此main开发分支与 LTS 分支之间都维护 API 兼容性详见 BRANCHES.md 中Backwards Compatibility for application code一节接口变更必须可辩护即使是主开发分支上任何 ABI/API 变更都必须是显著增强、新功能或最能通过接口变更解决的 bug 修复。若贡献包含 API 变更只有在发生 major release 时才会被合并只扩展、不修改公共接口中函数的定义不允许做改变 API 的修改只能通过扩展接口来变更。确实需要改动已有函数时将其标记为deprecated弃用若要用一个接口略有不同的新函数替代旧函数原型不同或文档化行为不同应创建带新名称的新函数保留旧函数并标记弃用计划性移除库会定期移除弃用函数这构成 API 破坏性变更但只在有计划、有结构、给用户充分预告的情况下进行。BRANCHES.md 进一步补充了可操作的细节项目采用语义化版本Semantic Versioning同一 major 版本内的小版本升级保证 API 向后兼容4.(x1) 的 API 向后兼容 4.x只在 major 变更如 3.x 到 4.0时允许打破 API 兼容而 LTS 分支在此之上还要尽量维持 ABI 兼容重链接而非重编译级别并避免代码体积、RAM 用量或构建工具最低版本的增加——唯一例外是安全修复优先但仍会尽量提供兼容选项。该文档还列举了若干不算破坏兼容的常见小版本变更例如向结构体添加或重排字段、向枚举添加条目、对原有失败场景改为成功作为合理功能扩展等。LTS 分支与回移Backport三条规则Mbed TLS 维护若干 LTS 分支其存在价值是让嵌入式/资源敏感平台的用户获得一个只有安全修复和缺陷修复、没有新特性的稳定版本——新特性可能带来代码体积或 RAM 用量的变化这在部分平台上是重大考量。因此 LTS 分支同时维护公共 API 与 ABI 的向后兼容。贡献者回移到 LTS 分支时必须遵守三条规则任何改变 API 或 ABI 的变更都不得回移凡修复了 LTS 分支中也存在的缺陷的 bug 修复必须回移到该 LTS 分支如果该修复引入了 API 变更如新增函数应重构修复方式以规避 API 变更——缺乏强理由的 API 变更不太可能被接受新功能或增强不需要回移例外包括新增测试用例、构建/测试脚本的质量改进等。CONTRIBUTING.md 同时鼓励贡献者主动将贡献回移到 LTS 分支在development分支之外。当前维护中的分支列表可在 BRANCHES.md 的Current Branches一节查询目前包括main、development、mbedtls-3.6支持至 2027 年 3 月与mbedtls-4.1支持至 2029 年 3 月项目按 18 个月节奏发布 LTS 版本每个 LTS 支持期为三年。测试function 与 data 文件驱动的生成式测试套件CONTRIBUTING.md 的 Tests 一节揭示了 Mbed TLS 测试体系的核心机制测试套件位于tests/目录是动态生成出来的。每个套件由两类文件驱动function 文件如suites/test_suite_ssl.function包含实际的测试函数代码data 文件如suites/test_suite_ssl.data包含测试用例以参数形式传递给测试函数。以 tests/suites/ 目录为例可以清楚看到.function与.data成对出现的组织方式。test_suite_error.data 展示了一个典型的 data 文件格式——标题行、depends_on:配置依赖声明、以及函数名:参数1:参数2:...形式的用例行Single low error depends_on:MBEDTLS_NET_C error_strerror:-0x0042:NET - Failed to open a socket Non existing high error error_strerror:-0x8880:UNKNOWN ERROR CODE (8880)data 文件中的depends_on:机制让测试能根据编译期配置include/mbedtls/mbedtls_config.h中的宏自动跳过不适用的用例这也解释了为何同一套测试在不同配置下可用测试数量会浮动。CONTRIBUTING.md 还给出两条测试相关硬性要求测试覆盖仓库提供测试脚本tests/scripts/basic-build-test.sh用于展示库的测试覆盖情况新代码贡献应提供与现有代码相当的覆盖率。查看 tests/scripts/basic-build-test.sh 可看到它的具体职责先以--coverage插桩构建然后依次执行单元测试tests/scripts/run-test-suites.pl、系统测试tests/ssl-opt.sh与互操作性测试tests/compat.sh最后生成覆盖率报告示例程序同步如需修改示例程序programs/下的 ssl/x509 等 demo应一并更新。此外Mbed TLS 网站知识库上有关于如何为测试套件新增测试的专门文章CONTRIBUTING.md 中的链接指向该知识库贡献者可参考。持续集成测试与 Git 钩子PR 提交后会触发 CI 测试贡献者的义务是跟踪 CI 结果并修复失败。CONTRIBUTING.md 建议在推送前启用 githooks 脚本以便尽早暴露问题。结合仓库中的 tests/git-scripts/ 目录可以了解其安装与工作方式钩子脚本存放于tests/git-scripts/需要软链接到.git/hooks才能生效。tests/git-scripts/README.md 给出了 Linux 下的安装命令ln -s ../../tests/git-scripts/pre-push.sh pre-push注意该 README 明确提示目前钩子仅在 GNU 平台上可用非 GNU 平台不要启用tests/git-scripts/pre-push.sh 的核心逻辑很简洁——它调用tests/scripts/all.sh -q -k check_*即执行所有以check_*命名的检查项如已提交的生成文件检查等。脚本以非零状态退出时阻止推送该脚本也可以脱离 git 独立运行适合手动预检。文档要求与 ChangeLog 条目规范CONTRIBUTING.md 的 Documentation 一节列出五条要求所有接口都应通过 Doxygen 文档化新 API 必须引入 Doxygen 注释Doxygen 输入文件位于 doxygen/input/复杂代码段应包含注释如需要建议添加 Readme 文件如需新增知识库KB文章请在 PR 描述中以评论形式写明必须为本贡献添加 ChangeLog 条目。第 5 条的完整规范在 ChangeLog.d/00README.md 中值得贡献者细读何时需要写条目——存在用户可见变更时库或示例程序的 bug 修复安全漏洞、行为破坏、特定配置/平台下的构建修复等、新特性/新示例程序/新平台支持、既有行为变更应少见。通常不需要的文档改进、非显著的性能改进、测试代码等用户不直接接触的部分、普通编译器告警修复。条目文件格式——文件扩展名为*.txt放在ChangeLog.d/目录类别头加缩进条目Security * Change description. * Another change description. Features * Yet another change description. This is a long change description that spans multiple lines.允许的类别共 9 个API changes、Default behavior changes、Requirement changes、New deprecations、Removals、Features、Security、Bugfix、Changes无法归类时用 Changes。书写规则每条以3 个空格 星号 空格开头续行缩进 5 个空格行宽 79 字符换行使用完整英文句子、现在时、适用时使用祈使句相关时附上 issue 编号#1234格式与 CVE 等外部引用适当致谢 bug 报告者核心原则是解释为什么而不是怎么做——面向的读者是库用户而非开发者例如 bug 修复应说明该 bug 的影响而非修复手法。仓库当前就有一个符合该格式的真实示例ChangeLog.d/serialized-data-load-hardening.txtBugfix * Reject serialized TLS 1.2 sessions whose session ID length exceeds 32, instead of accepting an out-of-range length that is later used to read past the end of the 32-byte session ID buffer.条目写好之后通过运行framework/scripts/assemble_changelog.py需从 Git 工作副本执行将ChangeLog.d中的条目合并进主 ChangeLog 文件。许可证与版权SPDX 标识与 DCO 签署CONTRIBUTING.md 对知识产权的规定与 Mbed TLS 的双重许可模式紧密相关双重许可除非文件中另有说明Mbed TLS 的文件同时提供 Apache-2.0 与 GPL-2.0-or-later 两种许可完整文本见 LICENSE 文件用户可选择以其中任一许可证取用代码贡献者的义务贡献者必须接受其贡献同时以 Apache-2.0和GPL-2.0-or-later 双许可发布SPDX 标识所有新文件在可行处都应包含标准 SPDX 许可证标识即文件头注释中的SPDX-License-Identifier: Apache-2.0 OR GPL-2.0-or-later版权归属贡献代码的版权仍归原作者新文件尽量在文件头以Copyright The Mbed TLS Contributors形式注明可在 tests/git-scripts/pre-push.sh 等脚本文件中看到该头部的标准写法DCO 签署提交代码时提交者与所有作者必须按照 dco.txt 中的《Developer Certificate of Origin》DCO 1.1声明提交内容可以合法成为项目一部分并以上述双许可提交。操作层面就是在每个 commit message 中加入标准的Signed-off-by:行若有多人贡献同一 commit每个人都应添加自己的Signed-off-by:行。dco.txt 完整收录了 DCO 1.1 的四条声明条款a–d可作为签署时的法律依据对照。小结Mbed TLS 的贡献规范可以概括为一条主线与四个硬约束主线是基于development分支、先写测试、小步提交、配合评审四个硬约束分别是——API 只能扩展不能破坏API 变更只能随 major release 合并、LTS 分支只回移不改接口的缺陷修复、用户可见变更必须有 ChangeLog 条目、每个 commit 必须带Signed-off-by签署。贡献者在动手前对照 CONTRIBUTING.md 的快速清单自查再结合 BRANCHES.md 确认目标分支与支持周期、用tests/scripts/basic-build-test.sh验证覆盖、用tests/git-scripts钩子做推送前预检即可满足仓库对 PR 的全部工程要求。【免费下载链接】mbedtlsAn open source, portable, easy to use, readable and flexible TLS library, and reference implementation of the PSA Cryptography API. Releases are on a varying cadence, typically around 3 - 6 months between releases.项目地址: https://gitcode.com/GitHub_Trending/mb/mbedtls创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考