使用 patatt 和 b4 进行端到端补丁证明

最近UMN 事件的副作用之一是重新审查内核开发过程，该过程继续依赖通过电子邮件发送的补丁。这促使我重新审视我的端到端补丁证明工作，并使其达到我认为它在日常工作中既稳定又从底层安全性和可用性的角度来看令人满意的程度。

项目目标

这些是一开始的目标：
选择加入并且不干扰现有的工具和工作流程

尽可能在幕后和非侵入性

简单易懂，解释和审计

我相信提议的解决方案符合所有这些要点：
该实现与 DKIM 非常相似，并使用电子邮件标头对所有相关内容（“发件人：”和“主题：”标头，以及邮件正文）进行加密证明。任何现有的工具都会忽略无法识别的标头。
加密签名是通过 git-send-email(

)自动调用的 git hook 完成的，因此只需设置一次，不需要记住执行任何额外步骤

进行签名的库只有几百行 Python 代码，并且在其大部分逻辑中重用了 DKIM 标准

介绍patatt

该库称为“patatt”（显然是补丁证明），可以从PyPi安装：

它只需要 PyNaCl（Python libsodium 绑定）、git 和 gnupg（如果使用 PGP 密钥签名）。详细的操作原理在PyPi项目页面有描述，这里不再赘述。

上面链接的截屏视频从常规补丁贡献者的角度显示了 patatt 的运行情况。

支持 b4

Patatt 从 b4 的 0.7.0 版开始得到完全支持——这里正在验证Greg Kroah-Hartman的补丁:

正如你在上面看到的，b4 验证了 DKIM 头是有效的，并且来自 Greg Kroah-Hartman 的 PGP 签名也通过了，双重保证消息在离开 Greg 的计算机和在终端系统上检查之间没有被修改。检索补丁的人。

钥匙圈管理

Patatt（和 b4）还引入了在 git 存储库本身中跟踪贡献者公钥的想法。这听起来可能很愚蠢——存储库本身怎么能成为可信密钥的来源？但是，它实际上很有意义，并且并不比当前使用的任何其他公钥分发机制差：

• git 已经是去中心化的，可以镜像到多个位置，避免任何单点故障
• 所有内容都已经版本化，关键的添加/删除可以被审计和“git blame’d”
• git 提交本身可以进行加密签名，这允许一小部分开发人员充当许多其他贡献者的“可信介绍人”（模仿“密钥签名”过程）

贡献者公钥可以与项目代码库一起添加到主分支本身（可能在.keys顶级子目录中），也可以在专用引用中进行管理，例如refs/meta/keyring。后者对于大型项目特别有用，在这些项目中，补丁由子系统维护人员收集，然后作为拉取请求提交以包含到主线存储库中。将密钥环保存在自己的 ref 中可确保它不受常规开发工作的影响，但仍可集中管理和跟踪。