WordPress 贡献者在过去的 24 小时内迅速准备了一个 6.4.1 维护版本,之前出现了一个关键的错误,是由于 Requests 库的更改导致服务器上运行旧版本 cURL 的更新问题。
托管公司开始报告这个错误的广泛影响。来自丹麦最大的一家托管公司之一的 Tom Sommer 在 GitHub 上提交了一个问题,详细说明了 cURL 超时如何影响网站:
- #657 在使用 Curl 7.29.0(以及可能其他版本) 时破坏了对 https://api.wordpress.org/和许多其他站点的下载
错误:RuntimeException:获取网址'https://api.wordpress.org/core/version-check/1.7/?locale=en_US'失败:cURL 错误 28:10000 毫秒后操作超时,已接收 807 个字节,共-1 个字节。
- 这也导致了站点健康中的 REST API 错误:
REST API 响应:(http_request_failed)cURL 错误 28:10005 毫秒后操作超时,已接收 XXX 个字节,共 XXX 个字节
- 这也阻止了 WordPress 插件和核心更新,基本上是依赖 WordPress 内部 Curl 处理程序的任何东西。
这个问题成为了首要任务,因为不清楚用户如何接收更新。
「即使现在您修复了这个问题,该问题也会阻止任何将来自动升级到 6.4.1 的操作,因为它破坏了 Curl 请求,所以人们更新的唯一方式是手动更新,」 Sommer 说。 「您等待的时间越长,问题就会变得越大。」
Nexcess 报告称,数以万计的站点受到了这个错误的影响。这个问题超出了大多数用户自行修补的范围,因此托管提供商必须找出如何更新他们的客户。
「在升级到 WordPress 6.4 后,我的所有网站都被锁住了,」Javier Martín González 报告说。 「没有更新的网站正常工作。」
据报告,这个错误还导致了可能引起 Stripe API 、 WP-Admin 和性能问题。
Liquid Web/Nexcess 产品经理 Tiffany Bridge 总结了这个问题是如何出现的:
看起来像这样:
- 有人报告了一个关于入侵保护系统和 WordPress 之间互动的错误
- 然后他们提交了自己的补丁给 WordPress
- 该领域的项目负责人要求提交者编写测试,但他没有这样做
- 尽管缺乏测试,他们仍然合并了 PR
- 与此同时,如果我们运行受影响的 cURL 版本 (已确认为 7.29,可能还有其他版本),则所有托管提供商都必须自己恢复更改,以确保我们的客户仍然可以获得核心和插件更新等小事情。
WordPress 核心贡献者必须弄清楚这个错误是如何通过的,通过事后分析或其他讨论,以防止将来发生类似的大规模问题。
WordPress 6.4.1 更新了 Requests 库,从版本 2.0.8
到 2.0.9
,作为一个快速修复版本,以减轻问题。它撤销了有问题的更改。版本 6.4.1 还包括针对其他三个独立问题的修复。对于支持自动后台更新的站点,自动更新已于今晚发布。
发表回复