@
hamsterbase #11
Git 和签名有完全不同的场景，因为 Git commit 通常是 non-adversarially constructed （非别有用心构造的），所以用一个过时的散列函数危害没有那么大。如果用户对自己的 Git 仓库构造 SHA-1 碰撞，受害者是用户自己，而不是别人。请注意 Git commit 签名和 commit hash 是两码事儿，它的 commit 签名的作用对象是 commit object 被 sign 之前的内容，而不是 commit hash ，而 commit object 本身的信息是当前内容快照加上一些 commit 信息（比如消息、时间、committer ），因此可攻击的面仅限于内容快照。
当然，我的观点是 Git commit 签名意义不大，考虑用户 A 签名 commits 后又继续被别人开发，然后用户 A 的私钥泄露，那么对于新来的人，没有办法确认过去被 A 签名的 commits 到底是泄露之前签名的，还是泄露之后伪造的——除非重新签名并改写过去所有的 Git 历史。其意义不大的根本原因在于我期待软件开发历史隽永，但是签名的安全性并不隽永。
@
drymonfidelia #14
考虑我定义的签名算法 Sign(sk, msg) = 123 并且给所有程序都加入这个签名。显然该算法不安全，请问它是否有伪造的风险？
答：有“被伪造的风险”，但是此问题无意义，因为没有任何人会认为被这个不安全算法签名的程序是“有背书的”，即没有“错误认为有安全签名的风险”。
习题：过期的证书不被信任，一个证书的证书链只能追踪到过期的根证书，那么被这个证书签名的程序，是否有伪造签名的风险？
没有验证程序支持的签名，不过是一堆无甚意义的数字。
