锈迹斑斑的OpenPGP：红杉项目

LWN订户已向您提供以下仅限订阅的内容。数以千计的用户依赖LWN获取来自Linux和自由软件社区的最好消息。如果您喜欢这篇文章，请考虑接受右边的试用报价。感谢您访问LWN.net！

免费试用LWN 1个月：无需付款或信用卡。现在激活您的试用订阅，看看为什么成千上万的读者订阅LWN.net。

2018年，三名前GnuPG开发人员开始了Sequoia的工作，Sequoia是Rust中OpenPGP的新实现。OpenPGP是数据加密的开放标准，通常用于安全电子邮件；GnuPG是该标准的实现。GPLv2许可的Sequoia正在迈向1.0版，还有一些问题有待解决。该项目的创始人认为，GnuPG还有很多需要改进的地方，GnuPG是当今OpenPGP事实上的标准实现。他们希望通过使用一种语言重新实现该规范来解决这个问题，该语言的功能将有助于保护用户免受常见类型的内存错误的影响。

虽然GnuPG是最流行的OpenPGP实现-尤其是在Linux上-但还有其他实现，包括OpenKeychain、OpenPGP.js和RNP。OpenPGP多年来一直受到批评(比如2014年的这篇博客文章，以及2019年的另一篇)；Sequoia项目正在努力构建现代的OpenPGP工具，以解决其中许多抱怨。Sequoia已经被其他几个项目采用，包括keys.openpgp.org、OpenPGP CA、koverto、Pijul和Kipa。

红杉由尼尔·H·沃尔菲尔德(Neal H.Walfield)、贾斯图斯·温特(Justus温特)和凯·米凯利斯(Kai Michaelis)创立，每人在GnuPG上工作了大约两年。在2018年的一次演示中[YouTube](幻灯片[PDF])，Walfield讨论了他们对新项目的动机。在他看来，GnuPG很难修改-主要是因为它几十年来的有机增长。Walfield指出，GnuPG中组件之间的紧密耦合和缺乏单元测试是具体的问题领域。例如，他指出GnuPG命令行工具和相应的应用程序库没有相同的功能；有些事情只能使用命令行工具来完成。

正如Walfield在他的演讲中解释的那样，社区是红杉项目的重要组成部分。该项目得到了p≡p(PEP)和Wau Holland基金会的资金支持，所有的开发都是在公开进行的。甚至在编写代码之前，项目创始人就会见了OpenPGP社区的重要成员以及最终用户，讨论项目的计划，并确保他们的方法是合理的。项目的当前状态、Git存储库和问题跟踪器都可用。存储库日志显示该项目大约有30个贡献者，自从2020年4月宣布即将发布的1.0版以来，已经发布了三个版本。最新版本0.19.0是在2020年8月发布的-其最显著的改进是包含了Windows Cryptoography API：Next Generation(CNG)作为后端，取代了在非POSIX环境中存在问题的Nettle。

因为它是用Rust编写的，所以Sequoia受益于该语言提供的所有内存安全优势。存储库显示，正在做出重大努力来编写单元测试，以防止倒退和提高质量。与GnuPG不同，在GnuPG中，命令行gpg工具比库更强大，而Sequoia首先是一个OpenPGP库；它的所有功能都可以通过公开的API使用。该项目计划提供两个级别的API，一个是OpenPGP规范的低级非自以为是的实现，另一个是具有合理默认值的高级API，以使用户更容易执行签名和签名验证等常见任务。Walfield的陈述清楚地表明，虽然该项目努力在低级API实现上保持不自以为是，但它确实避免了规范中过时的部分，如MD5散列的使用。

红杉的目标是现代平台，包括Linux、Windows、MacOS、Android和iOS。如果可能，这包括使用现有的加密工具；与特定于平台的加密服务紧密集成是该项目的设计目标。例如，Sequoia计划在iOS设备上使用Secure Enclave协处理器(如果可用)。它还提供了一个外部函数接口(FFI)，用于将项目与用其他语言编写的程序集成。目前，Sequoia提供C和Python FFI绑定。读者应该注意到，使用绑定的程序缺乏内存安全性，因此必须遵守项目的规则才能正确使用它们。

Walfield在Sequoia开发邮件列表上回答了我的问题，提供了关于项目当前状态和即将发布的1.0版本的信息：

首先，对于我们即将发布的1.0版本(Anytime Now(Tm)，尽管API和功能集已经稳定了几个月；我们只是记录了一切，并仔细检查了API和amp；代码)，我们只发布了低级API，即Sequoia-OpenPGP机箱及其依赖项。

这意味着读者现在还不能指望Sequoia会成为GnuPG等工具的最终用户替代品；第一个主要版本将专注于面向开发人员的库。要使项目为最终用户做好准备，它需要与GnuPG中的gpg命令等效。对于Sequoia，这是SQ命令行工具，1.0版不包括该工具。沃尔菲尔德将SQ描述为缺少相当多的功能，并解释说，我们希望保留在其向公众发布之前更改其界面的权利。

