GitHub CLI 中 attestation verify 命令处理 JSONL 文件的新行问题解析

GitHub CLI 作为 GitHub 官方命令行工具，在 2.55.0 版本中出现了一个关于 attestation verify 命令处理 JSONL 格式文件的有趣问题。本文将深入分析这个问题的技术细节、产生原因以及解决方案。

问题背景

当用户使用 GitHub CLI 的 gh attestation verify --bundle 命令验证构建证明时，如果输入的 JSONL 文件末尾包含空行，验证过程会失败。具体表现为验证工具无法正确匹配哈希值，但实际上这些哈希值是存在的。

技术细节分析

JSONL（JSON Lines）是一种常见的日志和数据交换格式，每行都是一个有效的 JSON 对象。规范上，JSONL 文件可以包含或不包含末尾的换行符，两者都是合法的。

在 GitHub CLI 的实现中，attestation 验证模块处理 JSONL 文件时，会逐行读取并解析每行的 JSON 对象。问题出在当文件末尾有空行时，解析器会尝试将这个空行也作为 JSON 对象解析，导致解析失败。

问题复现

用户提供了详细的复现步骤：

1. 使用 GitHub Actions 的 attest-build-provenance 动作生成证明文件
2. 下载包含证明的 JSONL 文件
3. 直接使用该文件验证时失败
4. 删除文件末尾的换行符后验证成功

更复杂的是，当 JSONL 文件中包含多个证明时，验证器似乎只能正确处理第一个证明，而忽略后续的证明条目。

解决方案

GitHub CLI 团队通过以下方式解决了这个问题：

1. 在读取 JSONL 文件时，增加了对空行的过滤处理
2. 确保所有有效的 JSON 行都能被正确解析
3. 修复了多证明条目处理的问题

技术实现要点

在代码层面，主要修改了文件读取逻辑：

• 增加了行内容非空检查
• 优化了 JSON 解析错误处理
• 完善了多证明条目的收集和处理机制

最佳实践建议

对于使用 GitHub CLI 进行证明验证的用户，建议：

1. 升级到最新版本（2.56.0 及以上）
2. 无需再手动处理 JSONL 文件的格式问题
3. 可以放心使用 GitHub Actions 生成的原始证明文件

总结

这个问题的解决体现了 GitHub CLI 团队对用户体验的重视。通过正确处理 JSONL 文件的各种边界情况，使工具更加健壮和易用。对于开发者而言，这也提醒我们在处理类似行格式数据时，需要考虑各种可能的格式变体，确保程序的鲁棒性。