很多人都知道,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的兼容性。