Unbound与OpenSSL 3.0兼容性问题解析

在构建Unbound 1.20.0版本时，当系统安装了OpenSSL 3.0及以上版本且编译时启用了OPENSSL_NO_DEPRECATED选项时，配置阶段会出现构建失败的问题。这个问题的根源在于Unbound的配置脚本检测机制与OpenSSL 3.0的API弃用策略存在冲突。

问题背景

OpenSSL 3.0作为一个重要的版本更新，引入了许多API变更，其中就包括将ECDSA_sign和SHA384_Init等函数标记为废弃。这些函数在OpenSSL 3.0的文档中已被明确标注为不推荐使用。然而，Unbound 1.20.0的configure.ac脚本仍然会检查这些废弃函数的存在性，导致在严格模式下（OPENSSL_NO_DEPRECATED启用时）配置失败。

技术细节

问题的核心在于Unbound的自动配置脚本使用了过时的检测方法。脚本原本通过检查以下两个函数来判断EC支持：

1. ECDSA_sign - 用于ECDSA签名
2. SHA384_Init - SHA-384哈希算法的初始化函数

在OpenSSL 3.0中，这些函数已被标记为废弃，推荐使用更现代的EVP接口替代。当OpenSSL编译时启用了OPENSSL_NO_DEPRECATED选项，这些废弃函数将不会被定义，从而导致配置失败。

解决方案

项目维护者已经修复了这个问题，改进后的检测机制现在会：

1. 首先检查OPENSSL_NO_EC宏定义，这是OpenSSL中检测EC支持的新方法
2. 如果检测到较新的EVP_PKEY_fromdata函数存在，则使用新的API路径
3. 同时保留了旧版API的兼容性检测路径

这种双重检测机制确保了Unbound能够在各种OpenSSL版本上正常工作，无论是使用传统API的系统还是严格遵循OpenSSL 3.0新规范的环境。

影响范围

值得注意的是，这个问题在大多数Linux发行版中可能不会出现，因为发行版维护的OpenSSL软件包通常不会启用OPENSSL_NO_DEPRECATED编译选项。这个问题主要影响那些自行编译OpenSSL并启用严格废弃API检查的用户环境。

总结

这个问题的修复展示了开源项目如何适应基础库的重大API变更。通过实现双重检测机制，Unbound既保持了与旧系统的兼容性，又支持了OpenSSL 3.0的新特性。对于开发者而言，这个案例也提醒我们在依赖第三方库时需要考虑API的长期稳定性和兼容性策略。