mutt：使用 gpgme 还是经典 gpg？

Question 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 或其他东西使其位于网络端口上）。虽然它没有记录，但如果您运行它并与它交互一段时间并从帮助命令开始，它是相当不言自明的。或者，这也很有效：

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

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

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

这不会导出密钥，只是列出它们和有关它们的数据。另外，它会以一些粗俗的输出格式导出，在任何内容真正将其识别为 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（而且我们应该这样做），但不幸的是，很多人坚持使用内联，因为他们想要这样做（例如 Windows 上 The Bat! 的用户））或需要（例如，他们需要从 Android 设备发送加密的电子邮件）。

基本上，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/内联，那么您将会遇到问题，但是使用 Mutt 都无法避免这些问题，因此如果可以的话，我建议您使用 GPGME。

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

更新：PyME 到 Python 3 的端口现在位于 GPGME 的主分支中，并在 PyPI 上以 pyme3 形式提供。

Answer