supply-chain-tools/gitverify

# gitverify **这仍然是一个原型，需要清理/更好的测试。** ## 演示：验证此仓库 *在实际使用中，必须先建立对配置文件的信任，然后才能将其用于验证。* ``` curl https://raw.githubusercontent.com/supply-chain-tools/root-of-trust/refs/heads/main/gitverify.json --output gitverify.json ``` 验证 ``` gitverify --config-file gitverify.json --repository-uri git+https://github.com/supply-chain-tools/gitverify.git validating... OK ``` 对于 `github.com` 仓库，还可以将配置放置在 ``` ~/.config/gitverify/github.com/supply-chain-tools/gitverify.json # 即 ~/config/gitverify///gitverify.json ``` 并运行 ``` gitverify ``` 这将使用 git config 中的第一个 upstream URL 来推断 forge、组织和仓库名称。 推断配置时的默认操作也是存储本地状态（在 [threat-model.md](docs/threat-model.md) 中有描述）。它将被放置在 ``` ~/.config/gitverify/github.com/supply-chain-tools/gitverify/local.json # 即 ~/config/gitverify////local.json ``` ## 迁移指南 请参阅 [migrate.md](docs/migrate.md)。 ## 配置文件 请参阅 [config.md](docs/config.md)。 ## 命令行 ### 验证特定的 commit、tag 和/或 branch 验证 `commit`、`tag` 和/或 `branch` 是否遵循规则并由 `HEAD` 指向： ``` gitverify --commit 1f46f2053221c040ce5bcba0239bc09214a37658 --tag v0.0.1 --branch main ``` 使用此命令时，必须提供 `--commit`，并且同时提供 `--tag` 或 `--branch`。 - `--tag` 验证 tag 以及它是否指向 `commit`。 - `--branch` 验证 `commit` 是否位于 `branch` 上。如果 `branch` 是一个 `protectedBranch`，那么还将验证这些规则。 - 可以添加 `--verify-at-tip` 来验证 `commit` 是否位于 `branch` 的顶端。 - 使用 `--verify-on-head=false` 可以仅验证相关状态，而不验证 `HEAD` 是否指向它。 这仅会验证仓库中相关数据的子集。即，即使存在其他无法通过验证的 `commits`、`tags` 和 `branches`，此检查也可能成功。 ## 威胁模型 请参阅 [threat-model.md](docs/threat-model.md)。 ## 常见问题 / 故障排除 ### 性能问题 我们的目标是使其对于像 Linux 内核这样的大型仓库也能发挥作用，但目前它仅应用于较小的仓库。 ### 浅克隆仓库 目前不支持浅克隆仓库。验证递归验证 `SHA-1` 和 `SHA-512` 哈希值需要所有的仓库状态。 ### 最多两个父 commit 不支持超过两个父 commit。 ### 迁移时：设置了 `after` 但验证失败 您可能有额外的 commits 需要清理或添加到 `after` 列表中。要获取未被其他 commits 指向的所有 commits 的列表，请运行 ``` gitverify after-candidates ``` 将此列表添加到 `after` 中，或者删除 tags/branches 并在仓库中运行垃圾回收。 ### 迁移时：设置了 `requireSignedTags: false` 但 tag 验证失败 `gitverify` 被设计为严格的，即使没有签名，它仍然会验证 annotated tags 的完整性。 要获取现有 tags 的列表，请运行 ``` gitverify exempt-tags ``` 可以将它们作为 `exemptTags` 添加到配置中。 ### 从仓库中不正确的状态恢复 主要的恢复方法是手动验证状态是否安全，并更新 `after` 以忽略错误的 commits。对于 tags，可以将其删除或添加到 `exemptTags` 中。 如果 commits 或 tags 被删除，并且使用了 `local state`，则可能需要对其进行修补或重新创建。目前没有任何用于此操作的便捷工具。 ### Git stash 问题 **注意：这会删除状态，请谨慎使用！** Git stash 会创建未签名的本地 commits，并且无法通过检查。 可以按如下方式删除 stashes（**注意！只有在您愿意丢失 stashes 中的数据时才运行此命令**） ``` git stash clear # Remove all stashes ``` 移除悬空的 commits ``` git gc --prune=now ``` ### 移除本地未签名/错误的 commits **注意：这会删除状态，请谨慎使用！** 如果不小心引入了不应该存在的 commits（即未签名或使用了错误的密钥签名），且尚未被 push，则可以将它们移除。 确保不再有任何 branch 指向该 commit，例如使用 `reset --hard` 或 `push --force` 使所有悬空的对象过期 ``` git reflog expire --expire-unreachable=now --all ``` 运行 gc ``` git gc --prune=now ``` ### Tags 未指向 commits 目前不支持。

标签：EVTX分析, Git签名验证, 文档结构分析, 网络安全研究