mutt：使用 gpgme 还是经典 gpg？

Question

Mutt 关于 GnuPG 集成的 wiki和许多其他地方（如 Debian 上的默认设置）使用经典方式将 mutt 连接到 gnupg。即配置一堆命令gpg直接调用。另一方面，有一个名为 的库gpgme，它试图准确地标准化。在网上搜索“mutt gpgme”并没有给我任何真正有用的结果。

使用set crypt_use_gpgme=yesin 的优缺点是.muttrc什么？为什么很少使用？

Answer 1

很多人真的不了解 GPGME，现有的文档基本上是当时编写的代码注释，这可能无济于事。但是，它将允许对整个 GNU Privacy Guard 套件进行完全或接近完全的编程访问，并且还应该能够访问诸如 libassuan、gpg-agent 和各种其他组件之类的东西。这就是为什么默认情况下它还包括 S/MIME 实现，除了在 90 年代后期大声喊叫的几家公司之外，几乎没有人使用它。

目前 GPGME 包含 500 个或更多独立函数，并且肯定涵盖了您在命令行上使用 GPG 所做的几乎所有事情。然而，它也包含一些先前设计选择的遗物，这些遗物后来被确定为不是正确的方向。例如，这是一个包含大量 GTK 2 的 API。显然，这需要进行（并且在时间允许的情况下会进行）。现在还有一个问题，也许采用的最大障碍是当有人说“API”时，大多数编码人员不会立即想到用自己的代码编译 C 头文件以访问它；让我们面对现实吧，现在大多数人都在考虑 RESTful 的东西，或者至少让他们与 JSON 格式的数据进行交互。GPGME 与它相差甚远' 有可能得到。请注意，虽然它应该可以很好地与 JSON 一起使用，但它永远不可能是 RESTful，因为编辑键不能。此外，通过网络管理密钥只是自找麻烦。

该软件还有许多未记录的功能和方面，因此即使是自软件诞生以来就使用该软件的人仍然会对某些事情感到惊讶。就像密钥环数据的 XML 格式一样，除了正式模式（直到几个月前生成）之外，它具有所有内容。

另一方面，尽管 Mutt 做了很多好事，但它也做了一些相当令人震惊的事情。例如，无论是否使用 GPGME，Mutt 都应该没有理由缓存密码；在任何一种情况下，它都应该交给 GPG（有或没有 gpg-agent）。同样，它应该遵守~/.gnupg/gpg.conf文件中的配置参数（以及该目录中的其他参数）。当然，为不同的帐户设置备用密钥 ID 以更改调用命令的方式，甚至能够指定备用配置文件或整个目录（例如gpg --homedir ~/.gnupg-work/gpg.conf）。然而，就目前情况而言，Mutt 浪费时间试图解决与其交互的程序已经解决的问题，例如密码或密钥管理，但不允许访问 GPG 的正常功能，其中许多功能非常适合电子邮件比如为多个收件人使用组行或覆盖特定收件人的密钥选择（因为总是有一个人不断丢失他的密钥或忘记密码，现在你有 15 个公钥与 UID 和默认行为是选择第一个很可能不正确的匹配项）。Emacs 在那里稍微好一点，但即使它无法接收gpg.conf通常会自动回答它想要提示的内容的文件。

现在，对于一些更有用和切线相关的东西，GPGME 附带了另一个漂亮的小东西，称为 gpgme-tool。它是 GPGME 的基本接口，它将在 UNIX 套接字上运行（当然，如果需要，您可以使用 ncat 或其他东西使其位于网络端口上）。虽然它没有记录，但如果你运行它并与它交互一段时间并从 help 命令开始，它是相当不言自明的。或者，这很有效：

echo help | gpgme-tool > gpgme-tool-cheatsheet.txt

它会很高兴地完成所有基础操作（加密、解密、签名、验证、更改密码、生成密钥、列出密钥、列出秘密密钥、搜索特定密钥或选择它们等）。如果您想查看“隐藏”的 XML 格式，请尝试以下操作：

