Token导航 LogoToken导航TokenDH.com
研究检索操作浏览器github未标认证来源可访问许可证需确认审计提醒

chrome-release-verifychrome 版本验证

Agent Skill

chrome-release-verify 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

192

周安装

8

GitHub Stars

121,132

下载量

64
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:chrome-release-verify(chrome 版本验证)
来源仓库:https://github.com/electron/electron
仓库路径:skills/chrome-release-verify
安装命令:
npx skills add https://github.com/electron/electron --skill chrome-release-verify
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/electron/electron --skill chrome-release-verify

简介

验证 Chrome 安全修复能否成功回移植到指定分支。

  • 自动尝试应用补丁并通过 lint 检查,确保兼容性。
  • 本地操作不推送代码,降低误提交风险。适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。
  • 需用户提供发布分支与博客 URL 作为输入参数。
  • chrome-release-verify 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

SKILL.md

Chrome Release → Validated Backport PR

Input: $ARGUMENTS = <release-branch> <chrome-releases-blog-url> (e.g. 41-x-y https://chromereleases.googleblog.com/2026/04/stable-channel-update-for-desktop_15.html). Ask if either is missing.

The flow is local-first: nothing is pushed until every patch applies via e sync --3 and passes lint --patches.

1. Map CVE → bug → fix CL

Run /chrome-release-cls <blog-url> (or its inline procedure) to produce /tmp/cve_bugs.txt (CVE|bug|severity|desc) and a per-bug canonical fix CL. For each CL also note repo (path under src/: ., v8, third_party/{skia,angle,pdfium,dawn}, third_party/libaom/source/libaom) and gerrit-host.

Prefer the target-milestone merge CL if one exists (e.g. on 41-x-y ≈ M146, prefer the [M146] cherry-pick over the main CL) — it's already rebased and far less likely to conflict. Find it via git log --all --grep on the Change-Id, or Gerrit ?q=bug:<n>. If Chrome did *not* merge a fix to the target milestone, that's a strong signal the vulnerable code doesn't exist there — flag it for skip rather than forcing a port.

2. Prepare a synced worktree

Reuse bp-<NN> from e show configs if present, else e worktree add bp-<NN> ~/src/electron-bp-<NN> --source <current> --no-sync.

cd <root>/src/electron
git fetch origin <branch>
git checkout -B security-backport/<branch>/<short-date> origin/<branch>
e use bp-<NN>
e sync 2>&1 | tee /tmp/bp_sync.log

If sync fails with NotADirectoryError: '<root>/src/.git/objects/info/alternates', remove GIT_CACHE_PATH from the bp config's env and retry.

3. Verify IN-TREE vs NEEDS-BACKPORT

For each bug, three checks against the synced repo:

  1. git -C "$repo" log HEAD --since='1 year ago' -E --grep="\b${bug}\b" --format='%h %s'
  2. Fetch Change-Id from Gerrit, then git log HEAD --grep="^Change-Id: ${cid}$"
  3. grep -rlE "(\b${bug}\b|${cid})" <root>/src/electron/patches/

Any hit ⇒ IN-TREE. All empty ⇒ NEEDS-BACKPORT.

For each NEEDS-BACKPORT CL, also fetch its file list (/changes/<proj>~<cl>/revisions/current/files) and skip if every file is under chrome/browser/, chrome/android/, ios/, or components/**/android/ — Electron doesn't compile those.

Report the table now (CVE | Sev | Bug | Component | Verdict | CL) and the proposed backport set; get user sign-off before continuing.

4. Write patches locally (no push yet)

For each backport CL, fetch the raw patch and write it into patches/<dir>/:

curl -s "https://${host}.googlesource.com/changes/${proj//\//%2F}~${cl}/revisions/current/patch" \
  | base64 -d > "patches/${dir}/cherry-pick-${short}.patch"
echo "cherry-pick-${short}.patch" >> "patches/${dir}/.patches"

For repos with no Gerrit host e cherry-pick supports (e.g. libaom on aomedia), instead git cherry-pick the upstream commits onto the synced sub-repo HEAD and git format-patch the result.

For any newly-created patches/<dir>/, append to patches/config.json preserving the compact one-line-per-entry style:

  { "patch_dir": "src/electron/patches/<dir>", "repo": "src/third_party/<dir-or-nested-path>" }

5. Validate with e sync --3

e sync --3 2>&1 | tee /tmp/bp_sync3.log

On Patch failed at NNNN <subject>:

  • cd into the failing repo, inspect git diff for conflict markers.
  • Test-only files (e.g. web_tests/VirtualTestSuites, *_unittest.cc context drift): take ours (git checkout --ours -- <file>) if the security-relevant hunks merged cleanly.
  • Substantive code conflicts: check whether a target-milestone merge CL exists and swap to it. If none exists upstream and the surrounding code is structurally different, drop the patch (delete the file, remove from .patches and config.json) and note it for a separate manual-port PR — do not improvise security-fix semantics.
  • After resolving: git add <files> && git -c commit.gpgsign=false am --continue, then e patches <repo> to export the resolved patch, then re-run e sync --3. Repeat until clean.

6. Export → lint → re-apply loop

e patches all
node script/lint.js --patches   # must exit 0

If lint reports findings (typically trailing whitespace on + content lines), fixing them changes the bytes the patch writes, which invalidates the index <old>..<new> blob hashes that e patches baked in. Hand-editing a .patch and pushing it as-is will pass lint locally but fail CI's Apply Patches re-export check with a one-line index hash diff.

So whenever lint (or you) modifies any .patch file after export, round-trip once more:

# fix the lint findings in patches/**/*.patch, then:
e sync            # re-apply the edited patches (no --3 needed; they applied cleanly last time)
e patches all     # re-export so index blob hashes match the edited content
node script/lint.js --patches      # must now exit 0
git diff --quiet -- patches/ || { echo "patches changed again — repeat the loop"; }

Repeat until lint --patches exits 0 and git diff -- patches/ is empty after the final e patches all. Only then is the patch set CI-stable.

7. Commit, push, PR

git add patches/
git commit -m "chore: cherry-pick <N> changes from <dirs>"
git push origin HEAD
gh pr create --repo electron/electron --base <branch> --head <this-branch> \
  --title "chore: cherry-pick <N> changes from <dirs>" \
  --label "<branch>" --label backport-check-skip --label semver/patch --label "security 🔒" \
  --body-file /tmp/pr_body.md

PR body format:

Backports the following changes:

* [`<shortCommit>`](<gerrit-CL-url>) from <patchDir> — <subject> ([<bug>](https://crbug.com/<bug>), CVE-YYYY-NNNN)
* ...

Notes: Security: backported fixes for CVE-YYYY-NNNN, CVE-YYYY-NNNN, ....

Short commit links to the Gerrit CL; bug links to crbug.com; CVE comes from the blog mapping (the patch's own Bug: footer may differ); Notes: is the last line. Mention any dropped patches (with reason) above the Notes: line.

Restore e use <previous> when done.

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

35.91%
按下载量换算23

Claude

30.03%
按下载量换算19

Cursor

15.86%
按下载量换算10

Gemini CLI

9.59%
按下载量换算6

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

可疑

权限和风险

操作浏览器

该 Skill 可能涉及浏览器控制能力,使用时可能读取或操作网页内容,需要在受控环境中确认权限边界。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在 warning/failed 结果,不能写成本站确认安全。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills