SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsarkweb-security-patch-fetch

arkweb-security-patch-fetch

Security & auditing

View repository

Updated 10-16 03:11

About this skill

ArkWeb Patch Fetch

Used for arkweb-security-patch-fetcher。

When to use this skill

Use this skill after vulnerability intake has selected upstream fix PRs/CLs. It fetches or locates the exact patch files and modified file list used by later ArkWeb impact and merge stages.

Input

  • .ace-outputs/{runId}/{issue_id}/01_issue_analysis.md
  • .ace-outputs/{runId}/{issue_id}/01_issue_analysis.json
  • Where upstream_fix_prs[] is the only trusted entry point; do not re-expand the scraping scope from similar titles or the same directory.

Output

Write to the same issue directory:

  • .ace-outputs/{runId}/{issue_id}/02_patch_fetch.md
  • .ace-outputs/{runId}/{issue_id}/02_patch_fetch.json
  • Archive the patch file to .ace-outputs/{runId}/{issue_id}/patches/

No files may be written to the root directory; do not generate 02_patch_fetch.index.md/json or .ace-outputs/{runId}/patches/。

Detailed output structure is in references/patch-fetch-output.md.

Scripts

Prefer using the built-in script to scrape and validate the patch; do not regenerate temporary Python scripts at runtime:

python3 skills/arkweb-security-patch-fetch/scripts/fetch_chromium_patch.py \
  --project-root <context.codebase> \
  --output-root <context.projectRoot>/.ace-outputs/<runId>

Optional parameters:

  • --issue-id <issue_id>: process only a single issue;
  • --offline: do not go online, only based on upstream_fix_prs[] generate reproducible scraping commands and blocking explanations.

Script capabilities:

  • Scan {issue_id}/01_issue_analysis.json；
  • The forced output directory can only be <context.projectRoot>/.ace-outputs/<runId>, and must not be written to the ACEHarness run log directory; the real ArkWeb source root uses context.codebase；
  • Use only upstream_fix_prs[] 's first primary fix candidate; subsequent candidates are written to excluded_candidates[]；
  • Supports Chromium Gerrit CL and Gitiles commit patch URLs;
  • Write the patch to {issue_id}/patches/, and generate 02_patch_fetch.md/json；
  • Perform standard diff signature validation on the patch content to avoid HTML, JSON metadata, or error pages being treated as patches.

During the adjudication phase, an independent validation script can be used to review existing patch_files[]：

python3 skills/arkweb-security-patch-fetch/scripts/validate_patch_files.py \
  --project-root <context.codebase> \
  --output-root <context.projectRoot>/.ace-outputs/<runId>

Field ownership boundaries:

  • This phase must fill in: the confirmed primary fix PR/CL, the list of modified files, the local patch file, the scraping commands, and the reasons for candidate exclusion.
  • This phase must not rewrite: the Issue basic fields, or the semantic audit conclusions of the upstream fix PR/CL.
  • This phase must not fill in final values: ArkWeb affected/unaffected, responsibility area, feature tree impact, or whether retention is recommended.

Rules

  • Prefer directly obtaining the primary fix explicitly specified in the issue, upstream CL, or PR.
  • Do not additionally scrape any dependency patches, even if they are mentioned upstream; retain only the current primary fix itself.
  • Do not treat other CLs / PRs with similar titles, in the same component, same directory, or by the same author as the fix patch.
  • Do not mix candidate patches that are not explicitly referenced by the primary fix into the results, even if they appear related.
  • Must distinguish between the fix PR/CL and the PR/CL that introduced the bug;culprit、bisect、introduced by、caused by、regression range、first bad PR/CLs semantically pointed to by etc. can only serve as root cause or version range evidence, and must not be scraped as patch targets.
  • If upstream_fix_prs[] the candidate in appears to be a bug-introducing PR/CL rather than a fix PR/CL, it must be recorded in excluded_candidates[] and block scraping; its patch must not be downloaded as a fix.
  • If the current primary fix cannot be confirmed separately or cannot be obtained directly, fail explicitly; do not fill in with other patches.
  • When unable to go online, record the failed commands and the precise patch links that require manual provision.
  • Do not treat an uncertain CL as a fix patch.
  • If the network is available, for a Gerrit CL you may first try https://chromium-review.googlesource.com/changes/{project}~{cl}/revisions/current/files to obtain the file list, and for the patch you may try .../revisions/current/patch?download or the Gerrit download link; when it fails, record the HTTP status and command.
  • After downloading the patch file, content validation must be performed; do not only look at the HTTP command return, file existence, or file size:
    • A valid .patch/.diff must contain one of the standard diff signals:diff --git、Index:、--- a/ + +++ b/, or the mbox patch's From <hash> + Subject: + diff hunks；
    • If the content is an HTML error page,<!DOCTYPE html>、<html, HTTP error text, Gerrit/Gitiles error pages,)]}' JSON metadata must be marked as invalid patch;
    • metadata JSON can only be used as a commit/file-list auxiliary artifact and must not be filled in as a usable patch;
    • Only patch/diff files that pass content validation can be written in 02_patch_fetch.md/json as "patch archived/ready for subsequent stages".