Electron 安全回移实战从 Chrome Releases 公告到上游修复 CL 的定位方法chrome-release-cls 技能解析【免费下载链接】electron:electron: Build cross-platform desktop apps with JavaScript, HTML, and CSS项目地址: https://gitcode.com/GitHub_Trending/el/electronElectron 紧跟 Chromium 上游演进每当 Chrome Stable 发布安全更新Chrome Releases 博客维护者需要知道每一条 CVE 修复具体对应上游 Gerrit 上的哪个 CLChange List才能完成补丁回移backport与溯源。本文解析仓库内置的 chrome-release-cls 技能完整讲解Chrome Releases 博客 → CVE/bug 提取 → 本地 git 历史检索 → Gerrit CL 映射的完整工作流并结合 Electron 的补丁系统说明该映射结果在回移流程中的作用。1. 这个技能解决什么问题在 Electron 仓库中上游 Chromium/V8 的改动不是以依赖包形式引入而是以 git 补丁形式管理patches/目录下按目标仓库分目录存放.patch文件由 patches/config.json 描述每个补丁目录应用到哪个子仓库补丁按同目录.patches文件列出的顺序应用详见 docs/development/patches.md。当 Chrome 发布安全更新后要把修复引入 Electron 的发布分支核心前提是先回答一个问题每条 CVE 是由上游哪个 CL 修复的只有拿到 Gerrit CL才能拉取修复补丁的原始 diff/changes/project~cl/revisions/current/patch将其写入patches/dir/并登记到.patches与 patches/config.json用e sync --3 补丁 lint 验证后提交回移 PR该回移流程由同目录的 chrome-release-verify 技能 定义其第 1 步就是调用本技能的流程。chrome-release-cls技能正是这个映射环节的标准化操作手册输入一个https://chromereleases.googleblog.com/...URL若参数为空则需向用户索取输出每条 CVE 对应的 canonical fix CL。2. 第一步从博客 HTML 提取 CVE → bug ID 对Chrome Releases 博客把 crbug 编号埋在a标签里因此需要先剥离 HTML 标签再正则提取。技能中给出的完整命令为curl -sL $URL | python3 -c import sys, re, html t re.sub(r[^], , sys.stdin.read()) t re.sub(r\s, , html.unescape(t)) seen set() for m in re.finditer(r\[\s*(\d{6,})\s*\]\s*(Critical|High|Medium|Low)\s*(CVE-\d{4}-\d):\s*([^.]?)\., t): if m.group(3) in seen: continue seen.add(m.group(3)) print(f{m.group(3)}|{m.group(1)}|{m.group(2)}|{m.group(4).strip()}) /tmp/cve_bugs.txt cat /tmp/cve_bugs.txt命令要点正则\[\s*(\d{6,})\s*\]\s*(Critical|High|Medium|Low)\s*(CVE-\d{4}-\d):\s*([^.]?)\.匹配博客中六位数以上 bug ID 严重级别 CVE 编号 描述的行文格式用seen集合按 CVE 去重同一 CVE 可能对应多条 bug输出格式为CVE|bug|severity|desc四列写入/tmp/cve_bugs.txt供后续步骤逐行驱动。降级方案如果博客改版导致正则提取为空回退到grep -oE CVE-[0-9]{4}-[0-9]与grep -oE crbug\.com/[0-9]分别提取再按出现顺序配对。3. 第二步在本地 git 历史中查找修复 CL技能假设本地存在 Chromium checkoutElectron 仓库位于 chromium 根目录之下技能中的路径/root/src/electron/src表示 chromium 根即electron/的父目录。查找逻辑在每个候选仓库的 git 历史中搜索 commit message 的Bug:或Fixed:footer 含目标 bug ID 的提交再从中提取Reviewed-on:行得到 Gerrit URL。3.1 按组件关键词选择仓库不同组件的修复落在不同子仓库技能给出的映射规则组件关键词目标仓库相对 chromium 根ANGLEthird_party/angleSkia、Graphitethird_party/skiaPDFiumthird_party/pdfiumDawnthird_party/dawnV8、Turbofan、Maglev、Turboshaftv8其余.chromium/src规则要求即使组件提示仓库未命中也必须回退到.再搜一次。技能内嵌的驱动函数即按此顺序遍历cd /root/src/electron/src # chromium root (parent of electron/) lookup() { local bug$1 repos$2 for repo in $repos . v8 third_party/skia third_party/angle third_party/pdfium third_party/dawn; do local hits hits$(git -C $repo log --all --since6 months ago -E \ --grep(Bug|Fixed):.*\\b${bug}\\b --format%H 2/dev/null | sort -u) [[ -z $hits ]] continue while read -r h; do git -C $repo log -1 --format%B $h | grep ^Reviewed-on: | sed s/^/ / echo ↳ $(git -C $repo log -1 --format%s $h) done $hits return 0 done echo (not found locally) }检索参数的含义--all搜索所有引用包括已合并的 milestone 分支--since6 months ago安全修复通常落在近几个月的提交中窗口限制避免全量扫描-E --grep(Bug|Fixed):.*\b${bug}\b扩展正则匹配 footer\b词边界防止 bug ID 子串误配如 bug 1234 误匹配 12345命中后用git log -1 --format%B取完整 bodygrep ^Reviewed-on:提取 Gerrit 地址%s取 commit 标题作为佐证。3.2 区分主干 CL 与分支 cherry-pick/tmp/cve_bugs.txt驱动逐 bug 查找后同一 bug 常出现多条命中。技能规定优先选取非[M1xx]前缀的 commit 标题作为 canonical 主干 CL带[M1xx]前缀的是向 milestone 分支的 cherry-pick。4. 第三步未命中时的处理策略本地搜索为空不代表修复不存在技能定义了四档递进的补救手段拉新再搜git -C repo fetch origin后用--remotes重搜——本地 checkout 可能落后于实际修复提交。直接查询 Gerritcurl -s https://chromium-review.googlesource.com/changes/?qbug:${BUG}n10 | tail -n 2 | python3 -m json.tool同一模式可尝试skia-review、pdfium-review、dawn-review、aomedia-review各实例。b/bug 格式特例Skia、Graphite、Dawn这些仓库在 commit message 中以b/id而非Bug: idfooter 记录 bugGerrit 的bug:查询会返回空。应改用message:id搜索curl -s https://skia-review.googlesource.com/changes/?qmessage:${BUG}n5 | tail -n 2Dawn 组件同理适用dawn-review.googlesource.com。从 merge CL 反查主干 CL当只找到[M1xx]merge CL 时查询 CL 详情的cherry_pick_of_change字段获取原始主干 CL 编号curl -s https://chromium-review.googlesource.com/changes/${CL_NUM}?oCURRENT_REVISION | tail -n 2 | python3 -c import sys, json d json.load(sys.stdin) print(d.get(cherry_pick_of_change, none)) 若以上全部落空且 bug 报告时间很新尤其由 Google Threat Intelligence 报告或标注 in-the-wild修复 CL 大概率仍处于访问限制access-restricted状态——此时应如实报告该状态而不是猜测。5. 第四步特殊情形处理Roll CL 不是修复本身对于修复先落在上游仓库的组件PDFium、Dawn、Skia、Graphite、libaom、libvpx、ffmpegchromium-review 上命中的会是Roll src/third_party/...滚动提交。不能把 roll CL 当作修复 CL 报告而应直接查询组件自己的 Gerrit 实例拿到真正的 fixing CLPDFium →pdfium-review.googlesource.combug:或message:查询Dawn →dawn-review.googlesource.commessage:查询b/格式Skia / Graphite →skia-review.googlesource.commessage:查询b/格式libaom →aomedia-review.googlesource.com仅当上游 Gerrit 实例也无结果时才回退为报告 roll CL并注明实际修复在上游但具体 CL 未能识别。多条Reviewed-on:行cherry-pick 会保留原始的Reviewed-on:行并追加一条新的第一条才是原始 CL。一个 bug 多个修复 CL可能存在修复 后续加固follow-up hardening多条 CL需要全部列出。6. 第五步输出规范技能要求按严重级别分组输出 markdown 表格CVE | Bug | Component | Fix CL (main)bug 以https://crbug.com/id形式链接同时将包含所有分支 merge 的原始输出保存到/tmp/cve_cls.txt并在结果中提及该路径。这份本地映射文件也正是下游回移流程chrome-release-verify消费 CVE↔CL 对应关系的来源。7. 结合 Electron 仓库映射结果如何被消费理解这条映射的价值需要看它在 Electron 补丁体系中的落点补丁系统的组织结构。每个补丁目录如 patches/chromium、patches/v8、patches/node 等包含.patch文件与一个.patches顺序清单patches/config.json 将patch_dir映射到实际子仓库例如src/electron/patches/chromium→srcsrc/electron/patches/v8→src/v8src/electron/patches/node→src/third_party/electron_node共 14 个目标。补丁文件本身是标准的 mbox 格式例如 patches/chromium/web_contents.patch 中可见index old..new的 blob 哈希行——e patches导出时烘焙这些哈希是后续 CI 校验的基准。回移流程对 CL 的直接依赖。chrome-release-verify 技能 描述完整回移链路第 1 步调用本技能产出/tmp/cve_bugs.txt与每 bug 的 canonical fix CL并记录repo路径与gerrit-host随后对需要回移的 CL 执行curl -s https://${host}.googlesource.com/changes/${proj//\//%2F}~${cl}/revisions/current/patch | base64 -d patches/${dir}/cherry-pick-${short}.patch拉取补丁登记进.patches并在 patches/config.json 保持每行一个条目的紧凑风格追加新目录条目。可见没有第一步的准确 CL 映射后续拉补丁、验证、提 PR 均无从谈起。验证手段与补丁一致性。回移补丁落库后要经e sync --3三向合并应用与 script/lint.js 的补丁 lint该规则遍历config.json各目标校验.patches清单与目录内实际文件一一对应、无重复登记双重把关若 lint 修复改动过补丁字节还需重新e synce patches all使indexblob 哈希与新内容一致才能保证 CI 的 patch 重导出检查通过。补丁的手工新增/编辑/冲突解决操作则可参照 docs/development/patches.md 中git-import-patches/git-export-patches对应 script/git-import-patches 与 script/git-export-patches的标准做法。版本升级场景的交叉印证。Chromium 版本滚动e sync --3修复补丁冲突由 electron-chromium-upgrade 技能 规范其提交格式要求补丁提交标题为{CL-Number}: {上游 CL 原标题}并在 body 中附Ref: {URL}——同样以修复源自哪个 Gerrit CL为锚点与本技能建立的 CL 溯源体系一脉相承。8. 适用前提与限制本地 checkout 布局需要 chromium 源码树已检出且 Electron 位于其下技能中cd /root/src/electron/src即 chromium 根v8、third_party/skia、third_party/angle、third_party/pdfium、third_party/dawn等子仓库需为独立 git 仓库才能分别执行git -C检索。时间窗口--since6 months ago是启发式窗口超期或非常规落地的修复可能漏检此时应改用fetch--remotes或 Gerrit 直查。网络依赖补救手段依赖对chromium-review/skia-review/pdfium-review/dawn-review/aomedia-review等 googlesource 实例的访问访问受限的安全 CL 只能标记状态而非获取内容。输出边界映射结果尤其 CVE↔CL 对应关系应保留在本地如/tmp/cve_cls.txt供维护者核对按回移流程的公开 PR 撰写规范CVE 编号与 crbug 链接不应出现在公开的 PR 标题、正文中。9. 小结chrome-release-cls技能把Chrome 安全更新 → 上游修复 CL这一 Electron 安全回移的前置环节压缩为五步可执行流程HTML 剥标签提取 CVE/bug 对、按组件选仓库做 git 历史检索、多档未命中补救fetch 重搜 / Gerritbug:与message:查询 /cherry_pick_of_change反查 / 受限状态报告、Roll CL 与 cherry-pick 等特殊情形的甄别以及按严重级别分组的标准化输出。它既是一份人工可照做的操作手册也是 chrome-release-verify 自动化回移流程的第 1 步依赖其产出的/tmp/cve_bugs.txt与/tmp/cve_cls.txt是后续写补丁、e sync --3验证和提交回移 PR 的直接输入。【免费下载链接】electron:electron: Build cross-platform desktop apps with JavaScript, HTML, and CSS项目地址: https://gitcode.com/GitHub_Trending/el/electron创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Electron 安全回移实战：从 Chrome Releases 公告到上游修复 CL 的定位方法（chrome-release-cls 技能解析）
Electron 安全回移实战从 Chrome Releases 公告到上游修复 CL 的定位方法chrome-release-cls 技能解析【免费下载链接】electron:electron: Build cross-platform desktop apps with JavaScript, HTML, and CSS项目地址: https://gitcode.com/GitHub_Trending/el/electronElectron 紧跟 Chromium 上游演进每当 Chrome Stable 发布安全更新Chrome Releases 博客维护者需要知道每一条 CVE 修复具体对应上游 Gerrit 上的哪个 CLChange List才能完成补丁回移backport与溯源。本文解析仓库内置的 chrome-release-cls 技能完整讲解Chrome Releases 博客 → CVE/bug 提取 → 本地 git 历史检索 → Gerrit CL 映射的完整工作流并结合 Electron 的补丁系统说明该映射结果在回移流程中的作用。1. 这个技能解决什么问题在 Electron 仓库中上游 Chromium/V8 的改动不是以依赖包形式引入而是以 git 补丁形式管理patches/目录下按目标仓库分目录存放.patch文件由 patches/config.json 描述每个补丁目录应用到哪个子仓库补丁按同目录.patches文件列出的顺序应用详见 docs/development/patches.md。当 Chrome 发布安全更新后要把修复引入 Electron 的发布分支核心前提是先回答一个问题每条 CVE 是由上游哪个 CL 修复的只有拿到 Gerrit CL才能拉取修复补丁的原始 diff/changes/project~cl/revisions/current/patch将其写入patches/dir/并登记到.patches与 patches/config.json用e sync --3 补丁 lint 验证后提交回移 PR该回移流程由同目录的 chrome-release-verify 技能 定义其第 1 步就是调用本技能的流程。chrome-release-cls技能正是这个映射环节的标准化操作手册输入一个https://chromereleases.googleblog.com/...URL若参数为空则需向用户索取输出每条 CVE 对应的 canonical fix CL。2. 第一步从博客 HTML 提取 CVE → bug ID 对Chrome Releases 博客把 crbug 编号埋在a标签里因此需要先剥离 HTML 标签再正则提取。技能中给出的完整命令为curl -sL $URL | python3 -c import sys, re, html t re.sub(r[^], , sys.stdin.read()) t re.sub(r\s, , html.unescape(t)) seen set() for m in re.finditer(r\[\s*(\d{6,})\s*\]\s*(Critical|High|Medium|Low)\s*(CVE-\d{4}-\d):\s*([^.]?)\., t): if m.group(3) in seen: continue seen.add(m.group(3)) print(f{m.group(3)}|{m.group(1)}|{m.group(2)}|{m.group(4).strip()}) /tmp/cve_bugs.txt cat /tmp/cve_bugs.txt命令要点正则\[\s*(\d{6,})\s*\]\s*(Critical|High|Medium|Low)\s*(CVE-\d{4}-\d):\s*([^.]?)\.匹配博客中六位数以上 bug ID 严重级别 CVE 编号 描述的行文格式用seen集合按 CVE 去重同一 CVE 可能对应多条 bug输出格式为CVE|bug|severity|desc四列写入/tmp/cve_bugs.txt供后续步骤逐行驱动。降级方案如果博客改版导致正则提取为空回退到grep -oE CVE-[0-9]{4}-[0-9]与grep -oE crbug\.com/[0-9]分别提取再按出现顺序配对。3. 第二步在本地 git 历史中查找修复 CL技能假设本地存在 Chromium checkoutElectron 仓库位于 chromium 根目录之下技能中的路径/root/src/electron/src表示 chromium 根即electron/的父目录。查找逻辑在每个候选仓库的 git 历史中搜索 commit message 的Bug:或Fixed:footer 含目标 bug ID 的提交再从中提取Reviewed-on:行得到 Gerrit URL。3.1 按组件关键词选择仓库不同组件的修复落在不同子仓库技能给出的映射规则组件关键词目标仓库相对 chromium 根ANGLEthird_party/angleSkia、Graphitethird_party/skiaPDFiumthird_party/pdfiumDawnthird_party/dawnV8、Turbofan、Maglev、Turboshaftv8其余.chromium/src规则要求即使组件提示仓库未命中也必须回退到.再搜一次。技能内嵌的驱动函数即按此顺序遍历cd /root/src/electron/src # chromium root (parent of electron/) lookup() { local bug$1 repos$2 for repo in $repos . v8 third_party/skia third_party/angle third_party/pdfium third_party/dawn; do local hits hits$(git -C $repo log --all --since6 months ago -E \ --grep(Bug|Fixed):.*\\b${bug}\\b --format%H 2/dev/null | sort -u) [[ -z $hits ]] continue while read -r h; do git -C $repo log -1 --format%B $h | grep ^Reviewed-on: | sed s/^/ / echo ↳ $(git -C $repo log -1 --format%s $h) done $hits return 0 done echo (not found locally) }检索参数的含义--all搜索所有引用包括已合并的 milestone 分支--since6 months ago安全修复通常落在近几个月的提交中窗口限制避免全量扫描-E --grep(Bug|Fixed):.*\b${bug}\b扩展正则匹配 footer\b词边界防止 bug ID 子串误配如 bug 1234 误匹配 12345命中后用git log -1 --format%B取完整 bodygrep ^Reviewed-on:提取 Gerrit 地址%s取 commit 标题作为佐证。3.2 区分主干 CL 与分支 cherry-pick/tmp/cve_bugs.txt驱动逐 bug 查找后同一 bug 常出现多条命中。技能规定优先选取非[M1xx]前缀的 commit 标题作为 canonical 主干 CL带[M1xx]前缀的是向 milestone 分支的 cherry-pick。4. 第三步未命中时的处理策略本地搜索为空不代表修复不存在技能定义了四档递进的补救手段拉新再搜git -C repo fetch origin后用--remotes重搜——本地 checkout 可能落后于实际修复提交。直接查询 Gerritcurl -s https://chromium-review.googlesource.com/changes/?qbug:${BUG}n10 | tail -n 2 | python3 -m json.tool同一模式可尝试skia-review、pdfium-review、dawn-review、aomedia-review各实例。b/bug 格式特例Skia、Graphite、Dawn这些仓库在 commit message 中以b/id而非Bug: idfooter 记录 bugGerrit 的bug:查询会返回空。应改用message:id搜索curl -s https://skia-review.googlesource.com/changes/?qmessage:${BUG}n5 | tail -n 2Dawn 组件同理适用dawn-review.googlesource.com。从 merge CL 反查主干 CL当只找到[M1xx]merge CL 时查询 CL 详情的cherry_pick_of_change字段获取原始主干 CL 编号curl -s https://chromium-review.googlesource.com/changes/${CL_NUM}?oCURRENT_REVISION | tail -n 2 | python3 -c import sys, json d json.load(sys.stdin) print(d.get(cherry_pick_of_change, none)) 若以上全部落空且 bug 报告时间很新尤其由 Google Threat Intelligence 报告或标注 in-the-wild修复 CL 大概率仍处于访问限制access-restricted状态——此时应如实报告该状态而不是猜测。5. 第四步特殊情形处理Roll CL 不是修复本身对于修复先落在上游仓库的组件PDFium、Dawn、Skia、Graphite、libaom、libvpx、ffmpegchromium-review 上命中的会是Roll src/third_party/...滚动提交。不能把 roll CL 当作修复 CL 报告而应直接查询组件自己的 Gerrit 实例拿到真正的 fixing CLPDFium →pdfium-review.googlesource.combug:或message:查询Dawn →dawn-review.googlesource.commessage:查询b/格式Skia / Graphite →skia-review.googlesource.commessage:查询b/格式libaom →aomedia-review.googlesource.com仅当上游 Gerrit 实例也无结果时才回退为报告 roll CL并注明实际修复在上游但具体 CL 未能识别。多条Reviewed-on:行cherry-pick 会保留原始的Reviewed-on:行并追加一条新的第一条才是原始 CL。一个 bug 多个修复 CL可能存在修复 后续加固follow-up hardening多条 CL需要全部列出。6. 第五步输出规范技能要求按严重级别分组输出 markdown 表格CVE | Bug | Component | Fix CL (main)bug 以https://crbug.com/id形式链接同时将包含所有分支 merge 的原始输出保存到/tmp/cve_cls.txt并在结果中提及该路径。这份本地映射文件也正是下游回移流程chrome-release-verify消费 CVE↔CL 对应关系的来源。7. 结合 Electron 仓库映射结果如何被消费理解这条映射的价值需要看它在 Electron 补丁体系中的落点补丁系统的组织结构。每个补丁目录如 patches/chromium、patches/v8、patches/node 等包含.patch文件与一个.patches顺序清单patches/config.json 将patch_dir映射到实际子仓库例如src/electron/patches/chromium→srcsrc/electron/patches/v8→src/v8src/electron/patches/node→src/third_party/electron_node共 14 个目标。补丁文件本身是标准的 mbox 格式例如 patches/chromium/web_contents.patch 中可见index old..new的 blob 哈希行——e patches导出时烘焙这些哈希是后续 CI 校验的基准。回移流程对 CL 的直接依赖。chrome-release-verify 技能 描述完整回移链路第 1 步调用本技能产出/tmp/cve_bugs.txt与每 bug 的 canonical fix CL并记录repo路径与gerrit-host随后对需要回移的 CL 执行curl -s https://${host}.googlesource.com/changes/${proj//\//%2F}~${cl}/revisions/current/patch | base64 -d patches/${dir}/cherry-pick-${short}.patch拉取补丁登记进.patches并在 patches/config.json 保持每行一个条目的紧凑风格追加新目录条目。可见没有第一步的准确 CL 映射后续拉补丁、验证、提 PR 均无从谈起。验证手段与补丁一致性。回移补丁落库后要经e sync --3三向合并应用与 script/lint.js 的补丁 lint该规则遍历config.json各目标校验.patches清单与目录内实际文件一一对应、无重复登记双重把关若 lint 修复改动过补丁字节还需重新e synce patches all使indexblob 哈希与新内容一致才能保证 CI 的 patch 重导出检查通过。补丁的手工新增/编辑/冲突解决操作则可参照 docs/development/patches.md 中git-import-patches/git-export-patches对应 script/git-import-patches 与 script/git-export-patches的标准做法。版本升级场景的交叉印证。Chromium 版本滚动e sync --3修复补丁冲突由 electron-chromium-upgrade 技能 规范其提交格式要求补丁提交标题为{CL-Number}: {上游 CL 原标题}并在 body 中附Ref: {URL}——同样以修复源自哪个 Gerrit CL为锚点与本技能建立的 CL 溯源体系一脉相承。8. 适用前提与限制本地 checkout 布局需要 chromium 源码树已检出且 Electron 位于其下技能中cd /root/src/electron/src即 chromium 根v8、third_party/skia、third_party/angle、third_party/pdfium、third_party/dawn等子仓库需为独立 git 仓库才能分别执行git -C检索。时间窗口--since6 months ago是启发式窗口超期或非常规落地的修复可能漏检此时应改用fetch--remotes或 Gerrit 直查。网络依赖补救手段依赖对chromium-review/skia-review/pdfium-review/dawn-review/aomedia-review等 googlesource 实例的访问访问受限的安全 CL 只能标记状态而非获取内容。输出边界映射结果尤其 CVE↔CL 对应关系应保留在本地如/tmp/cve_cls.txt供维护者核对按回移流程的公开 PR 撰写规范CVE 编号与 crbug 链接不应出现在公开的 PR 标题、正文中。9. 小结chrome-release-cls技能把Chrome 安全更新 → 上游修复 CL这一 Electron 安全回移的前置环节压缩为五步可执行流程HTML 剥标签提取 CVE/bug 对、按组件选仓库做 git 历史检索、多档未命中补救fetch 重搜 / Gerritbug:与message:查询 /cherry_pick_of_change反查 / 受限状态报告、Roll CL 与 cherry-pick 等特殊情形的甄别以及按严重级别分组的标准化输出。它既是一份人工可照做的操作手册也是 chrome-release-verify 自动化回移流程的第 1 步依赖其产出的/tmp/cve_bugs.txt与/tmp/cve_cls.txt是后续写补丁、e sync --3验证和提交回移 PR 的直接输入。【免费下载链接】electron:electron: Build cross-platform desktop apps with JavaScript, HTML, and CSS项目地址: https://gitcode.com/GitHub_Trending/el/electron创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考