SQ工具并不是1.0版中唯一缺少的；密钥存储服务仍在进行中。根据沃尔菲尔德的说法，这是1.0版本发布后最优先考虑的项目之一。

与其他OpenPGP实现相比，密钥存储是红杉计划独一无二的领域之一。为了提高安全性，项目计划在处理公钥和私钥的服务之间使用进程分离；Cap'；n Proto将用于进程间通信。Walfield在他的演示中指出，进程分离并不总是可能的，例如在iOS环境中。当它不可用时，Sequoia计划使用共享的SQLite数据库在进程Walfield中的两个服务之间通信，该进程被描述为托管。

从概念上讲，Sequoia对其公共密钥环采用了基于身份的方法，其中密钥环更像是每个域的地址簿，而不是PGP密钥环。密钥被设计为使用用户分配的Petname来存储和访问，并能够将对实现信任模型有用的任意结构化数据关联起来。Walfield还认为，这种方法更符合用户对键的实际想法：与名称相关联，而不是抽象ID的集合。此外，在Sequoia中，所有密钥都被分配一个领域，指明密钥的预期用途；目前，领域包括"；联系人&34；和软件更新密钥"；指定。完成后，红杉的密钥环服务将自动更新远程服务器上的公钥(类似于Parcimonie)，确保及时发现新的子密钥和撤销等更改。API文档指出，除了更常见的TLS加密方法之外，还可以使用Tor等匿名服务来实现这一点。

私钥环服务计划为解锁本地密钥提供可选的一次密码解决方案。该库将使用沃尔菲尔德所说的类似智能卡的API提供对私有密钥环的访问。目前红杉不支持智能卡，但基于这张罚单，社区希望看到它在未来发生。通过使用OpenPGP规范来支持静态数据(加密存储)和动态数据(加密传输)之间的区别，Sequoia的私钥环服务将考虑到前向保密性，这在许多其他实现中是找不到的。频繁轮换动态密钥是一种良好的安全做法，但这需要以一种仍然允许对存档的加密数据进行解密的方式来实现。温特的演示文稿(幻灯片[PDF])将该项目的前向保密功能与其他OpenPGP实现进行了比较。

那些有兴趣参与这个项目的人应该知道，它需要贡献者将他们的版权分配给p≡p基金会。该项目进一步指出，代码最终可能会在多个许可证下发布，但是所有软件也都是在GNU许可证下作为自由软件发布的，无一例外。

总而言之，很高兴看到一个专注于使OpenPGP成为更容易访问的技术的项目，而且看起来该项目自近三年前开始以来已经取得了稳步的进展。该项目的文档也为在应用程序中使用该库提供了一个合理的起点。这就是说，Sequoia在成为一个可信的加密工具之前还有很长的路要走；对于初学者来说，代码仍然需要审计。该项目的状态页面显示它还没有经过审计，但是一旦我们发布了核心的红杉木箱，它就会被第三方审计。读者可能有兴趣查看该项目的贡献者页面，该页面提供了他们的邮件列表和IRC频道的详细信息。正如沃尔菲尔德所说，红杉1.0版何时登陆还没有时间表，但听起来似乎很快就会落地。然而，在Sequoia成为可行的替代品之前，OpenPGP的最终用户还需要等待更长的时间。

你喜欢这篇文章吗？请接受我们的试用订阅优惠，以便能够看到更多类似的内容并参与讨论。

