GPGME使用passphrase_cb方法从用户那里获取密码以进行操作，这些操作需要访问私钥。仅对于对称加密，可以覆盖此回调，在所有其他情况下，将使用默认的pinentry。
所有这些工作似乎非常不舒服，尤其是因为GPGME是一种API，将用于对C / C++ / ...应用程序进行编程。如果密码短语可以直接传递给加密/签名函数，则在某些情况下(对于想使用GPGME的程序员而言)可能会更容易。我还看到OpenPGP的其他实现(更准确地说是NetPGP)使用回调。
因此，我想知道是否有任何特定的安全原因？
最佳答案
从2.1开始的GnuPG将最关键的私钥功能删除到gpg-agent中，以减少针对最私密 secret 的攻击面-私钥。
这样的回调不仅会将密码短语公开给您正在编写的应用程序(这可能意味着攻击面比GnuPG还要大)，而且GnuPG也会知道该密码短语。
如果确实需要从应用程序控制密码短语的输入，则有多种选择。
实现Pinentry
信息流将是:您的应用程序通过GPGME调用GnuPG，GnuPG从gpg-agent请求一些私钥操作，这再次要求您的应用程序提供密码短语。请注意，这仅在您还使用适当的pinentry配置启动gpg-agent时才有效(您可能必须启动另一个实例，该实例与系统上已运行的实例分开)。gpg-preset-passphrase
直接传递密码最重要的用例是在无头守护程序中，没有人等待输入密码。 GnuPG还带来了一个小的实用程序gpg-preset-passphrase(在Debian和衍生产品上，它作为/usr/lib/gnupg2/gpg-preset-passphrase安装)，该实用程序还可用于预缓存密码(因此在可配置的时间内不会被查询)。
Pinentry环回
在GnuPG 2.1中，添加了另一个选项:在gpg-agent中，您可以使用allow-loopback-pinentry选项允许pinentry回送。在GnuPG / GPGME中设置为pinentry-mode的其他参数loopback应该允许您再次使用passphrase_cb处理密码短语交互。
但是:考虑到这不仅暴露了您的应用程序和GnuPG的通行口令，而且可能被证明是(可能很小，但存在但可能是不必要的)安全风险。另外，GnuPG 2.1尚未广泛传播，如果您不控制环境，这可能是一个问题。