【问题标题】:Google Code changing host fingerprint causes hg pull to fail谷歌代码更改主机指纹导致 hg pull 失败
【发布时间】:2011-08-25 08:08:49
【问题描述】:

我正在为一个小项目javaclass-rb 使用 Google 代码和 Mercurial。我使用 HTTPS 克隆了存储库。我的.hg/hgrc 包含

[paths]
default = https://javaclass-rb.googlecode.com/hg/

有时,Google 代码会有不同的指纹(很可能是服务集群)。当我想拉(使用 hg 1.8.4)时,我得到了

E:\Develop\JavaClass>hg pull -u
abort: invalid certificate for javaclass-rb.googlecode.com with fingerprint 28:92:6b:9b:40:10:cc:0e:4c:16:a4:78:7f:bb:1a:8d:d4:d1:d3:27

然后我必须更改我的~/.hgrc 文件并更新hostfingerprints 部分以包含新指纹:

[hostfingerprints]
javaclass-rb.googlecode.com = 28:92:6b:9b:40:10:cc:0e:4c:16:a4:78:7f:bb:1a:8d:d4:d1:d3:27

然后一切正常,直到下一次。现在这很烦人,因为我已经做了十次了,大约。每月一次,并且必须在多台机器(台式机、笔记本电脑、工作电脑等)上进行...

34:4b:90:e7:e3:36:81:0d:52:1f:10:c0:4c:98:66:90:4a:9e:05:c9
6e:a8:09:6a:42:60:d7:81:f7:04:b8:0f:5d:1e:ac:b3:58:db:7e:da
89:6d:fb:e5:4a:7e:72:91:db:0b:ee:72:9f:60:a7:29:65:fd:e1:10
da:b3:df:aa:55:73:ac:65:04:70:78:8e:ed:dd:a9:be:40:a8:64:81
a9:be:c0:4a:da:1c:eb:4c:31:9d:78:27:48:99:f4:9c:9a:e8:53:c8
ed:19:7c:b9:a3:48:27:93:72:74:43:db:26:40:af:e0:7a:90:1c:97
28:92:6b:9b:40:10:cc:0e:4c:16:a4:78:7f:bb:1a:8d:d4:d1:d3:27

你知道一种方法来配置 Mercurial 以忽略指纹或我摆脱这种烦恼的其他方法吗?

回答

tonfa 带领我走上了正确的道路。 Mercurial 是checking also OS certificates。最初我不得不回退到指纹,因为 Googlecode 证书对子域无效:

The certificate is only valid for the following names:
  *.googlecode.com , *.u.googlecode.com , googlecode.com , *.codespot.com , *.googlesource.com , googlesource.com  

1) 我从.hgrc 中删除了指纹,然后顶级域javaclass-rb.googlecode.com 再次工作,因为它与*.googlecode.com 匹配。

2) 必须使用另一个名称克隆子域,请参阅Google support

【问题讨论】:

    标签: mercurial https repository google-code fingerprint


    【解决方案1】:

    忽略指纹而不验证签名是一个非常坏主意。

    您应该按照https://www.mercurial-scm.org/wiki/CACertificates 的说明进行操作(基本上应该已经正确配置了最新版本的 TortoiseHg)。

    【讨论】:

    • 啊,好吧 - 出于某种原因,我认为正常的证书验证不起作用,并且 OP 出于某种原因不得不使用指纹。
    • 是的,原来的问题是The certificate is only valid for the following names: *.googlecode.com , *.u.googlecode.com , googlecode.com , *.codespot.com , *.googlesource.com , googlesource.com,所以我又回到了指纹。但这些正在改变。
    【解决方案2】:

    试试命令hg pull --insecure

    【讨论】:

    • 这确实是一个非常糟糕的主意!
    • 自从我发布此答案以来,多年来了解中间人攻击后,我不得不同意你的看法。
    • 太棒了。请仍然将您的答案留在那里,以便其他人看到这是一种理论上的可能性,并进一步说明为什么这是一个坏主意;)
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-12-23
    • 1970-01-01
    • 2014-01-31
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多