【问题标题】:Does git client guarantee content integrity against a compromised git server?git 客户端是否保证内容完整性免受受损 git 服务器的影响?
【发布时间】:2017-06-14 04:39:40
【问题描述】:

假设用户下载了带有特定哈希的 git 存储库修订版。例如使用此命令:git clone --depth 1 --branch mybranch https://mygitserver.com/x.git && cd x && git checkout {hash}

让我们假设 git 服务器不可信,它可能会受到损害,以某种方式被黑客入侵。它可能试图以某种恶意方式更改内容。

客户端是否真的重新计算整个内容的哈希值并在哈希错误的情况下失败?

如果克隆很浅并且只有depth=1,这意味着历史丢失了。每个提交哈希实际上是否包含整个源哈希,还是仅包含增量哈希?似乎后者只是合理的,否则在历史悠久的情况下,它将不得不一遍又一遍地重新计算哈希。

我的怀疑是它只需要以前的哈希,向其中添加最新的提交增量和元数据,然后获取最新的哈希。最新提交未更改的代码部分呢?当客户端以这种方式下载它们时,它们是否会考虑到计算的最新哈希值?

【问题讨论】:

  • 如果有人破坏了服务器并对你的提交历史做了任何坏事并替换了完整的 git 历史,除非你从其他来源提取并相互比较,否则你永远不会发现。你得到一个历史并且你相信这个历史,如果它被完全替换了,你就无法弄清楚。
  • 一个小提示:“hashtag”是 Twitter 上的东西,“hash”是 Git 所做的。

标签: git


【解决方案1】:

据我所知,Git clonefetch 不会验证对象完整性(哈希不匹配)。这是根据Which git commands perform integrity checks? 提供的,但该信息可能已过时。

如果您想检查提交的 SHA-1 哈希是否正确,

git fsck

这会验证历史,但显然这不会验证你没有的对象,就像在浅层存储库中一样。

请注意,SHA-1 容易受到碰撞攻击,因此您无法在任何合理意义上的“保证”一词中使用 SHA-1“保证”对象完整性。

【讨论】:

  • 请注意,SHA-1 容易受到碰撞攻击,因此您无法在任何合理意义上的“保证”一词中使用 SHA-1“保证”对象完整性。 虽然这确实是真的,但从 2.13 开始,有一个 ad-hoc 分析应该识别已知的碰撞方式。
  • 有配置变量fetch.fsckObjectsreceive.fsckObjectstransfer.fsckObjects在对应操作时自动运行
猜你喜欢
  • 1970-01-01
  • 2015-03-08
  • 1970-01-01
  • 1970-01-01
  • 2013-02-02
  • 2017-03-04
  • 2021-10-03
  • 2017-11-13
  • 1970-01-01
相关资源
最近更新 更多