chrome-release-verify

Backport and validate Chrome security CVE fixes into Electron release branches.

123k|17.5k|Updated Apr 12, 2013
One-click install
npx skills add https://github.com/electron/electron --skill chrome-release-verify
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: chrome-release-verify
Source: https://github.com/electron/electron/tree/main/.claude/skills/chrome-release-verify
Command: npx skills add https://github.com/electron/electron --skill chrome-release-verify

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Manually mapping Chrome security release blog posts to Electron release branches, identifying which CVE fixes are already present, and producing conflict-free cherry-pick patches is error-prone and time-consuming. This Skill automates the entire backport workflow from CVE-to-CL mapping through validated PR creation.

Core Features & Use Cases

  • CVE-to-CL Mapping: Parses Chrome Releases blog posts to extract CVE identifiers, associated bugs, severity, and canonical fix CLs from Gerrit.
  • In-Tree Verification: Checks the synced Electron source via git log and patch directory greps to determine whether each CVE fix is already present.
  • Patch Generation & Validation: Writes cherry-pick patches locally, validates them with e sync --3 and node script/lint.js --patches, and resolves conflicts (test-only drift, target-milestone merge CLs, or drop-and-flag for manual port).
  • PR Creation: Pushes a single backport PR following the Electron PR template with appropriate labels, keeping CVE details out of the public PR body.

Quick Start

Backport the Chrome security release at the provided blog URL to the specified Electron release branch and open a validated PR.

Frequently Asked Questions about chrome-release-verify

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I backport a Chrome security release to an Electron release branch?

Run this skill with the release branch and Chrome Releases blog URL as arguments. It maps CVEs to Gerrit CLs, verifies which fixes are already in-tree, writes cherry-pick patches, validates them with `e sync --3` and `lint --patches`, then opens a single PR.

How to check if a specific CVE is already in an Electron release branch?

The skill runs three checks against the synced source: git log grep on the bug number, git log grep on the Change-Id, and grep across the patches directory. Any hit indicates the fix is already in-tree.

What happens when a cherry-pick patch fails to apply cleanly?

For test-only file conflicts, the skill takes ours if security-relevant hunks merged cleanly. For substantive code conflicts, it swaps to a target-milestone merge CL if available, or drops the patch and flags it for a separate manual-port PR.

Why does lint --patches fail after editing patch files manually?

Editing patches changes the bytes written, which invalidates the index blob hashes that `e patches` baked in. The skill handles this with a round-trip loop: re-apply via `e sync`, re-export via `e patches all`, and re-run lint until both lint passes and `git diff -- patches/` is empty.

Which Chrome CLs should be skipped during Electron backport?

CLs whose entire file list falls under chrome/browser/, chrome/android/, ios/, or componentsandroid/ are skipped because Electron does not compile those paths. CLs without an upstream target-milestone merge where the surrounding code is structurally different are also dropped.