openclaw-ghsa-maintainer

OpenClaw GHSA Maintainer

Verwenden Sie diese Fähigkeit ausschließlich für den Workflow mit Repository-Sicherheitsadvisories. Behalten Sie allgemeine Veröffentlichungsarbeit in release-openclaw-maintainer.

Sicherheitsleitplanken beachten

• Lesen Sie vor dem Überprüfen oder Veröffentlichen eines Repository-Advisory die SECURITY.md.
• Holen Sie vor jeder Veröffentlichungsaktion die Erlaubnis ein.
• Behandeln Sie diese Fähigkeit als GHSA-exklusiv. Verwenden Sie sie nicht für stabile oder Beta-Veröffentlichungen.

Advisory-Zustand abrufen und inspizieren

Rufen Sie das aktuelle Advisory und die neueste veröffentlichte npm-Version ab:

gh api /repos/openclaw/openclaw/security-advisories/<GHSA>
npm view openclaw version --userconfig "$(mktemp)"

Verwenden Sie die Ausgabe, um den Advisory-Zustand, den verknüpften privaten Fork und die Form der Schwachstellen-Payload vor dem Patchen zu bestätigen.

Überprüfen, dass private Fork-PRs geschlossen sind

Überprüfen Sie vor der Veröffentlichung, dass der private Fork des Advisories keine offenen PRs hat:

fork=$(gh api /repos/openclaw/openclaw/security-advisories/<GHSA> | jq -r .private_fork.full_name)
gh pr list -R "$fork" --state open

Die PR-Liste muss vor der Veröffentlichung leer sein.

Advisory-Markdown und JSON sicher vorbereiten

• Schreiben Sie Advisory-Markdown über einen Heredoc in eine temporäre Datei. Verwenden Sie keine escaped \n-Zeichenfolgen.
• Erstellen Sie die PATCH-Payload JSON mit jq, nicht mit hand-escaped Shell-JSON.

Beispielmuster:

cat > /tmp/ghsa.desc.md <<'EOF'
<markdown description>
EOF

jq -n --rawfile desc /tmp/ghsa.desc.md \
  '{summary,severity,description:$desc,vulnerabilities:[...]}' \
  > /tmp/ghsa.patch.json

PATCH-Aufrufe in der richtigen Reihenfolge anwenden

• Setzen Sie severity und cvss_vector_string nicht im selben PATCH-Aufruf.
• Verwenden Sie separate Aufrufe, wenn das Advisory beide Felder benötigt.
• Veröffentlichen Sie, indem Sie das Advisory PATCHen und "state":"published" setzen. Es gibt keinen separaten /publish-Endpunkt.

Beispielform:

gh api -X PATCH /repos/openclaw/openclaw/security-advisories/<GHSA> \
  --input /tmp/ghsa.patch.json

Veröffentlichen und Erfolg bestätigen

Nach der Veröffentlichung rufen Sie das Advisory erneut ab und bestätigen:

• state=published
• published_at ist gesetzt
• die Beschreibung enthält keine wörtlichen escaped \n

Bestätigungsmuster:

gh api /repos/openclaw/openclaw/security-advisories/<GHSA>
jq -r .description < /tmp/ghsa.refetch.json | rg '\\\\n'

Häufige GHSA-Fallstricke

• Die Veröffentlichung schlägt mit HTTP 422 fehl, wenn erforderliche Felder fehlen oder der private Fork noch offene PRs hat.
• Eine Payload, die in der Shell korrekt aussieht, kann trotzdem falsch sein, wenn Markdown mit escaped Newline-Zeichenfolgen zusammengesetzt wurde.
• Die Reihenfolge der Advisory-PATCH-Aufrufe ist wichtig; trennen Sie Feldaktualisierungen, wenn die GHSA-API-Einschränkungen dies erfordern.
• Öffentliche Härtungs-/Nicht-Veröffentlichungskommentare und Entwurfstext sollten rohe Commit-Hashes, PR-Titel/Nummern und Zusammenfassungen des Behebungsmechanismus vermeiden. Bevorzugen Sie gepatchte Versionsfelder oder veröffentlichungsbezogene Formulierungen; bewahren Sie SHAs, PRs und Implementierungshinweise in internen Beweisen auf.