OpenSSL 1.1 API 的迁移问题

很多人都知道，openssl 1.1.0版本有意介绍了从以前的版本引入了重大的api更改，以前公开可见的大量数据结构已经变得不透明，添加了访问器函数以获取和设置这些现在不透明结构中的一些字段。值得注意的是，使用不透明数据结构对库通常是有益的，因为可以改变这些数据结构而不破坏abi。因此，这些变化的总体方向在很大程度上是合理的。

然而，虽然api更改通常是进展所必需的，但openssl似乎没有转换计划，完全忽视了这些更改对整个开源生态系统的影响。

目前来看唯一可接受的方案是把重任转接给每个使用openssl 的软件项目中：在依然兼容以前api的情况下推进每个项目中把核心代码迁移为openssl 1.1 ，同时保持与先前api的兼容性（例如php-src和openssh-portable）。这迫使每个项目提供自己的向后兼容性，肯定会引发一些问题，引入潜在的安全问题或内存泄漏。

由于许多因素，使用openssl的软件项目不能简单地迁移到1.1 api，并且不再支持1.0 api ——在大多数情况下，他们需要继续支持这两者。首先，我不知道有任何平台已经发布openssl 1.1版本 —— 任何支持openssl 1.1的软件，没有平台可以使用。其次，openssl 1.0.2版本支持到2019年12月31日，而openssl 1.1.0只支持到2018年8月31日——显然任何lts风格版本都会考虑使用1.0.2。

尝试与openssl 1.1 协同工作的平台已经遭遇了明显的挑战 ：例如，目前debian518个中就有257个包不是针对openssl 1.1 构建的。同时还存在隐藏一些问题，类似不同的类库基于不同的openssl 版本但却贡献openssl 数据结构的场景，这些问题都很难被察觉。因为他们只会在运行时出现。

但是，openssl（仍然有）至少两个选项可以避免这种情况，使得软件项目从旧的api平滑过渡到新的api，而不是每个单独的项目都必须向后兼容至少三年（实际更长）。

我恳求openssl项目认真重新考虑他们的api改变的方法，更重要的是相关的迁移，尤其是记住什么是最好的整体生态系统，而不仅仅是openssl项目。我还要求使用openssl的软件项目仔细考虑他们如何处理这种情况，特别是考虑他们需要多长时间携带兼容性代码和#ifs。

最后我想说的是，这不是libressl的问题 —— 如果我们添加所有的openssl 1.1访问器，为openssl 1.0或openssl 1.1编写的软件将可以与libressl无缝工作。但无论如何，软件仍然必须保持与两个openssl api的兼容性。