2017-09-20 102 views
3

在專業版Git中,標記您的版本:我們是否應該共享用於檢查簽入git存儲庫的公鑰?

它顯示了一種將公鑰集成到git中的方法,因此同步它的用戶可以添加該公鑰並驗證簽名標記。

這種方式實際上是否安全?有人可以改變公鑰並重新簽名。我認爲我們應該從一個單獨的授權方式獲得公鑰,對吧?

在這本書中的命令粘貼如下:

$ git tag -s v1.5 -m 'my signed 1.5 tag' 
You need a passphrase to unlock the secret key for 
user: "Scott Chacon <[email protected]>" 
1024-bit DSA key, ID F721C45A, created 2009-02-09 

$ gpg --list-keys 
/Users/schacon/.gnupg/pubring.gpg 
--------------------------------- 
pub   1024D/F721C45A 2009-02-09 [expires: 2010-02-09] 
uid                  Scott Chacon <[email protected]> 
sub   2048g/45D02282 2009-02-09 [expires: 2010-02-09] 

$ gpg -a --export F721C45A | git hash-object -w --stdin 
659ef797d181633c87ec71ac3f9ba29fe5775b92 

$ git tag -a maintainer-pgp-pub 659ef797d181633c87ec71ac3f9ba29fe5775b92 

$ git show maintainer-pgp-pub | gpg --import 
+0

你爲什麼會接受公關更改公鑰? – ceejayoz

+0

爲什麼你會接受惡意請求?這不是攻擊模式:而是想到攻擊者以某種方式獲取存儲庫憑證並能夠上傳惡意提交(包括新密鑰),而不發出請求。 –

+0

我認爲(也許我錯了)通過從分離和授權的方式獲得可信的公鑰來保證安全性,然後使用該密鑰來驗證簽名標籤,這也驗證標籤指向的提交以及承諾。因此無論我在哪裏獲取存儲庫,都會對其進行驗證。根據您的意見,如果安全由授權的git服務器保證,爲什麼我們需要首先簽署標籤? – TangXC

回答

3

沒有什麼錯在共享您的簽名密鑰,即使它當然不應該被視爲一個有效的關鍵,除非通過其他方式驗證。與完全不共享密鑰相比,對方將不得不通過簽名中包含的指紋參考從密鑰服務器獲取密鑰 - 密鑰仍然不可信,但是對密鑰服務器有依賴性。

一個例子,爲什麼包括密鑰可能顯示有用:許多(企業)公司對服務器系統有非常嚴格的防火牆規則。您可能能夠獲得存儲庫服務器的許可(或者默認情況下甚至可以獲得Github許可),但爲關鍵服務器添加參考可能很乏味。在構建軟件時,您可能很好地從存儲庫導入密鑰 - 並根據硬編碼的公鑰指紋發佈信任。儘管如此,這比靜態地在本地存儲密鑰更好,例如滾動子密鑰意味着破損的內部版本,除非本地密鑰副本被更新。當從存儲庫中獲取密鑰(並通過公共主鍵指紋驗證)時,不需要採取任何行動。

此外,還有TOFU的概念:「首次使用時的信任」。當你第一次獲取密鑰時(例如,在初始開發期間),你希望沒有攻擊者到位,但是要確保沒有操縱的源將在以後分發。開發人員在本地開發機器上獲取密鑰並將其設置爲可信,可能已經很好,這取決於您的攻擊模型和可接受的風險。

無論如何,也只是您提議的可靠來源上的關鍵字(或至少指紋,never use short key IDs)。通過具有可信證書的HTTP可用的網站是一個開始。特別是如果你進入開源項目,試着讓你的密鑰在開源會議上得到認證(或者至少有開發人員密鑰認證,然後才能證明項目密鑰)。

+0

謝謝你,感謝你的回答。但我仍然困惑於此。如果我們可以信任git倉庫中的公鑰,那麼我們可以信任倉庫中的標籤,對吧?那麼爲什麼我們需要首先簽署標籤? – TangXC

+0

那麼,這正是我所討論的:您可以提供密鑰,但仍需要通過其他方式進行驗證。例如,通過比較它的指紋(哈希碼)與網站,...;運用「豆腐」信託模式;通過使用信任網。一旦密鑰(或指紋)被驗證,你就沒事了。事實上,大多數OpenPGP生態圈依賴不可信的密鑰交換方法(OpenPGP密鑰服務器),但隨後應用驗證密鑰的方法。 –

相關問題