======================== Suricata 向后移植指南 ======================== 本文档描述了如何将内容向后移植到当前稳定版Suricata发行版的过程。大多数情况下，这涉及安全修复和/或错误修复；但在某些情况下，新功能也可能被移植到旧版Suricata中。 任何时候都存在多个Suricata版本： * 主分支（Master） * 主要稳定版 * 旧稳定版 例如当前基于以下分支的3个发行版： * master: 8.0.0-dev，当前开发分支 * main-7.0.x：主要稳定版（注意我们正在调整命名规范） * master-6.0.x：旧稳定版 关于Suricata的发布节奏和*生命周期终止*政策，请参阅 https://suricata.io/our-story/eol-policy/。 后续章节将讨论何时进行移植、移植内容以及相关准则。 应该移植哪些内容？ -------------------------- 通常团队创建工单时，我们会添加*Needs backport*相关标签，必要的移植任务会自动生成。如果您处理的工单没有此类标签或关联的移植任务，则可能无需移植。若您认为该问题需要移植，请在工单或相关PR中告知我们。但有时我们可能会遗漏这些。 决定移植内容的基本原则： * 安全修复（参见我们的`安全政策 `_） * 错误修复 * 少数情况下，若有充分理由，新功能也会被移植 .. 注意:: 例外情况 可能存在"遗漏移植"的情况——某些问题可能未被标记为需要移植，或某些PR在无关联工单的情况下被合并。 本指南可能无法覆盖所有场景。如有疑问，请在移植工单或PR中联系团队。 选择概述 ------------------ 所有待移植项都应评估以下方面： * 风险预估：改动是否会引入新缺陷？需考虑变更范围和影响项 * 行为变更：移植对系统行为的改变程度。例如解码新增封装协议的小改动可能导致更多流量进入Suricata * 默认设置：若问题改变行为，能否设为可选？实现成本如何？ 创建移植工单——新问题 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Redmine：针对安全和错误修复，创建新Redmine工单时需标记"Needs backport to x.0"标签，其中x.0是受支持的Suricata版本（如7.0.x）。 创建移植工单——现有问题/PR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 我们力求减少"遗漏移植"（即应移植但未移植的工作）。这种情况常发生在无Redmine工单或工单未标记移植需求时。 因此我们将定期审查： * 未标记移植的Redmine工单（包括近期关闭的），确定哪些需要添加标签 * 无关联Redmine工单的PR。需要移植的应标记*needs backport* 随后定期为上述识别项创建移植工单。此时会评估适用的目标版本。某些针对master或当前版本的报告可能不适用于旧版。 Git移植工作流 --------------------- 若您处理的任务需要移植，请仅在master分支的PR合并后开始移植流程。步骤如下： * *确认需移植的提交*：从合并到master的PR开始，仅选择该问题相关的提交 * *将每个提交逐一移植到新分支*：从最旧的提交开始。使用``git cherry-pick -x commit-hash``（其中``commit-hash``是master或main-7.0x中待移植提交的哈希值），这会保留与原始提交的关联 * *解决冲突*：某些移植提交可能包含合并冲突。若冲突较小，直接在移植提交中修正 * *添加额外提交*（如需要）：例如调整移植代码以适应旧版行为 .. 注意:: 提交哈希 我们有CI检查确保移植行的有效性。 .. 注意:: 例外情况 有时master的修复方案不适用于稳定版或旧版。此时移植过程不通过摘取提交，而是专门为特定版本实现修复。 创建PR： ~~~~~~~~~~~~ 请在标题注明这是移植PR（例如*(7.0.x-backport)*），并添加相关里程碑标签。 在PR描述中注明关联的移植工单。 质量保证 -- 必要时添加suricata-verify的PR。某些现有suricata-verify测试可能需要调整版本规范。