docs: harden GHSA wording guidance

This commit is contained in:
Peter Steinberger
2026-05-28 16:15:26 +01:00
parent ad1d8bf990
commit b601550c97
2 changed files with 11 additions and 3 deletions
@@ -1,6 +1,6 @@
---
name: openclaw-ghsa-maintainer
description: Inspect, patch, validate, publish, or confirm OpenClaw GHSA security advisories and private-fork state.
description: "Inspect, patch, validate, publish, or confirm OpenClaw GHSA security advisories and private-fork state."
---
# OpenClaw GHSA Maintainer
@@ -85,3 +85,4 @@ jq -r .description < /tmp/ghsa.refetch.json | rg '\\\\n'
- Publishing fails with HTTP 422 if required fields are missing or the private fork still has open PRs.
- A payload that looks correct in shell can still be wrong if Markdown was assembled with escaped newline strings.
- Advisory PATCH sequencing matters; separate field updates when GHSA API constraints require it.
- Public hardening/no-publish comments and draft text should avoid raw commit hashes. Prefer release versions, PRs, patched-version fields, or "the fix on main"; keep full SHAs in internal evidence unless publishing a real CVE/GHSA needs them.
+9 -2
View File
@@ -1,6 +1,6 @@
---
name: security-triage
description: Triage OpenClaw security advisories, drafts, and GHSA reports with shipped-tag and trust-model proof.
description: "Triage OpenClaw security advisories, drafts, and GHSA reports with shipped-tag and trust-model proof."
---
# Security Triage
@@ -87,11 +87,18 @@ When preparing a maintainer-ready close reply:
- exact reason for close
- exact code refs
- exact shipped tag / release facts
- exact fix commit or canonical duplicate GHSA when applicable
- fix provenance or canonical duplicate GHSA when applicable
- optional hardening note only if worthwhile and functionality-preserving
Keep tone firm, specific, non-defensive.
## Public Wording Hygiene
- Keep raw commit hashes out of hardening/no-publish close comments and public advisory text. Use the shipped version, planned patched version, PR, or "the fix on main" instead.
- Keep exact commit SHAs in internal notes and verification files. Include raw SHAs in a public advisory only when publishing a real vulnerability and the SHA materially helps downstream tracking.
- For hardening/no-publish outcomes, do not add exploit-heavy details or a "Fix Commit(s)" section. Thank reporters, preserve credit, state the `SECURITY.md` boundary, and say clearly that the GHSA will close without publication.
- Keep GHSA ids out of changelog and release-note wording unless Peter explicitly asks.
## Discussion Mode
When Peter is manually posting GHSA comments, use this flow: