OpenSSL 兼容性

根据此提案，OpenSSL 可能会在 Python 2.7 维护版本中升级到更新的功能版本。在 Linux 和大多数其他 POSIX 系统上，所使用的 OpenSSL 特定版本已经有所不同，因为 CPython 默认动态链接到系统提供的 OpenSSL 库。

对于 Windows 二进制安装程序，_ssl 和 _hashlib 模块与 OpenSSL 静态链接，并且相关符号未导出。Marc-Andre Lemburg 表示，在 egenix-pyopenssl 二进制文件中更新到较新的 OpenSSL 版本尚未导致任何报告的兼容性问题[3]

Mac OS X 二进制安装程序历史上遵循与其他 POSIX 安装相同的策略，并动态链接到 Apple 提供的 OpenSSL 库。然而，Apple 现在已停止更新这些跨平台库，而是要求即使是跨平台开发人员也采用 Mac OS X 特定接口来访问其平台上最新的安全基础设施。因此，独立于本 PEP，Mac OS X 二进制安装程序已经计划切换到静态链接较新版本的 OpenSSL[4]

可维护性

包括 Alex Gaynor 和 Donald Stufft 在内的许多开发人员都表示有兴趣执行此策略涵盖的功能回溯，并协助解决 Python 2 系列因此产生的任何额外维护负担。

Steve Dower 和 Brian Curtin 已提出帮助创建 Windows 安装程序，让 Martin von Löwis 有机会退出维护 2.7 Windows 安装程序的工作。

本 PEP 主要旨在建立必要的共识，以允许他们开展这项工作。对于其他核心开发人员，此策略更改不应施加任何额外的工作，除了可能为那些对受影响模块特别感兴趣的开发人员审查生成的补丁。

安全发布

本 PEP 不提议对安全发布的处理进行任何更改——这些将继续是仅包含关键安全修复的纯源代码发布。

然而，对库和应用程序开发人员的建议是专门设计的，以适应选择将这些更改应用于处于仅安全修复模式或已被核心开发团队声明“生命周期结束”的其他 Python 发布系列的商业再分发商。

再分发商是否选择行使该选项将由各个再分发商决定。

集成测试

第三方集成测试服务应向用户提供针对多个 Python 2.7 维护版本（至少 2.7.6 和 2.7.7+）进行测试的能力，以确保库、框架和应用程序仍能正确测试其对传统安全基础设施的处理（根据软件的安全敏感性，要么失败，要么优雅地降级），即使在此提案涵盖的功能已回溯到 Python 2.7 系列之后。

处理风险承受能力较低的低安全环境

无论好坏（大多数是坏的），在某些环境中，对潜在安全缺陷的容忍度高于即使维护版本中回归风险略有增加。本提案在涉及豁免涵盖的模块时，很大程度上将这些环境排除在外——这种方法完全不适用于连接到公共互联网的软件，并且深度防御安全原则表明它也不适用于大多数私有网络。

下游再分发商仍可能选择迎合此类环境，但他们需要自行处理降级安全相关模块并进行相关回归测试的过程。CPython 主持续集成基础设施将不涵盖此场景。

为什么选择这些特定的更改？

考虑纳入本提案的功能的关键要求是它必须对**超出**用 Python 编写的特定应用程序和该应用程序运行的系统之外的安全性产生影响。因此，重点放在网络安全协议、密码存储和相关加密基础设施——Python 是开发 Web 服务和客户端的流行选择，因此广泛使用的 Python 版本的特性对其他服务（这些服务本身可能使用较新版本的 Python 或其他开发语言）的安全设计产生影响，但需要与使用较旧版本 Python 编写的客户端或服务器进行互操作。

此要求的意图是最大限度地减少此策略的引入可能对维护版本的稳定性和兼容性产生的影响，同时仍然解决与 Python 2.7 特定方面相关的一些关键安全问题。如果最终用户对更新到新的 Python 2.7 维护版本的谨慎程度与更新到同一发布系列中的新功能版本一样，那将是彻底的适得其反。

本提案中包含 ssl 模块的更改，旨在使 Python 2 系列与过去 4 年的网络安全标准演进保持同步，并使这些标准更容易在服务器和客户端中广泛采用。类似地，hashlib 中的哈希算法可用性指示符包含在内，以使应用程序更容易在 Python 2 和 3 中检测和使用适当的哈希定义。

包含 hmac.compare_digest() 和 hashlib.pbkdf2_hmac() 旨在帮助降低 Python 2 服务器应用程序中安全密码存储和检查的障碍。

本提案中已包含 os.urandom() 更改，以进一步鼓励用户将为加密用例提供高质量随机数的工作留给操作系统供应商。使用随机数不足可能会危及**任何**加密系统，并且操作系统开发人员拥有比典型的 Python 应用程序运行时更多的工具来充分解决该问题。

被拒绝的替代方案：仅建议开发人员迁移到 Python 3

这种替代方案代表了现状。不幸的是，它在实践中被证明是不可行的，因为向后兼容性影响意味着对于大型应用程序和集成项目来说，这是一个非平凡的迁移过程。虽然迁移工具已经发展到可以通过更新代码以在 Python 2 和 Python 3 的大公共子集中运行（而不是一次性）来机会性地增量迁移大型应用程序的程度，但在商业环境中，使用最新技术通常不是优先事项。

此前，这被认为是一种可接受的损害，因为虽然这对于受影响的开发人员来说是一个不幸的问题，但它被视为他们与管理层之间的问题，需要争取基础设施现代化，并且随着 Python 3 系列的发展，这个理由将自然变得更具说服力。

然而，现在我们完全意识到 Python 2 标准库的局限性可能对互联网安全标准演进产生的影响，我不再认为期望平台和应用程序开发人员仅仅为了获得 Python 3 中已有的网络安全增强功能而解决应用程序 Unicode 正确性中的所有潜在缺陷是合理的。

虽然 Ubuntu（以及某种程度上 Debian 也）致力于将所有默认系统服务和脚本移植到 Python 3，并从其默认分发镜像中移除 Python 2（但不是从其存档中），但这是一项艰巨的任务，并且不会在 Ubuntu 14.04 LTS 版本中完成（至少对于桌面镜像——移动和服务器镜像可能实现）。

Fedora 有更多的工作要做以进行迁移，并且迁移相关基础设施组件将需要大量时间。虽然 Red Hat 也在积极努力使用户更容易在我们稳定的平台上使用更新的 Python 版本，但这些努力开始对最终用户的版本选择产生影响需要时间，并且任何此类更改也不会惠及集成系统 Python 中运行的核心平台基础设施。

OpenStack 迁移到 Python 3 也仍处于起步阶段，即使这是一个拥有广泛且相对健壮的自动化测试套件的项目，它仍然足够大，需要相当长的时间才能完全迁移到 Python 2/3 兼容代码库。

而这仅仅是三个大量使用 Python 的最知名的开源项目。考虑到可能存在大量缺乏支持从 Python 2 迁移到 Python 3 所需的自动化回归测试套件的遗留代码，很可能在许多情况下，重新实现（甚至可能在 Python 3 中）比迁移更容易。本 PEP 的关键点是这些情况影响的人不仅仅是受影响应用程序的开发人员和用户：存在具有过时网络安全基础设施的客户端和服务器成为安全网络服务开发人员在安全设计中需要考虑的问题，而这阻碍了更好的安全标准的采用。

正如 Terry Reedy 所指出的，如果我们试图坚持现状，可能的结果是商业再分发商**仍然会**代表其客户尝试做类似的事情，但可能以不一致和随意的方式。通过将范围定义过程引入上游项目，我们能够更好地影响解决情况的方法，并有助于确保再分发商之间的一致性。

问题是真实的，所以**需要**改变，本 PEP 描述了我解决这种情况的首选方法。

被拒绝的替代方案：创建并发布 Python 2.8

如果获得足够的公司支持，**确实**有可能创建并发布 Python 2.8（此类项目极不可能获得足够多的兴趣以仅靠志愿者实现）。然而，这实际上并不能解决问题，因为目的是提供一种**相对低影响**的方式，将增强的安全功能整合到利用 Python 2 的集成产品和部署中。

升级到新的 Python 功能版本将意味着核心开发团队的工作量增加，以及更具破坏性的更新，大多数潜在最终用户可能会完全跳过。

尝试创建 Python 2.8 版本还将带来从 Python 3 回溯许多额外功能的建议（例如 tracemalloc 和改进的协程支持），这使得从 Python 2.7 迁移到这个假设的 2.8 版本更加危险和更具破坏性。

这不是推荐的方法，因为它将涉及大量的额外工作，而结果在实现原始目标（消除 Python 2 系列中当前广泛使用的老旧网络安全基础设施）方面实际上效果较差。

此外，虽然我不能承诺真正在 Red Hat 平台上解决这个问题，但我**可以**明确排除 Python 2.8 对我试图解决这个问题有任何用处的想法。

被拒绝的替代方案：通过 PyPI 分发安全增强功能

虽然这最初看起来是一种吸引人且更易于管理的方法，但它实际上存在几个严重问题。

首先，这是复杂的、低级的、跨平台代码，它与各种 POSIX 平台（包括 Mac OS X）和 Windows 上的底层操作系统集成。CPython BuildBot 机群已经设置好处理这种上下文下的持续集成，但大多数免费的持续集成服务只提供 Linux，可能还有付费访问 Windows。这些服务对于主要运行在 Python 和其他动态语言提供的抽象层以及 JVM 提供的更全面抽象之上的软件来说运行良好，但不足以满足这里涉及的代码类型。

网络安全支持的 OpenSSL 依赖项也属于“复杂二进制依赖项”，pip 基于的软件分发生态系统尚未很好地处理这类依赖项。依赖第三方二进制依赖项还会为在 PyPy 等其他解释器上运行时 pip 带来潜在的兼容性问题。

这个想法的另一个实际问题是 pip 本身依赖于标准库中的 ssl 支持（并获得捆绑的 requests 副本的一些额外支持，而 requests 又捆绑了 backport.ssl_match_hostname），因此需要任何替代模块也捆绑在 pip 中。这不会造成任何不可克服的困难（只是另一个要提供的依赖项），但它**确实**意味着又一个需要保持更新的 OpenSSL 副本。

这种方法还存在所有其他“通过重命名来提高安全性”方法相同的缺陷：它们完全错过了最需要帮助的用户，并大大阻碍了在基础设施支持时鼓励用户做正确事情的能力（因为“使用这个其他模块”的影响远高于“开启这个更高安全设置”）。废弃标准库中老旧的 SSL 基础设施而支持外部模块，将比接受与原地升级相关的轻微回归风险更具用户敌意。

最后，但肯定不是最不重要的是，这种方法与创建 Python 2.8 版本的想法存在相同的问题：可能无法解决实际问题。Python 的商业再分发商旨在再分发 **Python** 和一组预先存在的附加包。将新包添加到预先存在的集合**可以**做到，但这需要逐一联系每个再分发商，并要求他们相应地更新其重新打包过程。相比之下，本 PEP 中描述的方法将要求再分发商通过故意降级所提供的网络安全基础设施来故意**选择退出**安全增强功能，而他们中的大多数不太可能这样做。

被拒绝的变体：提供“传统 SSL 基础设施”分支

本 PEP 的早期版本包括了 2.7-legacy-ssl 分支的概念，该分支保留了 Python 2.7.6 网络安全基础设施的确切功能集。

在我看来，任何实际想要这样做的人几乎肯定犯了一个错误，如果他们坚持在特定情况下确实想要这样做，他们可以自己制作，或者安排下游分销商为他们制作。

如果它们公开发布，任何此类重建都应被称为“带有传统 SSL 的 Python 2.7”，以与包含最新网络安全基础设施的官方 Python 2.7 版本明确区分。

在本 PEP 实施的第一个 Python 2.7 维护版本之后，也将 Python 2.7.6 及更早的版本称为“带有传统 SSL 的 Python 2.7”。

被拒绝的变体：将特定模块与 Python 3 完全同步

本 PEP 的早期版本建议将 hmac、hashlib 和 ssl 模块与其 Python 3 对应模块完全同步。

这种方法被证明过于模糊，无法为例外情况建立令人信服的理由，因此已被当前更明确的提案取代。

被拒绝的变体：开放式回溯策略

本 PEP 的早期版本建议对未来影响互联网整体安全的 Python 3 增强功能进行一般性策略更改。

该方法造成了不必要的S不确定性，因此已简化为提出回溯一组具体的特定更改。未来的功能回溯提案可以参考本 PEP 作为先例，但仍需为 Python 2.7 长期支持版本中的每个功能添加提出具体案例。