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