woodruffw

I don’t agree about the “damage being done”: there’s no evidence that a cooldown is itself harmful. The worst thing it can do to you is deliver some updates to you slower-than-instantly.

I don’t think it makes a ton of sense for individual OSS maintainers to pay companies for security. The point of cooldowns is that they’re free and they trend towards security at no logistical cost to maintainers.

(I agree that companies should pay for security products, of course. The bigger problem there is that so many security products are terrible, and supply chain products appear to be no different as a class.)

The conventional meaning of “security theater” requires performance instead of effective action. But the author doesn’t reach that meaning: they claim that cooldowns don’t universalize, which then gets misconstrued into “security theater.”

I don’t agree with either claim: I don’t think they’re security theater, and I do think they universalize, contingent on there being security parties that are incentivized to scan packages.

The latter is a big assumption, but I think it’s a win for us either way: if supply chain companies are actually capable of defending us, then we win. But if it turns out they can’t serve as the cooldown vanguard, then we have great evidence that they shouldn’t be trusted at all.

I think they mean "clear owners" as in "responsible individuals," not that the repos literally lacked people with merge approval rights.

I gave Shai Hulud as an example above. If you want precise timeline examples that demonstrate the efficacy of cooldowns, here’s some examples I collected last year[1].

(See the “Window of opportunity” column in the table.)

[1] https://blog.yossarian.net/2025/11/21/We-should-all-be-using...

To be clear, the RSA key thing isn’t really about it being a security issue — that’s a part of it, but the bigger point was that it reflects structural failure/inertia that’s commonplace in distribution packaging.

(I am not a hater of distribution packaging, either. But I typically find comparisons between it and language packaging lacking, because the two have very different trust topologies.)

Well, yeah. There’s no package police that’ll stop you from installing malware. The argument has never revolved around that; the argument is solely that cooldowns are effective if you use them, and timely detection by third parties is strong evidence of that.

I generally try not to name the companies directly, because I don’t want to give them free advertising. But you can look up e.g. the recent Shai Hulud campaign.

Just post one link of a "supply chain" problem that was prevented by any of these companies before it went into the wild and affected users.

This is not the claim being made, since cooldowns are not widely adopted at the moment.

If you google “supply chain security company” you will find various companies of various reputations vying for attention in this space.

Being unable to rotate the same weak RSA key for over a decade because it was too operationally cumbersome[1] does not strike me as “modern best practices.” I also don’t think any Linux distribution package maintainer would make a legally binding claim to have “vetted” packages: the filter is reputational, not a strong guarantee that the package is not malicious. The xz incident demonstrates that tidily: the only reason it was caught it because it was noisy; the package itself was presumed to be safe.

(This is, to be clear, fine. But we should be clear-headed about what package distribution mechanisms actually provide in terms of guarantees.)

[1] https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1461834

They are very fundamentally different solutions: the entire premise of distribution packaging is that you’re relying on some distribution maintainer’s discretion. It’s not an open index.

Fundamentally, this is a cat-and-mouse game. But I suspect that "time bomb" techniques aren't economically viable for attackers, at least not with current patterns: current attackers demonstrate "smash and grab" tendencies because they know their access is limited anyways. Attempting to wait out a cooldown exposes them to additional detection risk.

Of course, maybe the attacker profile changes over time. But that's the nature of the game.

The publishing topology is pretty fundamentally different: the entire power (and danger) of language package managers is that anybody can publish, not just a privileged few.

(This cuts both ways: I’d say that distribution package managers have learned valuable lessons about what users actually want from language package managers. Learning is a good thing.)

But if everyone will be delaying updates, won't be there less chances to catch it in time?

No: the security assumption behind cooldowns rests on security scanning parties, not on innocent users being victimized. Three days is a short cooldown, but it should be a good enough lead for scanning parties.

I'm not fully sure if it's possible to preventively scan all NPM packages or how much compute it would require.

It’s not that much data, particularly for parties that are directly financially incentivized to be the first to report malware.

