GPGME 使用passphrase_cb方法从用户那里获取密码以进行需要访问私钥的操作。此回调只能用于对称加密，在所有其他情况下使用默认 pinentry。
所有这些努力似乎都非常不舒服，特别是因为GPGME是一个用于编程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 尚未广泛传播，如果您不控制环境，这可能是一个问题。