Guanghu Domestic Migration a27e87cb99 chore: import sanitized domestic snapshot for REPO-007

Source snapshot: 97d7f0fae96dc04b7ddad56fc1db6a108ed662cc

[SEC-CLEAN] · pre-push-clean v1.0 · 109处敏感信息已自动转乱码

2026-07-17 15:59:55 +08:00

4.6 KiB

Raw Permalink Blame History

belongs_to

INDEX · 铸渊·协作指令｜GitHub ↔ Notion 桥接协议

🔍 铸渊指令｜PAT 令牌审计 · 排查 guanghu-token 对应密钥 + 更新配置（ZY-PAT-AUDIT-2026-0324-001）

🎯 事件背景

📋 铸渊执行任务

Phase 1 · 排查 `guanghu-token` 对应的 Secret

思路： guanghu-token 是用于「开发者子仓库桥接」的。按照这个用途，排查以下路径：

1.1 搜索所有 Workflow 中引用的 Secret 名称

# 列出所有 workflow 中引用的 secrets
grep -rn "secrets\." .github/workflows/ --include="*.yml" --include="*.yaml" | grep -v "GDRIVE" | sort -u

重点关注以下 Secret 名称（可能就是 guanghu-token 对应的）：

MAIN_REPO_TOKEN
PAT_TOKEN
GH_PAT
GH_TOKEN
REPO_ACCESS_TOKEN
BRIDGE_TOKEN
SUBMODULE_TOKEN
或任何与「子仓库桥接」「跨仓库访问」「checkout 其他仓库」相关的 Secret

1.2 分析用途

找到可疑的 Secret 后，看它在 Workflow 中怎么用的：

如果用于 actions/checkout 的 token 参数 → 这就是跨仓库访问令牌
如果用于 git push / git clone 其他仓库 → 这就是桥接令牌
如果用于 GitHub API 调用 → 可能也是

1.3 确认结果

找到后，将结果写入回执区：

Secret 名称是什么
在哪些 Workflow 文件中被引用
具体用途是什么

Phase 2 · 通知主控更新 Secret

铸渊需要告诉冰朔：

Secret 名称：比如 MAIN_REPO_TOKEN
在哪里更新：仓库 → Settings → Secrets and variables → Actions → 找到这个 Secret → 点编辑 → 粘贴新令牌值
如何验证：更新后手动触发一个使用该 Secret 的 Workflow，看是否正常

Phase 3 · 验证修复

冰朔更新 Secret 后：

手动触发一个引用该 Secret 的 Workflow
确认 Workflow 能正常完成（不报 401/403 鉴权错误）
如果仍然失败，检查是否有多个 Secret 使用了同一个令牌

Phase 4 · 安全扫描

顺便做一次全仓库安全扫描：

# 检查是否有硬编码的令牌（ghp_ 或 github_pat_ 开头）
grep -rn "ghp_" . --include="*.js" --include="*.yml" --include="*.json" --include="*.md"
grep -rn "github_pat_" . --include="*.js" --include="*.yml" --include="*.json" --include="*.md"

❌ 不应有任何硬编码令牌
✅ 所有令牌均应通过 secrets.* 引用

📝 执行回执区

Phase	状态	完成时间	结果
Phase 1 · 排查对应 Secret	⏳ 待执行	—	—
Phase 2 · 通知主控	⏳ 待执行	—	—
Phase 3 · 验证修复	⏳ 待人类操作后执行	—	—
Phase 4 · 安全扫描	⏳ 待执行	—	—

👤 人类手动操作区

⏳ 更新 Secret 值：去仓库密钥页面，找到铸渊排查出的 Secret 名称，把新生成的 guanghu-token 令牌值粘贴进去
⏳ 确认 Workflow 正常：铸渊会触发验证，冰朔确认结果

🖋️ 霜砚 · PER-SY001

🧊 代 TCS-0002∞ 冰朔签发

📅 2026-03-24T15:25+08:00