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 基于的软件分发生态系统很好地处理。依赖第三方二进制依赖项也会为 pip 在其他解释器（如 PyPy）上运行时造成潜在的兼容性问题。

这个想法的另一个实际问题是 pip 本身依赖于标准库中的 ssl 支持（以及捆绑的 requests 副本提供的一些额外支持，该副本又捆绑了 backport.ssl_match_hostname），因此需要任何替换模块也捆绑在 pip 中。这不会造成任何难以克服的困难（这只是另一个需要进行供应商管理的依赖项），但这 *意味着* 又要维护 OpenSSL 的另一个副本。

这种方法也存在着所有其他“通过重命名事物来提高安全性”方法的相同缺陷：它们完全忽略了最需要帮助的用户，并且在基础设施支持的情况下，对鼓励用户做正确的事情设置了重大障碍（因为“使用另一个模块”比“打开这个更高安全性的设置”的影响大得多）。弃用标准库中陈旧的 SSL 基础设施，转而使用外部模块，将比接受在原地升级带来的略微增加的回归风险更加不利于用户。

最后，但同样重要的是，这种方法也存在着与进行 Python 2.8 版本发布的想法相同的缺陷：很可能无法解决实际问题。Python 的商业重新分发者被设置为重新分发 *Python* 和一组预先存在的附加包。将新包添加到预先存在的集合中 *可以* 完成，但这意味着要联系每个重新分发者并要求他们相应地更新他们的重新打包过程。相比之下，这个 PEP 中描述的方法将要求重新分发者通过故意降低提供的网络安全基础设施来故意 *退出* 安全增强，而大多数重新分发者不太可能这样做。

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

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

在我看来，任何真正想要这个的人几乎肯定犯了一个错误，如果他们坚持说他们真的在他们特定的情况下需要它，他们可以自己创建它，或者安排下游重新分发者为他们创建它。

如果这些重建版本被公开发布，任何这样的重建版本都应该被称为“具有 Legacy SSL 的 Python 2.7”，以清楚地将其与包含更最新网络安全基础设施的官方 Python 2.7 版本区分开来。

在第一个实现这个 PEP 的 Python 2.7 维护版本发布之后，将 Python 2.7.6 及更早版本称为“具有 Legacy SSL 的 Python 2.7”也是合适的。

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

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

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

被拒绝的变体：开放式的反向移植策略

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

这种方法造成了不必要的不明确性，因此它已经被简化为建议回移植一组特定的具体变更。未来的功能回移植建议可以参考这个 PEP 作为先例，但仍然需要为 Python 2.7 长期支持版本中的每个功能添加提供具体的理由。