加载失败
GitHub Actions（GitHub 提供的 CI/CD 平台）会在工作流日志里自动隐藏已注册的 secret，但它通常依赖对原始字符串的精确匹配。这里的问题出在 Composer（PHP 依赖管理器）抛出异常时，Symfony Console（PHP 命令行输出库）会把错误渲染成带样式的块，甚至插入换行和 ANSI control sequences，从而把 token 拆散。GitHub 的 secret masking 一旦无法识别完整值，GITHUB_TOKEN 就可能以明文进入日志。讨论还强调，这主要影响在 GitHub Actions 中运行 Composer 的 PHP 项目，尤其是使用 shivammathur/setup-php 或 php-actions/composer 这类 action 的工作流。
这里被指出的问题不是普通的日志截图，而是 Composer 在 GitHub Actions 中抛异常时把 secret 带进了日志。GitHub 的 secret masking 依赖对原始值做精确子串匹配，但 Symfony Console 的错误渲染会用换行、样式块和 ANSI control sequences 把 token 拆开，导致脱敏失效。这样一来，原本应被隐藏的 GITHUB_TOKEN 可能以明文出现在 workflow log 里。有人还追问这对 private repos 或特定 OAUTH token 的影响，回复则把范围收窄到在 GitHub Actions 中使用 Composer 的 PHP 项目。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
有评论直接纠正标题，认为真正的问题仓库是 composer/composer，而不是 GitHub Actions 本身。新的 GITHUB_TOKEN 格式与 Composer 的异常输出方式、以及 GitHub 的脱敏规则叠加后才出现泄露，因此这更像是 Composer 侧的兼容性问题。虽然这不等于 GHA 整体有 bug，但对在 GitHub 上跑 Composer 的用户来说仍然是必须警惕的安全风险。也有人因此稍微降低了恐慌程度，但没有否认事件本身的严重性。
另一组评论借机吐槽 GitHub Actions 对严肃 DevOps 不够友好，认为它更像是为几行 YAML 的快速集成而设计的。评论者的现实建议是把真正的任务逻辑放进 shell script wrappers，让 workflow 只负责调用脚本。这样不仅更容易在本地复现 CI，也更方便未来迁移到其他平台。对这类人来说，这次泄露只是又一个说明工作流抽象层太脆弱的例子。
GITHUB_TOKEN: GitHub Actions 自动注入的仓库访问令牌，若脱敏失败可能直接出现在日志中。
secret masking: GitHub Actions 的日志脱敏机制，通常按精确字符串匹配来隐藏 secret。
Symfony Console: PHP 的命令行输出组件，格式化异常信息时可能插入样式、换行和控制码。
Composer: PHP 的依赖管理器，用于安装和管理项目依赖包。
ANSI control sequences: 终端格式控制码，会影响文本的连续性，干扰字符串匹配和脱敏。