GPGME使用passphrase_cb方法从用户处获取密码以进行操作，这需要访问私钥。此回调只能被覆盖以进行对称加密，在所有其他情况下，使用默认的pinentry。
所有这些努力似乎都非常不舒服，特别是因为GPGME是一个API，它将用于编程C / C ++ / ...应用程序。如果密码短语可以直接传递给加密/签名函数，在某些情况下可能更容易（对于想要使用GPGME的程序员）。我还看到OpenPGP的其他实现（更确切地说是NetPGP）使用回调。
所以我想知道是否有任何特定安全理由这样做？
答案 0 :(得分：2)
从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），它也可用于预密码密码（因此在可配置的时间内不会查询）。 / p>
使用GnuPG 2.1，添加了另一个选项：在gpg-agent中，您可以使用allow-loopback-pinentry选项允许pinentry环回。 GnuPG / GPGME中设置为pinentry-mode的其他参数loopback应允许您再次使用passphrase_cb处理密码短语交互。
但是：考虑到这会泄露密码短语，而不是你的应用程序和GnuPG，并且可能被证明是（可能是次要但现有且可能不必要的）安全风险。此外，GnuPG 2.1尚未广泛传播，如果您不控制环境，这可能是一个问题。