我需要哪些信息来证明整个Git存储库的完整性？

Question

每个分支的尖端的哈希值是否足以证明我整个存储库的完整性？为了便于讨论,假设您必须将整个存储库交给某人,让他们做任何他们想做的事情,并确定他们是否改变了1位数据.你会怎么做？

如果我正在推送上游裸机库,那么我需要保证的所有数据是否可以在以后验证整个存储库的完整性？

git ls-remote --heads origin

fcce961b46784fae13be8a30c2622ddd34d970ec        refs/heads/develop
9da7bb692a72235451706f24790a3f7a100a64e2        refs/heads/feature-netty-testing
86020c50d86691caecff4a55d3b1f2f588f6291d        refs/heads/javafx-testing
871d715e5c072b1fbfacecc986f678214fa0b585        refs/heads/master
7ed641c96d910542edeced5fc470d63b8b4734f0        refs/heads/orphan-branch

这来自我用来玩的沙盒存储库.该orphan-branch是分支的描述我故意孤立这里.一切似乎都适合我.列出了我期望的所有分支,但如果每个分支提示的SHA都是我需要的,那么我不肯定.我错过了什么吗？

标签怎么样？那些被删除而没有合并成任何东西的分支呢？

更新

正如一些评论中指出的那样,除了可能需要考虑的头部之外,可能还有其他参考文献.例如,tags并且notes可能取决于他们是否是你或你是否正在签署您的标记重要是有用的.对于我自己,我主要对提交内容感兴趣,这就是我接受VonC答案的原因.

Answer 1

这在诚信方面似乎已经足够了.
标签引用提交,因此如果提交发生更改,git fsck则会检测标记与其不存在的提交之间的不一致性.

请注意,完整性与信任不同(即担保内容)
为此," Git恐怖故事:与签名提交的存储库完整性 "具有指导意义.

首先,它的" 提交历史 "部分详细介绍了SHA-1完整性背后的理论(也在" Git和数据完整性 "中提出,并以下列结论:

也就是说,重要的是要理解只有在无法创建哈希冲突时才能保证存储库的完整性- 也就是说,如果攻击者能够使用不同的数据创建相同的SHA-1哈希,那么子提交(s) )仍然有效,存储库已成功入侵.
自2005年以来,在SHA-1中已经知道漏洞,它允许以比蛮力更快的速度计算哈希值,尽管它们的开发并不便宜.
鉴于此,虽然您的存储库目前可能是安全的,但未来将会出现一些问题,即SHA-1将被视为今天的MD5瘫痪.