采访 Jan David Nose | Rust 博客
在内容团队，我们在美国华盛顿州西雅图举办的 RustConf 2025 上首次进行了旋风式的亮相。在那里，我们有机会与大家讨论项目及更广泛社区中正在发生的趣事。
Jan David Nose，基础设施团队
在这次采访中，Xander Cesari 与 Jan David Nose 进行了对话。Jan David Nose 当时是基础设施团队的一名全职工程师之一，该团队负责维护和开发 Rust 语言本身开发和部署所依赖的基础设施——包括 CI/CD 工具和 crates.io。 鉴于近期发生的软件供应链攻击事件，我们几周前加速发布了这段视频，但采访是在其他语言和生态系统出现软件包被攻破的消息之前进行的。
采访实录
Xander Cesari: 大家好，我是 Rust 项目内容团队的 Xander Cesari，在西雅图 RustConf 2025 的最后一天最后一小时进行录制。这是漫长而精彩的两天。我现在和 Rust 项目基础设施团队的一名成员坐在一起，他们是 Rust 语言的无名英雄。介绍一下你自己以及你是如何参与进来的？
Jan David Nose: 好的，当然。我是 JD。Jan David 是全名，但在国际场合，我通常就用 JD。过去三年我一直是 Rust 基金会的全职员工，基本上可以说我中了大奖，能够全职从事开源工作，并且我一直都在 Rust 项目的基础设施团队。过去两年，我和 Jake 一起领导这个团队。所以，基础设施团队是让 Rust 得以实现的关键，它包含许多不同的部分。
Xander Cesari: 能否概述一下基础设施团队的职责？
Jan David Nose: 当然。我认为从高层次来看，我们是从服务两组不同人群的角度来思考的。一方面，我们有语言的用户；另一方面，我们努力为语言的维护者提供良好的工具。
从维护者方面开始，这确实涉及到 Rust 是如何构建的一切。从有人做出贡献或提交 PR 的那一刻起，我们就维护着持续集成系统，确保 PR 确实有效。幕后有很多机器人和工具在帮助维持一个良好的现状、一个合理的状态。很多小东西，比如 GitHub 上的分类工具，用于设置标签、提醒相关人员等等。这些大体上都是由基础设施团队管理的。
然后在用户方面，我们有很多……或者说最重要的两件事是确保用户能够实际下载 Rust。我们不开发 crates.io，但我们支持实际向用户交付 crate 的基础设施。所有的下载都经过我们提供的内容分发网络。Rust 版本发布也是如此。所以，如果我工作没做好（这种情况发生过），可能会导致 crates.io 全球范围的中断，没人能下载东西。但这就是我们运行和运营的两大类服务。
Xander Cesari: 明白了。那么在维护者方面，GitHub 上的 Rust 组织是一个大型组织，活动很多，代码很多。显然，GitHub 上有很多大型代码库在开发，但在 GitHub 上开发像 Rust 这样规模的语言并不多见。相比于开发其他软件项目，开发一门语言及其所需工具是否面临独特的挑战？
Jan David Nose: 我能想到几件事，这些事与语言本身关系不大，而与 Rust 生命周期早期做出的一些架构决策有关。其中一件事实际上给 GitHub 带来了很多麻烦（当他们向我们抱怨时，对我们也是如此），那就是在很长很长一段时间里，crates.io 的索引是 GitHub 上的一个 Git 仓库。随着 Rust 开始发展，该仓库的活动变得如此之大，以至于实际上造成了一些问题——我会以友好的方式说——对 GitHub 来说，仅仅这一个仓库消耗的资源量就造成了问题。这后来开启了向基于 web、基于 HTTP 的索引转移的工作。这肯定是一个我们看到 Rust 与平台有些“角力”，平台提供商也与我们“角力”的领域。
对于 Rust 本身，我认为特别是在 CI 方面，我们真的希望确保 Rust 在我们支持的所有目标和所有平台上都能良好运行。这意味着我们有一个极其广泛的 CI 流水线，对于每个 Tier 1 目标，我们都希望运行所有测试，构建发布产物，并将所有内容上传到 S3。对于 Tier 2 目标，我们希望在合理范围内尽可能多地做，在较小程度上，甚至可能测试一些 Tier 3 目标上的东西。这已经变成了一个巨大的构建流水线。Marco 今天做了一个关于我们过去一年在 CI 方面所做工作的演讲。为准备这次演讲而进行研究得出的一个数字是，我们每月累计超过三百万构建分钟，这大约是每月六年的 CPU 时间。
特别是在开源项目方面，我认为从这个意义上说，我们是 GitHub Actions 的最大用户之一。不是总体最大的；肯定有更大的商业项目。但对我们来说，管理这是一个独特的挑战，因为我们希望尽可能好地为社区提供服务，并确保我们交付的产品是高质量的。这在扩展方面带来了巨大的成本。随着 Rust 越来越受欢迎，我们希望支持越来越多的平台，这个问题只会持续增长。
我们可能永远不会移除很多目标，所以这是一个有趣的挑战需要思考。如果现在已经很大了，5年、10年、15年后会是什么样子？我们如何确保能够维持我们希望交付的质量水平？当你在 CI 流水线中为某个目标构建和运行时，其中一些 Tier 1 目标你可以直接要求云服务提供商给你一个在该硬件上运行的虚拟机，但有些目标可能不是你能在云中直接运行的东西。
Xander Cesari: 是不是有某个 HIL（硬件在环）实验室？
Jan David Nose: 你触及了一个我们几乎正在进行的对话。到目前为止，作为我们目标层级政策的一部分，有一个条款说它需要能够在 CI 中运行。这意味着我们必须非常挑剔，只将那些我们能够实际运行和测试的目标提升到 Tier 1。对于所有这些，我们都有一个前提条件，即它能在 GitHub Actions 上运行。到目前为止，我们使用的非 GitHub 原生支持或提供的硬件非常少。
但这正是随着 Rust 日益流行而出现的问题。我们刚刚收到了支持 IBM 平台和 RISC-V 的请求，而这些在 GitHub 上并不原生支持。这引发了一场关于我们如何支持这些的内部讨论。作为一个项目，我们如何让能够提供硬件供我们测试的公司参与进来？这有什么影响？
一方面，存在有趣的限制和考量。例如，你肯定不希望你的 PR 因为别人的硬件不可用而随机失败。我们每天能合并的 PR 数量已经资源紧张，给这个过程增加噪音真的会减慢对 Rust 的贡献。另一方面，还有安全影响。特别是如果我们讨论将某个目标提升到 Tier 1，并且我们希望在该硬件上构建发布产物，我们需要确保这些硬件实际上是安全的，没有人能在 Rust 编译器的 RISC-V 目标中植入后门。
所以我们面临着有趣的挑战，特别是在我们生活的这个供应链安全成为巨大关注点的世界里。我们需要弄清楚，我们如何既能支持 Rust 的增长、语言、社区和整个生态系统的发展，同时又能确保我们交付的东西可靠、安全且高性能。这正成为一个越来越相关且有趣的课题。到目前为止，我们通过 GitHub 支持的平台应付过来了，但看到事情开始发生变化，人们主动联系我们，愿意提供硬件、提供赞助，并帮助我们在他们的平台上进行测试，这真的很酷。但本质上，我们还没有一个好的答案。我们仍在试图弄清楚这意味着什么，我们需要考虑什么，以及我们使用外部硬件的要求是什么。
Xander Cesari: 是的，每个人都对 Rust 将无处不在感到兴奋，但那里存在一个维护成本，其范围几乎是呈指数级增长的。
Jan David Nose: 这确实也很有趣，因为这里存在一种张力。以 IBM 为例，他们联系我们，就是一个有趣的例子。谁家里有 IBM 平台？那个平台的用户数量在全球范围内真的很小，但 IBM 也在 Rust 上投入了大量资金，努力促成此事，并且愿意提供硬件。
对我们来说，这引出了一系列问题。是否有界限？是否有某些要求？一个平台是否需要达到一定的使用量我们才会将其提升？还是说我们希望尽可能多地将平台提升到 Tier 1？这是我们尚未真正进行过的一场对话。只是现在随着 Rust 被更广泛地采用，以及公司投入大量资金和资源，它才开始慢慢浮现。看到这一点令人兴奋。
在这种特定情况下，公司联系基础设施团队，以弄清楚我们如何将其平台添加到 CI 中，作为迈向 Tier 1 支持的第一步。但这也是我们需要与 Rust 项目中更大部分进行的更广泛讨论。例如，对于 Tier 1 提升，编译器团队需要签字同意，基础设施团队需要签字同意。需要有更多人参与到这场关于我们如何支持整个生态系统日益增长的需求的讨论中。
Xander Cesari: 我感觉这将成为贯穿本次采访的一个主题。
Jan David Nose: 100%。
Xander Cesari: 那么，这个流水线中另一个我很久以来完全不知道的工具，我想是在另一个会议上的一次演讲让我了解了它，那就是 Crater。这是一个试图运行它在互联网上能找到的所有 Rust 代码的工具。你能谈谈这个工具是做什么的，以及它如何集成到发布流程中吗？
Jan David Nose: 每当有人在 GitHub 上创建拉取请求，为 Rust 编译器添加新功能或修复错误时，他们可以启动所谓的 Crater 运行或实验。Crater 本质上是一个大型机器集群，它试图拉取尽可能多的 crate。理想情况下，我们希望测试所有 crate，但由于各种原因，这不可能。有些 crate 就是无法可靠地构建，所以我们维护列表来排除这些。根据我的记忆，我认为我们目前测试大约 60% 的 crate。
该实验从你的拉取请求中获取代码，用它构建 Rust 编译器，然后使用该编译器构建所有这些 crate。它会报告是否存在与你提出的更改相关的任何回归。这是我们维护 Rust 新版本和新功能向后兼容性的一个非常重要的工具。它让我们可以问：如果我们将此功能添加到编译器中，生态系统是否仍然能编译？我们在哪里会遇到问题？然后，这更多是在编译器团队方面，需要决定如何进行。这种破坏可以接受吗？我们需要调整功能吗？拥有 Crater 使得这种对话成为可能，因为它为我们提供了关于对更广泛生态系统影响的真实数据。
Xander Cesari: 我认为这非常有趣，因为随着越来越多的公司采用 Rust，他们都在问这门语言是否会稳定且向后兼容。你听说过其他编程语言发生重大版本变更，导致很多戏剧性事件和代码更改。事实上，如果你的代码在 crates.io 上，编译器团队可能已经在测试其向后兼容性了，这相当令人安心。
Jan David Nose: 是的，我认为几率很高。特别是回顾整个 Python 2 到 Python 3 的迁移，我认为作为一个行业，我们从那些大的版本跳跃中学到了很多。我无法真正代表编译器团队发言，因为我不是其成员，也没有参与决策，但我觉得这就是 Rust 设计中向后兼容性如此重要的原因之一。我们希望尽可能轻松地保持最新状态，确保我们不会意外破坏语言，或制造出整个生态系统必须同时迁移的痛苦迁移点。
Xander Cesari: 你知道是否有其他组织也在拉取类似 Crater 的东西，并在他们自己的内部 crate 仓库上运行它？也许是一些大型科技公司，或其他编译器开发者，甚至其他语言？还是说这真的是 Rust 编译器团队定制的？
Jan David Nose: 我不知道有谁将 Crater 本身作为工具来运行。Crater 建立在一个沙箱框架之上，我们在其他地方也使用这个框架。例如，docs.rs 使用了一些相同的基础设施来构建所有文档。我们尽可能多地共享 Crater 中存在的功能，但我不知道有谁以与我们相同的方式使用 Crater。
Xander Cesari: 明白了。你工作的另一个重要部分是，基础设施团队既支持维护者，也支持从 crates.io 拉取依赖的 Rust 用户和消费者。听起来 crates.io 并不直接属于你的团队，但你们支持那里的很多后端。
Jan David Nose: 是的，没错。crates.io 有自己的团队，该团队维护着 Web 应用程序和 API。而 crate 本身，所有用户下载的单个文件，都托管在我们的基础设施内。基础设施团队维护着位于其前面的内容分发网络。每次 crate 的下载都会经过我们维护的基础设施。我们与 crates.io 团队在这个共享接口上密切合作。他们拥有应用程序和 API，我们确保文件能够交付给最终用户。
Xander Cesari: 那么听起来，对上传的文件有很多验证，每次有人向 crates.io 推送新版本时都会进行检查。那部分都发生在 crates.io 作为一个应用程序内部。
Jan David Nose: Cargo 使用 crates.io API 上传 crate 文件。crates.io 有很多内部逻辑来验证它是有效的，并且一切看起来都正确。对于我们基础设施团队来说，我们将其视为黑盒。crates.io 做它的工作，如果它对上传满意，就将文件存储在 S3 中。从那时起，基础设施确保文件是可访问的，可以被下载，这样人们就可以开始使用你的 crate。
Xander Cesari: 在 Rust 可以说是其自身成功的受害者这个主题下，我假设所有的流量图和下载图都是非常陡峭地向右上方增长。
Jan David Nose: 在基金会方面，我们的一位同事喜欢检查 crates.io 上达到十亿次下载需要多长时间，这个数字一直在快速下降。我不记得三年前是多少了，但已经下降了几个数量级。在我们的下载流量中，我们肯定看到了指数级增长。我们的流量往往每年翻一番，这个趋势一直相当稳定。看起来 Rust 在生态系统中的采用率确实很高，人们正在越来越多的事情上使用它。
Xander Cesari: 基础设施团队是如何随着这种增长而扩展的？你们是走在前面，还是有很多深夜加班？
Jan David Nose: 肯定有深夜加班。在我为基础设施团队工作的三年里，每年都有一个不同的主题，基本上都是需要扑灭的火灾。
情况在变化，因为我们修复了一件事，然后下一件事又出问题了。幸运的是，到目前为止，这些火灾大多是顺序发生的，而不是并行的。我加入时，带宽是大话题。过去一年，更多的是关于 CI。大约三年前，我们遇到了一个拐点，流量翻倍，而我们当时拥有的赞助能力达到了极限。
两三年前，Fastly 欢迎我们加入他们的 Fast Forward 计划，并从那时起一直赞助我们所有的带宽。这让我晚上大部分时间能睡个好觉。这是一段非常好的关系。他们一直是一个了不起的合作伙伴，在每一步都帮助我们消除了可能达到限制的恐惧。他们在整个开源社区都非常活跃；最著名的是他们还赞助 PyPI 和 Python 生态系统，与他们相比，我们只是汪洋大海中的一条小鱼。这给了我们很大的信心，相信我们能够维持这种增长，并继续以人们期望的质量水平提供 crate 和发布版本。
Xander Cesari: 从某种意义上说，Rust 在让所有这些基础设施感觉无形方面做得如此出色。你只需在终端中输入 Cargo 命令，感觉就像魔法一样。
Jan David Nose: 我对此感到非常高兴。在开源环境中运行一个基础设施团队，这是一个有趣的方面。回顾自第一个稳定版本发布以来的十年历史，甚至 Rust 真正开始以来的十五年，基础设施在大部分时间里都是由志愿者运行的。我在这里三年了，我是第一个全职基础设施工程师。所以，在十到十二年的时间里，志愿者们运行着基础设施。
对他们来说，关键是让一切正常工作，因为你不能因为服务器着火或下载停止工作而在半夜呼叫志愿者。从一开始，我们的基础设施就被设计得尽可能简单和可靠。我们的 CDN 也是如此。我总是觉得有点不好意思，因为 Fastly 是一个了不起的赞助商。每次我们在会议上见到他们，或者他们宣布新功能时，他们都会问我们是否想使用，或者谈论我们如何在生产中使用 Fastly。每次我都不得不说：我们使用的是可能的最简单配置。我们设置了一些 HTTP 头。差不多就是这样。
这是一个非常酷的平台，但我们使用最小的功能集，因为我们需要用一个主要由志愿者组成的非常小的团队来维护所有这些。我们的首要任务一直是保持简单可靠，而不是追求每一个花哨的新技术，这样项目才能保持可持续性。
Xander Cesari: 基于志愿者的组织似乎必须关心工作与生活的平衡，这可能很棒，并且那里有值得学习的经验。
Jan David Nose: 是的，这绝对是一个非常有趣的工作环境。它与公司或商业团队有不同的规则。我们必须以一种非常不同的方式思考在给定时间内我们能做多少工作，因为志愿者的时间、他们何时有空以及他们生活中发生了什么都是不可预测的。
过去几年，我们试图减少可能爆发的火灾数量。当它们确实发生时，我们试图保护志愿者免受其扰，并作为全职员工承担这些工作。这始于三年前的我。去年 Marco 加入，增加了我们的能力，因为在基础设施方面有太多事情要做，即使我全职工作，我们也根本没有足够的人手。
Xander Cesari: 所以你们是两名全职员工，其他都是志愿者。
Jan David Nose: 没错。团队大约有八个人。Marco 和我全职工作，由 Rust 基金会支付报酬，专门负责基础设施。然后我们有一些志愿者在不同的领域工作。
因为我们的责任范围很广，基础设施团队比其他团队更倾向于在“孤岛”中工作。我们有对基础设施非常具体的部分深切关注的人。否则，对任何一个人来说，要了解的东西实在太多了。这是一个非常好的组合，与团队中的人一起工作真是太棒了。
作为有幸全职从事这项工作并有时间和资源的人，我们试图承担更大的负担，并创造一个让志愿者乐于加入的空间。我们希望他们在风险较小、不太可能着火、更容易进入、完成一项工作然后离开的令人兴奋的领域工作。如果你的个人生活需要占用你两周时间，那也没关系，因为有人在那里确保服务器和灯还亮着。
这些工作更多地存在于维护者方面：GitHub 应用、帮助分类的机器人。如果那里出了问题，风险较小。在用户方面，如果你推送了错误的 DNS 设置（有人可能做过），你可能会陷入一个长达30分钟无人能下载 crate 的局面。在这种情况下，“无人”字面意思是全球没有一个用户。这不是我希望志愿者拥有的经历。压力极大，最终这也是我最初加入的原因之一——承担这种责任确实有精疲力竭的感觉。
作为全职人员，承担这种责任更容易一些。我们有更多时间和更多方法来管理压力。老实说，我对基础设施团队作为志愿者所能做到的事情感到极其惊讶。他们建立的东西，以及他们将 Rust 推到现在这个位置所付出的努力，真是令人难以置信。
Xander Cesari: 我想任何在2025年管理网络流量的人都在谈论由于 AI 或其他目的的机器人和爬虫导致的流量飙升。Rust 网络也遇到这种情况了吗？
Jan David Nose: 是的，我们肯定看到了。这由一个稍微不同的团队处理，但特别是在 docs.rs 方面，我们不时看到爬虫猛烈地攻击我们，并导致明显的服务降级。我们痛苦地意识到，当爬虫疯狂时，流量会在短时间内急剧增加。
这对我们的基础设施提出了新的挑战。我们需要弄清楚如何应对这种流量，并保护我们的服务不被那些想使用 docs.rs 查找工作所需内容的真实用户无法访问。在 CDN 方面，我们的提供商通常可以处理这种流量。更多时候是应用程序方面会受到伤害。
在 CDN 方面，我们也看到人们在爬取 crates.io，大概是为了将整个 crate 生态系统吸收进 LLM。幸运的是，在过去两年里，我们做了很多工作来确保 crates.io 作为一个应用程序较少受到这些流量高峰的影响。下载现在完全绕过 crates.io，直接进入 CDN，因此 API 不会受到这些突发流量的冲击。在过去，这看起来就像是 DDoS 攻击，来自许多来源的大量请求让我们无法处理。
我们做了很多后端工作来保持我们的技术栈可靠，但这绝对是过去一年改变了游戏规则的事情。我们可以清楚地看到爬虫比以前活跃得多。
Xander Cesari: 这说得通。我相信 Fastly 也在这方面努力。他们的业务必须适应这种新的互联网环境。
Jan David Nose: 没错。例如，我们现在正在进行的一场对话就是关于 docs.rs 的。它仍然托管在 AWS 上，位于 CloudFront 后面，但我们正在讨论将其放在 Fastly 后面，因为通过 Fastly 我们可以获得诸如机器人防护之类的功能，这有助于阻止爬虫。
这是我们的对话在过去六个月如何变化的一个很好的例子。在今年年初，我没想到这会是我们讨论的话题。我们当时专注于其他事情。对于 docs.rs，我们有一个长期计划来重建为其提供动力的基础设施，我期望我们把精力放在那里。但随着行业的变化，以及每个人都试图积累尽可能多的数据，我们的优先事项已经发生了变化。我们面临的问题以及我们解决它们的顺序已经改变了。
Xander Cesari: 而且我猜，作为一个主要由志愿者组成的团队中为数不多的带薪成员之一，你经常最终在处理“火灾”，而不是那些可能更有趣的下一项功能。
Jan David Nose: 确实如此，尽管说我只能处理“火灾”听起来有点负面。有时感觉是这样，因为就像任何技术栈一样，有很多维护开销。在基础设施方面，我们肯定要付出这种代价。
例如，Marco 今年花时间梳理了我们运行的所有服务器，对它们进行分类，并确保它们都打了补丁并使用了最新的操作系统版本。我们将 Ubuntu 机器更新到了最新的 LTS。这感觉有点像忙碌的工作——你必须做，因为它重要且必要，但这不是最令人兴奋的项目。
另一方面，当涉及到 CDN 配置、弄清楚机器人防护功能如何工作以及它们是否与我们相关时，那也是真正有趣的工作。它让我们可以试用供应商提供的新工具，并且我们正在应对整个行业面临的挑战。你如何处理这种新类型的流量？禁止机器人有什么影响？阻挡真实用户的风险有多高？有时某人只是错误配置了一个 curl 脚本，从外部看就像他们在爬取我们的网站。
所以，这是一个有趣的工作领域，弄清楚我们如何使用新功能并应对新挑战。即使对我们这些做更多“枯燥”工作的全职人员来说，这也让它保持令人兴奋。我们能够随着周围世界的变化而适应。如果说有什么是不变的，那就是变化本身。
Xander Cesari: 围绕这个主题，另一个来自头条新闻的变化是软件供应链安全，特别是 xz-utils 事件以及围绕开源安全的讨论。这多大程度上改变了你的工作环境？
Jan David Nose: xz-utils 的入侵事件很可怕。我不想称之为警钟，因为我们已经意识到供应链安全是个大问题，而且这不是第一次发生入侵事件。但它的发生方式令人非常不安。你看到一个行为者花了一年半的时间在一个开源项目中建立社会信任，然后利用这一点来引入后门。
在 Rust 的背景下思考这个问题：项目中的每个团队都在谈论我们需要更多的维护者，当前贡献者的工作量太大，以及 Rust 的增长给整个组织带来的压力。我们希望成为一个开放和受欢迎的项目，现在我们也需要引入新人。如果有人出现并说“我愿意帮忙，请让我加入”，他们坚持了一年，然后做了恶意的事情，我们将很容易受到攻击。我认为这并非 Rust 独有。这是开源固有的问题。
Xander Cesari: 是的，这与这种文化是相悖的。
Jan David Nose: 没错。所以我们正在努力思考，作为一个项目和生态系统，我们如何应对拥有时间和资源进行长期游戏的持续威胁行为者。付钱让某人在开源上全职工作一年，这是一种与我们过去担心的完全不同的威胁模型。
我过去常开玩笑说，对 crates.io 最大的威胁是我意外地拔掉了 CDN 的插头。我认为情况已经改变了。今天更大的威胁是有人设法将恶意代码插入到我们的发布版本、我们的供应链或 crates.io 本身。他们可能找到干扰我们系统的方式，而我们根本没有做好准备，作为一个主要由志愿者组成的组织，我们可能对新型攻击反应太慢。
回顾过去三年，这种转变变得非常明显，尤其是在第一年之后。流量翻倍，Rust 的使用量大幅上升，有新闻报道称 Rust 被用于 Windows 内核、Android 以及 iOS 的部分组件。突然间 Rust 无处不在。如果你想攻击“无处不在”，那么攻击 Rust 就变得很有吸引力。这无疑让我们成为了目标，并改变了游戏规则。
我非常高兴 Rust 基金会有一名专门的安全工程师，他做了很多威胁建模工作，并与我们合作处理基础设施安全。还有很多工作专门围绕着 crate 生态系统和防止通过 crate 进行供应链攻击展开。幸运的是，这不是基础设施方面必须单独解决的问题。但它正受到越来越多的关注，我认为这将是未来的重大挑战之一：一个主要由志愿者运行的项目如何应对这种迫在眉睫的威胁。
Xander Cesari: 而且是整个行业的问题。这不是 Rust 包管理器独有的问题。所有的包注册中心，从 Python 到 JavaScript 到 Nix，都在应对这个问题。是否有全行业的对话，讨论如何互相帮助并分享经验？
Jan David Nose: 是的，肯定发生了很多事情。我不得不有点微笑，因为带着很多同理心，但也有一点欣慰，我们有时会分享另一个包生态系统被攻破的消息。这提醒我们，不仅仅是我们在经历这些，有时这次是 npm。
我们确实努力保持对行业和其他生态系统中发生的事情的了解：出现了哪些新的威胁或攻击向量，其他人正在与什么作斗争。有时是安全问题；有时是可用性问题。例如，一年半前，npm 上出现了 “everything” 包，有人将 npm 上的每个包都声明为依赖，这导致索引爆炸。我们研究此类事件，并询问 crates.io 是否会遇到类似的问题，以及我们是否需要做出改变。
在安全方面，我们也密切关注其他人在做什么。在打包社区中，不同的包管理器开始更频繁地聚集在一起，以找出每个人都共有的问题。有个笑话是，我们不过是在互联网上发送文件。无论是 npm 包还是 crate，最终都是一堆 zip 中的文本文件。所以从基础设施的角度看，问题非常相似。
这些社区现在更多地讨论 PyPI 有什么问题，crates.io 有什么问题，npm 领域发生了什么。每个生态系统都看到的一件事——即使是非常成熟的生态系统——是带宽需求的大幅增加，这主要与 AI 的出现有关。例如，PyPI 发布下载图表，数据触目惊心。多年来，Python 一直保持稳定增长——略有指数级，但可以管理。然后在一两年前，你看到了一条巨大的曲棍球棒曲线。人们发现 PyPI 是他们模型的一个很好的分发系统。当时没有文件大小限制，所以你可以在那里发布预编译的 GPU 模型。
这种模式到处都在出现。它开启了一个包装生态系统携手合作的新时代，共同提出：在这个开源资金不足、流量需求不断增长的时代，我们如何共同努力为这些共同问题找到解决方案？crates.io 是这些对话的一部分。看到我们作为一个行业，在 Python、npm、Rust 等生态系统之间分享非常相似的问题，这很有趣。
Xander Cesari: 对于一个更小、更侧重于业余爱好者的社区，你可以对包管理器中允许包含什么有更宽松的规定。每个人都了解你试图做什么的精神，你可以在没有很多硬性规定和后果的情况下应付过去。Rust 世界是否需要思考关于包大小、允许的文件类型以及你被允许分发东西的方式等方面的更严格规定？
Jan David Nose: 有趣的是，我们是从相反的方向来看待这个问题的。与其他生态系统相比，我们一直有相当严格的限制。一个 crate 最多只能有大约十兆字节的大小。对于可以放入其中的文件类型也有限制。具有讽刺意味的是，这些限制帮助我们在这一时期保持了流量的可控。
与此同时，有一个合理的论点认为，这些限制可能无法满足所有 Rust 的用例。有些情况下，你可能希望在 crate 中包含预编译的东西，因为本地编译困难、耗时很长，或者依赖于没人有的模糊头文件。我不认为我们已经达到了 crates.io 包格式最终应该是什么样子的状态。
这带来了有趣的安全影响。当我们讨论预编译的二进制文件或有效载荷时，每次我们看到 curl | sh 命令时，我们脑海中都会有一个小小的声音：我能相信这个吗？同样，如果你下载一个包含你无法轻易检查的预编译二进制块的 crate，也是如此。
Rust 基金会在这方面正在进行大量的工作和研究。我的同事 Adam 在 crates.io 团队工作，他正在幕后努力回答其中的一些问题。例如：在发布 crate 之前，我们可以进行哪种安全测试以确保它们是安全的，不包含恶意有效载荷？我们如何展示这些信息？我们如何告诉发布者他们包含了不允许的文件？从用户的角度来看，当你访问 crates.io 时，你如何判断一个 crate 的维护程度和安全性如何？
这些对话正在整个生态系统中广泛进行。在基础设施方面，我们处于链条的下游。最终，我们与 crates.io 构建的任何安全扫描基础设施集成。我们不必自己做安全研究，但我们必须支持它。
仍然有很多事情需要做。尽管 Rust 已经很棒，尽管我非常喜欢使用它，但重要的是要记住，我们仍然是一个非常年轻的生态系统。Python 现在非常成熟和稳定，但它已经有超过25年的历史了。Rust 作为一门稳定的语言大约有十年历史。我们还有很多需要学习和弄清楚的地方。
Xander Cesari: Rust 生态系统是否比其他语言更早地遇到了问题？因为我们成功地成为了基础软件，Rust 被用在比其他语言更安全关键的地方，所以你不得不比其他语言的世界更早地面对这些难题？
Jan David Nose: 我认为这是真的。其他生态系统可能有更多的时间来成熟并回答这些问题。我们在一个更紧凑的时间线上运作。而且现在发生的事情也更多。开源非常成功；它无处不在。这意味着有更多地方的安全至关重要。
所以这是伴随着开源的成功，生态系统中发生的事情，以及我们所在的行业而来的。这确实意味着我们有更少的时间来弄清楚一些事情。另一方面，我们也有更少的包袱。我们有更少的技术债务和少十五年积累的历史。这让我们在某些领域处于前沿，比如一个包生态系统如何保持安全，以及一个21世纪的开源项目需要什么样的基础设施。
在这里，我真的很想提一下 Rust 基金会。他们积极支持这项工作：雇佣像 Marco 和我这样的人全职从事基础设施工作，让 Walter 和 Adam 重点专注于安全，并作为一个组织非常认真地对待供应链方面的考量。基金会也与其他生态系统合作，这样我们可以共同学习和成长，建立一个更好的行业。
在幕后，同事们不断为我们这门相对年轻的语言打开大门，这样我们就可以参与这些对话，并与其他生态系统坐在一起。这让我们能够从别人已经经历的事情中学习，同时也帮助塑造未来的方向。可持续性是其中的一个重要部分：我们如何长期资助这个项目？我们如何确保我们拥有运行基础设施和支持维护者所需的人力资源和财务资源？我确实低估了我的工作中有多少是关系管理和预算规划，确保现有额度能支撑到新的资助到来。
Xander Cesari: 大多数开核商业模式会免费赠送成本不高的部分——软件，而对随使用量增加而增加成本的部分——服务收费。在 Rust 的情况下，一切都是免费的，这对于采用来说非常棒，但这一定需要在商业方面有非常创造性的视角。
Jan David Nose: 是的，这就是不同力量向相反方向拉扯的地方。作为一个开源项目，我们希望每个人都能免费使用 Rust。我们希望有很棒的用户体验。当我们讨论下载时，我们有办法让它们便宜得多，但这可能意味着将所有内容托管在单一的地理位置。那么，包括澳大利亚在内的所有人都必须从（比如说）欧洲下载，他们的体验会变得更糟。
相反，我们希望使用更昂贵但能为 Rust 用户提供更好体验的服务。这里确实存在张力。一方面我们希望做到最好；另一方面我们需要现实一点，这需要花钱。
Xander Cesari: 我一直以为基础设施是二元的：要么有效，要么无效。但你是对的，它是一个滑块。你可以选择你想花多少钱，以及你得到什么样的服务质量。是否有新的技术出现，无论是对 Rust 基础设施团队还是对整个打包世界，来帮助解决这些安全问题？新的沙箱技术或更高级别的支持？
Jan David Nose: 很多人从不同的角度研究这个问题。内部我们已经讨论了很多，特别是在 Crater 的背景下。Crater 拉取所有这些 crate 来构建它们并从 Rust 编译器获取反馈。这意味着如果有人发布恶意代码，我们会下载并构建它。
在 Rust 中，这是一个特殊的挑战，因为构建脚本本质上可以在你的机器上做任何事情。对我们来说，这意味着我们需要强大的沙箱。我们构建了自己的沙箱框架，这样每个 crate 的构建都在一个隔离的容器中运行，这可以防止恶意代码逃逸并干扰主机系统。
我们在 Crater 中感受到了这种痛苦，但如果我们能以一种不限于 Crater 的方式解决它——如果它也能保护用户机器免受同样的漏洞——那就太理想了。基金会的 Walter 等人正在积极研究这个。我相信在 Cargo 和 crate 团队中也有对话，因为每个处理包的团队都看到了问题的不同角度。我们都必须共同努力来解决它，并且在该领域有很多有趣的工作正在进行。
Xander Cesari: 我希望会有帮助。
Jan David Nose: 我很乐观。
Xander Cesari: 我们看到了流量和其他一切的指数曲线。似乎在某些时候它必须趋于平缓。
Jan David Nose: 我们拭目以待。Rust 是一门年轻的语言。我不知道增长何时会放缓。我认为有很好的论据表明，随着采用的增长，它还会持续相当长一段时间。
参加像 RustConf 这样的会议，看到公司类型是如何随着时间变化的，这令人兴奋。我们有来自 Rivian 的关于他们如何在汽车中使用 Rust 的演讲。我们听说其他汽车制造商也在探索。Rust 正在进入越来越多的应用领域，这些领域在几年前是难以想象的，或者当时语言还不够成熟。
随着这种情况持续下去，我认为我们会看到维持我们目前指数曲线的新增长浪潮，因为我们正在进入对我们来说是新的领域。看到谁在谈论 Rust 以及他们如何使用它，有时是在你意想不到的领域，比如太空，真是令人惊讶。
我对 Rust 的未来非常乐观。随着采用率的提高，我们将看到很多关于如何使用 Rust 的有趣经验，以及人们用它构建的许多创造性想法。随着更多公司的采用，我也预计会有一波新的对生态系统的投资：公司付钱让人们全职从事 Rust 的不同部分工作，无论是在生态系统中还是在核心项目中。我很好奇未来十年会是什么样子，因为我真的不知道。
Xander Cesari: Rust 目前的状态确实有点像追到了车却不知道怎么办的狗。
Jan David Nose: 是的，我认为这是一个很好的类比。突然间，我们意识到我们没有完全思考过成功的每一个后果。看到挑战每年都在变化是很有趣的。我们不断遇到新的成长阵痛，一年前还不是问题的事情突然变成了问题，因为增长持续上升。
我们不断重建部分基础设施以跟上这种增长，我认为这不会很快停止。作为一个用户，这让我非常兴奋。随着语言和生态系统以这种速度增长，将会出现我今天无法预测的非常有趣的东西。
对于项目来说，这也意味着存在真正的挑战：资助我们需要的基础设施，寻找维护者和贡献者，创造一个人们可以在其中工作而不至于精疲力竭的健康环境。有很多工作要做，但这是一个令人兴奋的地方。
Xander Cesari: 好的，感谢你为让我能在终端中输入那些神奇的 Cargo 命令并在后台正常运行所做的一切工作。如果这次采访有什么行动号召的话，那就是如果你是一家使用 Rust 的公司，也许可以考虑捐款以支持基础设施团队继续工作。
Jan David Nose: 我们总是喜欢新的 Rust 基金会成员。特别是如果你是一家公司，这是支持我们所做工作的最佳方式之一。会员资格给了我们预算，我们可以用它来资助全职从事项目工作的人，或者填补我们基础设施赞助中的空缺，在那里我们无法免费获得服务，必须支付真金白银。
如果你不是一家公司，我们一直在寻找愿意提供帮助的人。基础设施团队有很多基于 Rust 的机器人和其他领域，人们可以相对容易地做出贡献。
Xander Cesari: 一些范围小、易于理解的机器人，你可以帮忙。
Jan David Nose: 没错。在基础设施方面有点困难，因为我们不能给人们访问我们的云基础设施的权限。有些领域，作为志愿者根本不可能做出贡献，因为你无法访问生产系统。但仍然有大量其他工作可以做。
像项目中的每个其他团队一样，我们有点人手不足。所以当你在会议上时，来找我或 Marco 聊聊。我们有工作要做。
Xander Cesari: 好的，感谢你为维持 Rust 运行所做的工作。
Jan David Nose: 我很乐意。
Xander Cesari: 太棒了。非常感谢。