告诉 HN：慢下来
6 分•作者: jacquesm•5 个月前
供应链攻击的数量以及由此造成的波及范围正在不断增加。罪魁祸首是那些不仅仅是语言，而是整个生态系统的语言，在这些生态系统中，本应“自带电池”的东西最终却堆积成庞大的库和模块，没有人愿意去审查。<p>这无法扩展。让所有潜在用户审查所有这些代码简直是自找麻烦，他们中的大多数人一开始就没有资源编写模块/库，因此他们很可能也没有资源审查他们摄取的所有内容。<p>我试着想象一下，如果 Linux 不是只有一个发行版，而是有几千个，每个发行版都可能随时变成恶意的。从长远来看，这行不通。所有这些系统只能在一个没有恶意行为者且你隐式信任来源的世界中运行。<p>请改进内容管理。下一个供应链漏洞很可能就是“大漏洞”，而且我确信，鉴于现在已经有大量的概念验证，各个国家都在努力实现这种能力。我们需要更少的发布点，更好的内容管理，以及在纳入之前进行更严格的审查，类似于 Linux 内核的做法。<p>我们不需要这种疯狂的高发布速度，以及整个堆栈每天的更新，你应该放慢速度，做好更好的质量保证。<p>可靠性来自于投入时间审查和提高理解的能力，而不是以惊人的速度发布、将你的下游用户作为质量保证，然后在出错时进行修复的能力。如果今天编写了代码，那么在明天甚至后天之前，世界都不需要它。从你的开发环境到发布的“热路径”很快，也可能会将你环境的任何妥协导出到你的发布中。如果你接受对你的代码的外部贡献，更是如此。
查看原文
The number of supply chain attacks and the blast radius as a result of these is ever increasing. The big culprits are languages that are not just languages but whole eco-systems, where stuff that should be 'batteries included' ends up in a massive stack of libraries and modules that nobody can be bothered to review.<p>This doesn't scale. Reviewing all of this code by all of the potential users is just asking for it, the bulk of them did not have the resource to write the module/library in the first place so they most likely will not have the resources to review everything they ingest.<p>I'm trying to imagine Linux with not one distribution but several thousand each of which could become malicious at the drop of a hat. In the longer term this will not work. All of these systems can only work in a world where there are no bad actors and where you implicitly trust the source.<p>Please improve curation. The next supply chain bug may well be 'the big one' and I'm pretty sure that various nation states are aiming to achieve that kind of capability now that there are ample proofs of concept out there. We need fewer points of distribution with better curation and far stricter review before inclusion, something along the lines of the Linux Kernel.<p>We do not need these crazy high release speeds with daily updates all over the stack, then you should just slow down and do better QA.<p>Reliability comes from the ability to invest the time review and increase understanding, not from the ability to release at breakneck speed, use your downstream as QA and then to fix things when you get them wrong. If it was coded today the world does not need it until tomorrow or even the day after tomorrow. Having a 'hot path' from your development environment to release that is fast also has the potential to export any compromise of your environment to your releases. More so if you accept external contributions to your code.