问题一： SF 毕竟冷清，提了好几个问题无人解答，愿意在 SF 上解答的移步 git-scm 上提供的 gpg 公钥分发方式似乎不可以防止内容伪造吧？
重复下问题，使用 git-scm 上 https:/git-scm.com/book/zh/v2/分布式-Git-维护项目#为发布打标签 设计的公钥分发方式，遇到伪造者用他的私钥加密，用 tag annotate 发布假公钥，再伪造内容，根本无解啊？
你说用指纹？指纹发布在 site 上吗，那我何不在 site 上直接写公钥？
问题二： ssh 的私钥明文存储在 ~/.ssh/ 下，要 private key 的 passphrase 又有何用？
发现链接有两段中文被hash分开且未encode的不能跳转，想跳转的可以浏览器复制" https:/git-scm.com/book/zh/v2/分布式-Git-维护项目#为发布打标签 "，或者使用这个encode过的，https://git-scm.com/book/zh/v2/%E5%88%86%E5%B8%83%E5%BC%8F-Git-%E7%BB%B4%E6%8A%A4%E9%A1%B9%E7%9B%AE#为发布打标签
 |
1
BOYPT Apr 20, 2016
1 没看懂
2 加密了的 key 不是明文。 |
 |
2
AstroProfundis Apr 20, 2016
1. 实现你说的那种情况，前提是网页或其他某个地方公布的公钥、和签名提交用的公钥，都被攻击者替换成自己的，概率比单点爆破低很多；当然不能说不存在
2. passphrase 是在有人拿到了你的私钥文件的情况下提供的最后一层遮羞布 |
 |
3
sunjourney OP @BOYPT 第二个问题取消，我弄错了， private key 是加密的，我之前以为是未加密的，第一个问题是 git-scm 提供的一个分发设计，原理是把 pubkey 放到一个有 annotate 的 git tag 下，传到 remote 上， 使用者只要 git show 一下这个 tag 的 annotate ，就知道 gpg pubkey 了，实现分发
|
|
4
AstroProfundis Apr 20, 2016
@AstroProfundis 又看了一遍，我也不确定我是不是看懂了你第一个问题... “只能靠发布公钥指纹在站点上可以防止这点” 网站也可以被黑啊，按这种极端推论的话...
另外，理论上只要公钥发布出来的第一时间是发布者本人的那一个，然后别人存下了这个公钥，后面发现签名的公钥变成了另一个而发布者本人没有公布过“以上一个公钥签名的表示更换为下一个公钥的申明”，就可以认为有问题了 至于怎么保证第一个公钥确实是发布者本人持有， WoT 就是专门解决这个问题的 |
|
5
sunjourney OP @AstroProfundis 你的意思是：使用者要保证安全，还是要在 site 上看公钥，再看 tag 里的公钥，两个一致的情况下还是伪造的可能性只有 site 被 hack ， git 被恶意提交了，发生这样事情的概率要很低？
可如果 签名没有被 fake ，发布者在 site 上伪造 pubkey 的意义一点都没有。 git-scm 上的问题在于，公钥和内容都用 git pull 下来，没有分开。 |
 |
6
shiji Apr 20, 2016
1. 这个跟 git 没关系，是 GPG 的事，你可以看这个：
http://security.stackexchange.com/questions/62791/pgp-gpg-verifying-authenticity 更多可以参看这里： https://www.gnupg.org/gph/en/manual.html#AEN385 即便是一般的安全证书，在没有预置 CA 的情况下，并且在和对方没有见过面（交换公钥）的情况下，你永远都不能得知和你通信的那个人究竟是不是真的。 gpg 靠的也是信任网。 2. 那个密码能加密你的私钥，这样即使你这个文件被坏人通过各种手段偷走了（按理来说不应该被轻易偷走，这密码是最后一道防线了），你也能有三五天的时间更换密钥对。（比如用于登录 ssh 的 authorized keys ， git 的公钥等等） 前提是你的密码够复杂。 有的时候，比如在 osx ，系统在 keychain 里面帮你记住这个私钥密码，所以会造成这个密码没用的错觉。 |
|
7
sunjourney OP @shiji @AstroProfundis 我提出的问题是 git-scm 设计的分发方式没有解决公钥分发方式，过度设计，还是得依靠 CA 、网站等。伪造者如果只能伪造内容，或是 hack 网站，只能实现其一，内容都是安全的。但 hacker 在 hack 到了你的机器，提交了假的内容并用他的的 gpg 签名，同时用 git-scm 的方式发布他的公钥，其它人 pull 下来的就是伪造的了。
1 ，如果网站有公钥且网站没有被 hack ，其它人可以比对破之，但既然要比对，那我为何不就信任网站的公钥呢？见 2 。 2 ，在 1 的前提下，网站既然可以发布公钥，使用者就没必要用 git-scm 的方法获取公钥了，因为网站公钥必然是有效的（网站与机器分离，网站就算被 hack ，假公钥也不能通过验证），只看网站即可。 第二问题是我搞错了，已明白理解，感谢！ |
|
8
AstroProfundis Apr 20, 2016  1
@sunjourney 论 GPG 公钥签名的重要性
如果我攻破某个仓库，在里面放了我伪造的公钥，但我却没办法伪造发布者真正公钥上的各种交叉签名 可以粗暴（并且不严谨）地解释为：没有和他人交叉签名的 GPG 公钥，其可信度和自签名的 SSL 证书一样，随缘 |
|
9
sunjourney OP @AstroProfundis pro git 提供这样自验证的方案，一点也不 pro 。
|
|
10
sunjourney OP @AstroProfundis 嗯，觉得是个烂设计，已经在 pro git 的 repo 上发 issue 去 讨论了，看看有没有什么玄机是我没看出来的。 pro git 这么不 pro ，有点怀疑自己也怀疑作者了
|
|
11
AstroProfundis Apr 20, 2016 1
@sunjourney 要我说的话，这个只是解决公钥分发方便的问题，安全性校验是交给 PGP/GPG 本身了，于是真正管用的唯一手段是保证自己的公钥在 WoT 网络中并有足够的交叉签名以显得可靠（伪造难度较高，但通过一些社工手段显然还是可以伪造）
|
Select Language