在 Pro Git, Tagging Your Releases 一书中:
它展示了一种在 git 中将公钥收集到 blob 中的方法，以便同步它的用户可以添加该公钥并验证签名标签。
这种方式真的安全吗？有人可以更改公钥 blob 并重新签名。我认为我们应该从单独的授权方式获取公钥，对吗？
书中的命令粘贴如下:
$ git tag -s v1.5 -m 'my signed 1.5 tag'
You need a passphrase to unlock the secret key for
user: "Scott Chacon <schacon@gmail.com>"
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 <schacon@gmail.com>
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
最佳答案
共享您的签名 key 并没有错，尽管它当然不应被视为经过验证的 key ，除非通过其他方式进行验证。与根本不共享 key 相比，另一方必须通过签名中包含的指纹引用从 key 服务器获取它们—— key 仍然不可信，但对 key 服务器有依赖性。
举个例子，为什么包含 key 可能会很有用:许多(企业)公司对服务器系统有非常严格的防火墙规则。您可能能够获得存储库服务器的许可(或者甚至在默认情况下获得 Github 许可)，但为关键服务器添加引用可能会很乏味。在构建软件时，您可能会从存储库中导入 key ——并根据硬编码的公钥指纹发出信任。尽管如此，这还是比在本地静态存储 key 要好，例如，除非更新本地 key 副本，否则滚动子 key 意味着构建损坏。当从存储库中获取 key (并通过公共(public)主 key 指纹进行验证)时，无需采取任何操作。
此外，还有 bean 腐的概念:“第一次使用的信任”。当您第一次获取 key 时(例如，在初始开发期间)，您希望没有攻击者就位，但要确保以后不会分发受操纵的源。开发人员在他的本地开发机器上获取 key 并将其设置为受信任可能已经没问题了，这取决于您的攻击模型和可接受的风险。
无论如何，正如您所建议的那样，也不过是可信来源上的 key (或至少是指纹， never use short key IDs )。一个可通过 HTTPs 使用受信任证书的网站是一个开始。特别是如果您参与开源项目，请尝试在开源 session 上获得您的 key 认证(或至少让开发人员 key 获得认证，然后才能认证项目 key )。
关于git - 我们应该共享公钥以检查 git 存储库中的签名吗？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/46318599/