2014-12-04 88 views
13

在爲Git 2.2.0發行說明,它描述了一個新的選擇git push--signed爲什麼Git需要簽名推送?

"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 pages可以證實這一點:

--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. 

你看在man pages for git-receive-packpre-receivepost-recieve鉤,看看究竟如何驗證簽名的推動。

似乎所有這些都有助於服務器驗證誰在進行推送的確實是他們所說的他們。

git push --signed如何幫助您(推者)不必「信任」服務器?到目前爲止我所見過的一切似乎都表明它可以幫助服務器信任你。更重要的是,爲什麼簽名提交和簽名標籤不足以推送到不受信任的服務器?爲什麼我們甚至需要簽名推送?

回答

7

這裏是從commit message摘錄介紹了簽署推動:

While signed tags and commits assert that the objects thusly signed 
came from you, who signed these objects, there is not a good way to 
assert that you wanted to have a particular object at the tip of a 
particular branch. My signing v2.0.1 tag only means I want to call 
the version v2.0.1, and it does not mean I want to push it out to my 
'master' branch---it is likely that I only want it in 'maint', so 
the signature on the object alone is insufficient. 

The only assurance to you that 'maint' points at what I wanted to 
place there comes from your trust on the hosting site and my 
authentication with it, which cannot easily audited later. 

因此,即使提交簽字,你不能確保所提交的作者的意圖被推到分支master或分支super-experimental-feature。簽名推送允許服務器保存每個推送事件及其簽名的記錄。然後可以驗證這個日誌,看看每個提交的確是打算在一個特定的分支上。