I really enjoyed this article. I grew up with a small amount of a similarly uncommon (outside of religious groups) Germanic language, one that I’ve learned more of as an adult, and many of the experiences (around struggling to get people to speak it, even when they know it) ring true.

I grew up using this term, but upon encountering Louden’s work, I learned that “dialect” often functions more as an insult than a linguistically useful designation.

A shprakh iz a dyalekt mit armey un flot!

I don’t have an opinion about whether Bun is poorly coded or not. I also don’t have an opinions on it being a good project or not.

I do find these kinds of “get good” arguments tiresome, though. Our job as responsible engineers is to develop strong and safe abstractions for the next group of engineers to use. Rust is one such abstraction.

There’s a difference between having a negative reaction, which is a natural human thing, and talking out of both sides of your mouth. You can also have negative things to say (or just strong opinions) without being indecorous or unkind.

The word “fuss” doesn’t occur in the original Bun article.

I also don’t think that forking the compiler is a big fuss. Large companies do that all the time, to carry whatever patches they haven’t upstreamed yet (or can’t). It’s really not that big of a deal.

I don’t think the basic idea that Zig is less safe than a language like Rust (and therefore has different classes of “endemic” bugs) is controversial among Zig programmers.

The points they make around explicit defers are a lot more subtle than it being too many lines. Quoting:

For Zig code, when exactly should we be running the cleanup code? If we're passing the same *T to many different functions, how do we know when it's no longer accessible and can be cleaned up? How does it work when some functions need to continue to reference the memory after the function is called?

Ah yeah, I agree with you.

I don't understand how a port is a "provocation." That's a very cynical and transactional way of thinking about open source.

(As for Anthropic's motivation: only they know. But I suspect that they saw Zig's AI policy as a potentially existential risk, and moved to de-risk their position. That is a technical decision, just not one rooted in the merits of any particular language.)

I really struggle to find a plain, non-motivated reading of the Bun's post that could be fairly described as a "trashing." It's a very bland post.

I want to be very clear: I don't dislike Andrew (or Jarred). Everything I've seen about him suggests that he's a bright and motivated person, and (like a lot of people, including myself) I suspect he struggles with how is tone is read online versus IRL.

I'm not judging him as a human being. I just think the post does not accomplish his goals, unless his goal really was to write a personal attack.

Yeah, I don’t mean to detract from the serious communication issues that other ecosystems have.

(I don’t think committee/unstructured/BDFL communities do better as a rule, it’s more about the culture that’s promulgated by whoever is at the top, regardless of how many of them there are.)

I find TigerBeetle very impressive. One of the impressive (and correct) decisions it made was to use an allocate-up-front pattern, which makes certain classes of temporal memory corruption harder to write.

At the same time, TigerBeetle can do this because it’s solving a specific shape of problem that’s amenable to that allocation strategy. Binding a third-party runtime written in C++ (TMU, this is what Bun is) is a pretty differently shaped problem that doesn’t easily admit that style.

In other words, discipline isn’t always enough (although you do certainly need it). Sometimes the shape of the problem makes environmental constraints (like the kind Rust offers) important.

I honestly hope that isn’t true. I’ve interacted with some Zig projects (and some people I’d characterize as Zig evangelists, in a positive way), and my experiences with both were very good.

You haven’t answered it, and I can’t find a fair reading that would lend itself to that interpretation either. You can easily correct me by quoting the part of the Bun post that you find to be “making a big fuss.”

(Surely a relatively bland technical criticism of Zig - one that gets couched with praise - does not count as “a big fuss.”)

Where are they making a big fuss?

Are we talking about the same post? This is the one I’m talking about[1], and I can’t see where it’s claimed that Rust’s build times are better. Apologies if I’m missing it.

(The one reference I found to Rust’s compile times is them talking about how they had to split their Rust rewrite into 100 crates. A plain reading of this is the opposite of what you’re saying: they’re pointing out that Rust’s compile times are slower, but that this wasn’t an overriding negative.)

It’s marketing that is also technical writing. Most companies do this, and IMO we should prefer this over the alternative (which is corporate blogspam).

Compare Cloudflare, the Google Chrome Security blog, etc.