CentOS7下固定版pyOpenSSL 19.0.0重建venv后突发SSL属性报错

这个问题和PyPI上的包被篡改重传完全无关，核心是未锁定的传递依赖版本漂移导致的版本不兼容：

• 直接触发逻辑：你固定的pyOpenSSL==19.0.0在模块初始化阶段，会从底层依赖cryptography库读取Cryptography_HAS_TLSEXT_HOSTNAME兼容标记，用来判断当前环境是否支持TLS SNI扩展。而从cryptography 3.1版本开始，官方认定SNI支持已是编译默认选项，不再需要这个兼容标记做能力判断，直接把这个属性从库代码里移除了。目前PyPI上的cryptography最新版本早已彻底删除了这个属性，当pyOpenSSL 19.0.0尝试读取该值时，就会抛出找不到属性的报错。
• 为什么锁了pyOpenSSL版本还是踩坑：pyOpenSSL 19.0.0在发布时，对cryptography的版本约束仅设置了最低要求cryptography>=2.8，没有设置可接受的版本上限。你之前能长期正常运行的旧venv，是数年前创建的——当时pip安装依赖时，拉取的cryptography版本还是2.x/3.0阶段，这些版本还保留着被pyOpenSSL依赖的兼容属性，和pyOpenSSL 19.0.0完全适配，所以旧环境一直没有问题。
• 今天重建环境踩坑的原因：删除旧venv后重新安装依赖时，pip会根据pyOpenSSL 19.0.0的版本范围要求，直接拉取当前PyPI上最新的cryptography版本，而这个最新版本早已经移除了老版pyOpenSSL需要的兼容属性，版本不兼容直接触发报错。
• 为什么升级pyOpenSSL到20.0.0后问题立刻消失：pyOpenSSL 20.0.0的发布恰好适配了cryptography的这次API清理，移除了对Cryptography_HAS_TLSEXT_HOSTNAME属性的依赖，改为直接调用cryptography的新API判断SNI支持能力，哪怕安装最新版的cryptography，也不会出现找不到属性的问题。

• 不要只锁定直接依赖的版本，必须将全量传递依赖的版本也固定住。最稳妥的做法是在当前环境验证运行正常后，执行pip freeze > requirements.lock生成全依赖的版本快照，后续所有环境重建都直接基于这个快照文件安装，避免pip自动拉取存在兼容性问题的最新传递依赖。
• 如果不想使用全量锁文件，至少要把已知存在兼容冲突的传递依赖也写入常规依赖列表固定版本。比如针对pyOpenSSL 19.0.0的场景，需要在requirements.txt中补充写死cryptography==3.0，强制pip安装和pyOpenSSL 19.0.0适配的cryptography版本，不要放任pip拉取未经验证的最新版。
• 安装依赖时避免使用绕过版本校验的参数，比如不要在无验证场景下使用pip install <包名> --force-reinstall --no-deps这类操作，防止版本组合错乱。
• 针对CentOS 7这类旧系统搭配Python3.6的运行环境，选择依赖版本组合时要优先确认长期适配范围，不要盲目升级到过新的cryptography/pyOpenSSL版本——太新的版本可能已经放弃对CentOS7自带OpenSSL 1.0.2的兼容，安装时会出现编译失败、SSL握手异常等其他问题。

内容的提问来源于stack exchange，提问作者Michael Soulier