在发行说明的Git 2.2.0,它描述了一个新的选择git push
,--signed
:
"git push" learned "--signed" push, that allows a push (i.e. request to update the refs on the other side to point at a new history, together with the transmission of necessary objects) to be signed, so that it can be verified and audited, using the GPG signature of the person who pushed, that the tips of branches at a public repository really point the commits the pusher wanted to, without having to "trust" the server.
因此,这听起来像是在推送期间发送到服务器的数据被签名,以便服务器可以验证并记录谁进行了推送.在man
页面中,您可以确认:
--signed GPG-sign the push request to update refs on the receiving side, to allow it to be checked by the hooks and/or be logged. See git-receive-pack[1] for the details on the receiving end.
您查看under 和hooks 的man
页面,git-receive-pack
以确切了解如何验证签名推送.pre-receive
post-recieve
似乎所有这些都有助于服务器验证谁正在进行推送真正是他们所说的人.
如何git push --signed
帮助您(推动者)不必"信任"服务器? 到目前为止,我所看到的一切似乎表明它有助于服务器信任您.更重要的是,为什么签名提交和签名标签不足以推送到不受信任的服务器?为什么我们甚至需要签名推送?
以下是引入签名推送的提交消息的摘录:
虽然签名标签和提交断言所签署的对象来自您,谁签署了这些对象,但没有一种好方法可以断言您希望特定对象位于特定分支的顶端.我的签名V2.0.1标签仅仅意味着我要拨打的版本V2.0.1,这并不意味着我想要把它给我的"主人"分支---很可能,我只希望它在"MAINT" ,因此仅对象上的签名是不够的.
唯一向您保证"maint"指向我想放置的内容来自您对托管站点的信任以及我对其的身份验证,以后无法轻松审核.
因此,即使提交已签名,您也无法确定作者是否希望将提交推送到分支master
或分支super-experimental-feature
.签名推送允许服务器记录每个推送事件及其签名.然后可以验证此日志以查看每个提交确实打算在特定分支上.