openclaw-ghsa-maintainer

OpenClaw GHSA Maintainer

Use esta skill exclusivamente para o fluxo de trabalho de avisos de segurança de repositório. Mantenha o trabalho geral de versão em release-openclaw-maintainer.

Respeite as diretrizes de avisos

• Antes de revisar ou publicar um aviso de repositório, leia SECURITY.md.
• Peça permissão antes de qualquer ação de publicação.
• Trate esta skill como exclusiva para GHSA. Não a use para trabalho de versão estável ou beta.

Busque e inspecione o estado do aviso

Busque o aviso atual e a versão npm publicada mais recente:

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

Use a saída da busca para confirmar o estado do aviso, o fork privado vinculado e a forma do payload de vulnerabilidade antes de corrigir.

Verifique se os PRs do fork privado estão fechados

Antes de publicar, verifique se o fork privado do aviso não tem PRs abertos:

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

A lista de PRs deve estar vazia antes da publicação.

Prepare o Markdown e JSON do aviso com segurança

• Escreva o Markdown do aviso via heredoc para um arquivo temporário. Não use strings \n escapadas.
• Construa o payload JSON de PATCH com jq, não com JSON escapado manualmente no shell.

Exemplo de padrão:

cat > /tmp/ghsa.desc.md <<'EOF'
<descrição markdown>
EOF

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

Aplique as chamadas PATCH na sequência correta

• Não defina severity e cvss_vector_string na mesma chamada PATCH.
• Use chamadas separadas quando o aviso exigir ambos os campos.
• Publique fazendo PATCH no aviso e definindo "state":"published". Não existe um endpoint /publish separado.

Exemplo de formato:

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

Publique e verifique o sucesso

Após a publicação, busque novamente o aviso e confirme:

• state=published
• published_at está definido
• a descrição não contém \n literais escapados

Padrão de verificação:

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

Armadilhas comuns do GHSA

• A publicação falha com HTTP 422 se campos obrigatórios estiverem ausentes ou se o fork privado ainda tiver PRs abertos.
• Um payload que parece correto no shell pode ainda estar errado se o Markdown foi montado com strings de nova linha escapadas.
• A sequência de PATCH do aviso é importante; atualizações de campo separadas quando as restrições da API GHSA exigirem.
• Comentários públicos de hardening/sem publicação e texto de rascunho devem evitar hashes de commit brutos, títulos/números de PR e resumos de mecanismo de correção. Prefira campos de versão corrigida ou redação exclusiva de versão; mantenha SHAs, PRs e notas de implementação em evidência interna.