echo "KEYLIST --secret-only" | gpgme-tool > secret-key-list.xml

这不会导出密钥，只需列出它们和有关它们的数据。此外，它会导出一些需要过滤掉的输出格式 cruft，然后才能真正将其识别为 XML（删除第一行、每个后续行的前两个字符以及每行末尾的 %0A ）。无论如何， gpgme-tool 可能会更好地了解 GPGME 的真正功能。例如，GPGME 的 PyME Python 绑定尝试自动匹配 GPGME 函数（并且通常可以毫无困难地实现）；pyme.core.pygpgme 中的当前功能列表为 534。与命令行相比，GPG 1.4.20 有 322 个选项，而 2.1.11 有 347 个（我跳过了 2.0，所以我无法检查，但应该介于两者之间）。

至于前面提到匹配关键命令的答案，这应该完全由配置选项驱动，以及 Mutt 是否“允许”完全访问 GPG。我目前正在将 Mutt 与 GPGME 一起使用，并且提到的两个功能（邮件键和提取键）都很好，尽管 Mutt 确实无法识别 PGP/内联内容，如果它已从某处。当发生这种情况时，是的，通常需要切换到 Emacs 或其他东西。尽管如此，这似乎是 Mutt 检查内容是否真的只是文本的方式或它如何检查 OpenPGP 格式内容的问题。虽然我只想说我们都应该使用 PGP/MIME（我们应该这样做），

基本上，看起来 Mutt 完全依赖于消息是多部分 MIME，其中一个或多个部分包含密钥、签名和/或加密内容，以便它可以做任何事情。它不会只是在任何普通电子邮件中搜索匹配的内容，但这既不是 GPG 的错，也不是 GPGME 的错。解决方案是将这些功能添加到 Mutt 或在具有该功能的东西中打开消息（例如带有 EPA/EasyPG 的 Emacs，这些天应该默认启用）或通过管道将消息输出到直接命令（或 gpgme-tool如果您愿意，但在进行管道传输时，直接执行常规命令通常更容易）。

至于 GPGME，并不是每个人都可以使用它，因为它总是需要从与系统上安装的相同源版本编译。如果您升级 GPG 并且不重新编译 GPGME 以匹配，那么可能会出现问题。另一方面，通常建议在可能的情况下从源代码安装 GPG，因此如果使用 GPGME 路线，那么在更新 GPG 时只运行重新编译就成为一种好习惯，一切都应该没问题。

而那些完全依赖于他们选择的发行版提供的包的人也将受到这些包的维护者可能会费心维护的任何事情的影响，他们可能总是也可能不了解 GPG 和 GPGME 一起工作的要求。例如，GPGME 的 MacPorts 包设置为依赖 GPG 2.0.x，而 GPG 2.0.x 又设置为与 GPG 2.1.x 冲突，因此大多数安装 2.1 的人不能同时安装 GPGME，即使他们显然可以协同工作。让 GPGME 在这种情况下工作需要做 MacPorts 建议反对的事情（在端口管理系统之外编译东西，但在/opt/local. 一些 Linux 发行版可能有类似的问题。

因此，如果您只打算使用 PGP/MIME，那么使用 GPGME 集成应该没有问题，这意味着您永远不必将特定命令配置到您的.muttrc文件中。如果您处理 PGP/in-line，那么您将遇到问题，但无论使用 Mutt 都无法避免这些问题，因此我建议您尽可能使用 GPGME。

免责声明：我参与了开发工作，为所有非 C 开发人员制作 API 的 API，以便能够在大修后使用该东西。我还将 PyME 0.9 从 Python 2 移植到 Python 3（它目前位于GPGME 的一个分支中，只有 Python 2 版本可通过 PyPI 和 pip 获得）。

更新：PyME 到 Python 3 的端口现在位于 GPGME 的 master 分支中，并且在 PyPI 上作为 pyme3 可用。

Answer 2

加密货币的人很偏执，并且了解命令行。该库是新的且未经测试的，但具有理论优势。试试吧，你可以成为我们的测试假人。