我正在处理一个必须经常下载某些文件的应用程序。我认为签名文件是个好主意。
所以我想做的第一件事就是创建一个主证书，并以某种方式将其分发到程序中，并用此验证开发人员证书。因此，当新开发人员来时，我们不需要更新我们随程序分发的证书。
我认为apt-key正在使用类似的方法。我读到它与共享密钥环有关。
但我无法弄清楚如何用GnuPG做到这一点。你可以帮忙吗？
答案 0 :(得分：2)
您{GnuPG create a new OpenPGP key pair，其中包含公钥和私钥。您将私钥保密，但释放公钥（例如，将其上载到密钥服务器）。使用私钥执行签名。其他人（掌握公钥）现在可以验证签名是否真的由密钥发出。
要让其他人验证密钥是否真的由您发出，您应该
如果您使用软件分发发送密钥，请考虑使用其他GnuPG主目录而不是用户的目录（因此您不依赖于用户特定的配置和数据）。
我认为
apt-key正在使用类似的方法。我读到它与共享密钥环有关。
apt基础架构会创建一个内部密钥环，最初随您的发行版一起提供。它包含Debian的所有公钥（Ubuntu，...;您选择的任何基于Debian的发行版）开发人员，因此可以验证所有包。
但我无法弄清楚如何用GPG做到这一点。你可以帮忙吗？
所有这些提案都需要＆＃34;公司密钥＆＃34;要在验证软件的GnuPG密钥环中导入，并且发出最终信任以便能够验证该密钥。
如果您只需要一个将分发文件的开发人员（或构建计算机），只需选择单一密钥对并验证文件＆＃39;根据密钥的指纹签名。
另一种解决方案是为每个开发人员创建签名子密钥 并向每个开发人员发出一个签名子密钥（当然还有所有公共（子）密钥） 。验证仍然可以通过主键进行，但是如果他退出公司，您可以轻松撤销每个开发人员的子项。但是将个人开发人员连接到签名更加困难，因为必要时必须通过指纹手动完成。
更复杂的设置包括像Debian构建的系统，或者使用OpenPGP信任网来验证开发人员的密钥，但这需要更深入地了解不同类别的信任，如何认证工作。
因此，当新开发人员来时，我们不需要更新我们随程序分发的证书。
在所有情况下，您仍然需要更新它，但那不是那么糟糕。只需共享更新的密钥（考虑使用密钥服务器网络进行更新）。对密钥的更改将自动合并，即使有人试图向您发送伪造的密钥，它也将是另一个密钥，并且没有上述信任。
答案 1 :(得分：0)
apt使用GPG安全性，主私钥保密，但公共密钥是共享的。