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