我注意到，從安裝軟體包時apt，有時我們會執行以下操作：
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
如果我理解正確的話，我們在這裡所做的就是從 中獲取 GPG 公鑰https://download.../gpg，並將其放入 中/usr/share/keyrings/docker-archive-keyring.gpg。然後，我們告訴 apt - 「當您下載軟體包時，請https://download.docker.com/...驗證這些軟體包是否由屬於該公鑰的私鑰簽署」。
所以我不太明白：如果我們相信它是另一邊的 Docker https://download.docker.com/.. - 而且我們這樣做，因為這是我們獲取公鑰的地方 - 那麼為什麼我們需要使用 gpg 金鑰驗證來自那裡的套件？
對我來說聽起來像是自簽名憑證。
我在這裡錯過了什麼嗎？
答案1
這是有多種原因的，它們都圍繞著中間人攻擊(MITM) - 具體來說，保護您在將來免受 MITM 攻擊或某種其他類型的惡意重定向到「虛假下載來源」的情況的影響後你已經拿到好鑰匙了。
如果您處於最壞的情況 - 您的系統已經受到損害並被重定向到惡意行為者（簡稱“MA”）的不良網站 - 那麼您就會被淹沒，但這並不能保護您，因為您'將下載MA 的金鑰。這不是 PGP 金鑰和金鑰環保護的重點，而是保護您免受未來MITM 攻擊。
在此範例中，您已經受到威脅，並且使用什麼金鑰無關緊要，因為 MA 此時可能已經控制了您的電腦、網路、資料等。然而，最常見的保護場景是您開始擁有乾淨的環境/系統和然後從合法來源安裝軟體。 （參見下一節）
然而，從受損的環境開始並不是關鍵簽名所防範的「常見情況」。最常見的情況是：您使用的是乾淨的系統，進行了乾淨的更新，您的系統、您使用的 DNS 伺服器、您連接的網路等都沒有受到損害。
你去安裝Docker並從真實的Docker網站取得Docker金鑰。然後安裝 Docker，金鑰就會生效。
在未來的某個時刻，MA 會控制您的流量流向網路的方式，並將您重定向到「假」Docker 下載網站。
除非 MA 從 Docker 竊取了 PGP 金鑰及其對應的私鑰，否則您的apt系統將顯示download.docker.com 不匹配並且在您的環境中發生了一些奇怪的事情，並且不會套用來自 MA 的「錯誤」儲存庫重定向的更新。
這是金鑰簽名和關鍵部分所防止的：您在未來。如果您已經受到威脅，它就無法保護您，沒有什麼可以保護您。當您開始乾淨且不妥協時，它會保護您，然後變得由於某種原因而妥協。
這也是為什麼您應該根據已知的良好密鑰指紋來驗證密鑰指紋。大多數優秀的儲存庫提供者都可以隨時手動驗證其指紋，這樣您就不再依賴命令來取得和信任金鑰。