Mutt关于GnuPG集成和其他许多地方的Wiki（例如Debian上的默认设置）使用将Mutt连接到gnupg的经典方法。也就是说，一个配置了一系列命令以gpg直接调用。另一方面，有一个名为的库gpgme，它试图对此进行标准化。在网上搜索“ mutt gpgme”并没有给我任何真正有用的结果。
使用set crypt_use_gpgme=yesin有.muttrc什么优缺点？为什么很少使用？
Mutt关于GnuPG集成和其他许多地方的Wiki（例如Debian上的默认设置）使用将Mutt连接到gnupg的经典方法。也就是说，一个配置了一系列命令以gpg直接调用。另一方面，有一个名为的库gpgme，它试图对此进行标准化。在网上搜索“ mutt gpgme”并没有给我任何真正有用的结果。
使用set crypt_use_gpgme=yesin有.muttrc什么优缺点？为什么很少使用？
Answers:
很多人真的不了解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
那不会导出秘密密钥，只列出它们和有关它们的数据。另外，它还会以某种输出格式残存进行导出，在将任何内容真正识别为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.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的一个分支中，并且只能通过PyPI和pip使用Python 2版本）。
更新：PyME到Python 3的端口现在位于GPGME的master分支中，并在pyPI上以pyme3形式提供。