Cyberax发布的2020年9月11日19：14协调世界时(✭Support✭，#52523)[链接]。

我看到了iOS的一个问题--因为GPL，他们不能使用它。

是的，它仍然会作为命令行工具被非GPLv2项目调用，以避免复制。为什么不采用MPL 2.0，它是按文件版权管理的，可以在iOS上使用，比如VLC。

为什么不将IOS TOS更改为与GPL冲突？我认为iOS上有几个GPL应用(我知道GNU Jami就是其中之一)已经存在多年了，所以苹果似乎并不关心或执行他们的服务要求。因此，真正的问题是，为什么他们选择GPLv2，而GPLv3更好？他们想在没有任何合法追索权的情况下将他们的程序嵌入到专用设备中吗？他们应该升级他们的执照。

Cyberax发布的2020年9月11日21：31 UTC(星期五)(✭Support✭，#52523)[链接]。

>；因此，真正的问题是，为什么他们选择GPLv2，而GPLv3更好？他们想在没有任何合法追索权的情况下将他们的程序嵌入到专用设备中吗？他们应该升级他们的执照。GPLv3并没有更好...

>；GPLv3并没有更好...。请停止传播FUD。GPL3在GPL2的基础上进行了改进，修复了通告漏洞，提供了专利授权，增加了与Apache2等许可证的兼容性，以及其他一些我已经忘记的事情。

我不认为提供专利授权是一种进步……。是的，v3有很多针对v2的错误修复，如果他们仅限于此，那将是一个真正的改进。(我也听人说过--对于FSF所说的错误修复--他们认为v2是一种功能，并不想要修复！)。

我和沃尔在一起。GPLv3是不同的。一些错误修复将很好地折叠成一个GPLv2.1&34；。以及社会契约的一些重大变化，这将更适合不同的许可证。

我们原来选择的其实是GPLv3+，但是有人要求我们改成GPLv2+，这个要求是合理的，我们就这么做了。

版权所有者可以否认GPL中与App Store条款冲突的任何限制。例如，Blink Shell是GPL&39；d，依靠MOSH开发者的豁免，它在iOS上已经可以使用一段时间了(因为MOSH也是GPL&39；d)。

Cyberax发布的2020年9月11日19：54协调世界时(✭Support✭，#52523)[链接]。

问题是，GPL+免责声明基本上是一个不同的许可，每个贡献者都必须同意它。这并不是真正可持续的。例如，如果苹果被迫将Apple Store拆分成另一家公司，并将其更名为Pear Store，免责声明将无效。他们必须得到每一个曾经为核心代码做出贡献的版权所有者的同意，才能获得一个新的例外。事实上，我并不介意GPL允许通过应用程序商店分发的律师证明的例外，但这不会允许滥用(我的应用程序是一个商店，所以我可以通过它分发经过GPL的应用程序！"；)。

这在这种情况下不是问题，因为贡献者被要求将版权分配给基金会，基金会可以根据需要重新许可例外，如果我理解正确的话。

但这意味着OpenPGP仅成为代码捐赠者项目-他们不能重复使用来自其他项目的代码，因为他们需要联系版权所有者-代码尚未提交给该项目。这就是GPL的任何扩展的问题--您不能利用其他GPL代码来包含在您自己的项目中。

我实际上不介意GPL允许通过应用程序商店分发的律师证明的例外，但这不会允许滥用(我的应用程序是一个商店，所以我可以通过它分发经过GPL处理的应用程序！"；)。只要下载将用户指向第三方源代码分发站点(不是您的第三方，也不是应用商店)上的相应源代码，那么在纯二进制站点上分发二进制文件是可以接受的。请注意，GPLv3允许单独分发二进制和源代码，而不会触发"；Binary-Only意味着您必须提供为期3年的源代码"；条款。(这是v2中的一个错误，至少有些人希望看到它进入v3)。这是一个错误，因为它意味着收件人的行为改变了提供者的责任。

与其他OpenPGP实施方案相比，>；密钥存储是红杉计划独一无二的领域之一。为了提高安全性，项目计划在处理公钥和私钥的服务之间使用进程分离；Cap'；n Proto将用于进程间通信。

引用的文字有点误导。私钥操作通常会在单独的进程中执行，这是事实。而且，您说得对，这正是gpg-agent的用途。SQ和Sequoia的高级API所鼓励的，以及与GnuPG不同的是，密钥是如何寻址的。红杉的密钥库首先使用petname来寻址密钥。你可以把Petname想象成个人通讯录中的一个条目：它是由你控制的，而不是钥匙的创建者。通过这种方式，地址簿条目直接与键相关联。目前，这是间接完成的：您从地址簿中选择一个收件人，您的MUA提取一些信息，并查询GnuPG'；的密钥库以查找具有匹配标识符的密钥，然后使用返回的密钥。只要您仔细管理您的钥匙环，并且不要有具有相同标识符的多个密钥，就可以很好地工作。但是，一旦发生这种情况，对于大多数用户来说，逻辑就变得相当不可预测了。

非常有趣。这听起来和我需要的东西一模一样。前段时间我试着做了一个与PGP相关的项目，发现GPG的结构非常不方便。我想要做的事情之一是检查密钥服务器的存档并解析数据。需要调用GPG，给它一个密钥，然后解析结果，这是缓慢而痛苦的。我真正想要的是一个库，在这个库中，我可以将一个ASCII编码的密钥提供给某个函数，然后取回所有数据--它属于谁、谁签署了它、何时过期等等，同时确保密钥完全有效，所有签名都是正确的等等。理想情况下，所有这些都不需要启动一百万个进程，也不需要绕过GPG对主目录和钥匙环等东西的需求。如果这个项目可以用于这样的任务，我非常感兴趣，而Rust听起来像是一个额外的好处，因为在解析一个巨大的密钥归档文件时，有明显的安全问题，这些年来，它很可能已经受到了许多方面的攻击。

完全同意。GPGme试图填补PGP库的角色，但因为它只是gpg的包装器，所以即使您只是想检查一个钥匙环，您也需要做一些事情，比如拥有一个GnuPG home dir。作为一个整体，GnuPG项目的架构是落后的。GPGme从字面上调用gpg并抓取输出，而不是将gpg作为PGP库的前端。除了实现API的疯狂方式之外，这还意味着GPGme中的任何功能都必须首先表示为某个gpg CLI选项。