今天看到 curl 官方邮件列表中出现了一封公开的邮件[1]，探讨是否该把 Rust 实现的 http 后端 hyper 的支持在 curl 2024[2] 的工作任务中移除。
curl 官方在 2020 年底合并了对 hyper 作为 libcurl HTTP 功能的替代后端的初步实验性支持。然而截止到今天依然处于实验阶段，还有 15 个测试没有跑通。
最近因为 curl 的开发者对 hyper API 的理解存在误解，以及不了解如何正确地集成 HTTP/2 支持到 curl 中，所以他甚至不得不在 hyper 使用时移除对 HTTP/2 的支持。
在过去的六个月中，curl 的 hyper 代码只进行了重构和其他内部清理以及与改进保持同步的修复。没有人似乎（想要）致力于改进 curl 的 hyper 后端。而且似乎没有人使用它或关心它缺乏 HTTP/2 的支持。
在距离最初合并后的大约 40 个月后，这项工作似乎陷入了停滞。所以 curl 开发者提出了这个问题：是否该在 2024 年移除 rust 后端 hyper ？
问题的重点不在于是不是该移除 Hyper
我在去年10月份写过一篇文章《curl 0day 启示录 ｜连接破碎的旧世界与安全的新纪元》 。那天， curl 曝出了 0Day 漏洞（ CVE-2023-38545），具体漏洞细节我这篇文章里有写，就不赘述。
我今天再次提起它，是因为这个漏洞是在其存在了 1315 天之后才被发现。
“作者有足够的时间（大约 1315 天）来发现该漏洞，但为什么没有发现呢？原因很简单，开发人员基本只有他一人。他多次对代码运行了几个静态代码分析器，但是它们都没有发现这个函数中的任何问题。
重点在于，开发人员只有他一个人。
他对 Rust 也不是很熟悉，以至于用错了 Hyper 的 API 。而 Hyper 作者在其社交网络上也声称自己对 C 的经验不足，无法进一步推动这件事。
这件事之所以陷入僵局，问题就在于：没有人推动这件事。
大家都认为 curl 支持 Rust 写的 hyper 后端，对互联网来说是一件好事。可就是没有人来做这件事。
所以就有人认为，Rust 社区中「想要用 Rust 重写一切阵营」中的人，应该出来推动这件事。
还有人说，称这个机会实现一个纯 Rust 版的 curl，连名字都想好了，叫 rurl。
然而，没有收益的事情，纯爱发电，没有人去做的。光有想法有什么用。
Ferrous System 的联合创始人 Florian Gilcher 表示，愿意资助现在生态系统中想要提供维护的参与者。但他也完全不知道这需要持续多少努力才能推进这件事。
所以，问题的重点不在于是否该移除 hyper，而是如何找到愿意持续推进这件事的人。否则，光靠 curl 开发者一人的力量，也做不到持续维护。
你愿意参与推动这件事吗？
参考资料
[1]
公开的邮件: https://curl.se/mail/lib-2024-04/0021.html
[2]
curl 2024: https://github.com/curl/curl-up/wiki/2024
