The author of this latest advertorial, Kevin Roose, has a podcast called “Hard Fork”.

Here he and his co-host attempt to answer the question “What’s a Hard Fork?”:

kevin roose: Casey, we should probably explain why our podcast is called “Hard Fork.”

casey newton: Oh, yeah. So our other names didn’t get approved by “The New York Times” lawyers.

kevin roose: True.

casey newton: And B, it’s actually a good name for what we’re going to be talking about. A “hard fork” is a programming term for when you’re building something, but it gets really screwed up. So you take the entire thing, break it, and start over.

kevin roose: Right.

casey newton: And that’s a little bit what it feels like right now in the tech industry. These companies that you and I have been writing about for the past decade, like Facebook, and Google, and Amazon, they’re all kind of struggling to stay relevant.

kevin roose: Yeah. We’ve noticed a lot of the energy and money in Silicon Valley is shifting to totally new ideas — crypto, the metaverse, AI. It feels like a real turning point when the old things are going away and interesting new ones are coming in to replace them.

casey newton: And all this is happening so fast, and some of it’s so strange. I just feel like I’m texting you constantly, “What is happening? What is this story? Explain this to me. Talk with me about this, because I feel like I’m going insane.”

kevin roose: And so we’re going to try to help each other feel a little bit less insane. We’re going to talk about these stories. We’re going to bring in other journalists, newsmakers, whoever else is involved in building this future, to explain to us what’s changing and why it all matters.

casey newton: So listen to Hard Fork. It comes out every Friday starting October 7.

kevin roose: Wherever you get your podcasts.

This is simply not accurate.

Today the term “hard fork” is probably most often used to refer to blockchain forks, which I assume is where these guys (almost) learned it, but the blockchain people borrowed the term from forks in software development.

In both cases it means to diverge in such a way that re-converging is not expected. In neither case does it mean anything is screwed up, nor does it mean anything about starting over.

These people who’s job it is to cover technology at one of the most respected newspapers in the United States are actually so clueless that they have an entirely wrong definition for the phrase which they chose to be the title of their podcast.

“Talk with me about this, because I feel like I’m going insane.”

But, who cares, right? “Hard fork” sounds cool and the times is ON IT.

They’ll fight against Border Patrol, and even plot to kill them sometimes, but only when they think they aren’t doing enough.

https://www.bbc.com/news/world-us-canada-48029360

https://time.com/6141322/border-vigilantes-militias-us-mexico-immigrants/

https://www.newsnationnow.com/us-news/immigration/border-coverage/militia-convicted-border-patrol-agents/

https://www.wired.com/story/border-militias-immigrants-trump/

https://www.texastribune.org/2024/02/07/border-el-paso-fbi-investigation/

The only three CVEs in their changelog are from 2007, 2010, and 2014, and none are specific to claws.

Does that mean they haven’t had any exploitable bugs? That seems extremely unlikely for a program written in C with the complexity that being an email client requires.

All of the recent changelog entries which sound like possibly-security-relevant bugs have seven-digit numbers prefixed with “CID”, whereas the other bugs have four-digit bug numbers corresponding to entries in their bugzilla.

After a few minutes of searching, I have failed to figure out what “CID” means, or indeed to find any reference to these numbers outside of claws commit messages and release announcements. In any case, from the types of bugs which have these numbers instead of bugzilla entries, it seems to be the designation they are using for security bugs.

The effect of failing to register CVEs and issue security advisories is that downstream distributors of claws (such as the Linux distributions which the project’s website recommends installing it from) do not patch these issues.

For instance, claws is included in Debian stable and three currently-supported LTS releases of Ubuntu - which are places where users could be receiving security updates if the project registered CVEs, but are not since they don’t.

Even if you get claws from a rolling release distro, or build the latest release yourself, it looks like you’d still be lagging substantially on likely-security-relevant updates: there have actually been numerous commits containing CID numbers in the month since the last release.

If the claws developers happen to read this: thanks for writing free software, but: please update your FAQ to explain these CID numbers, and start issuing security advisories and/or registering CVEs when appropriate so that your distributors will ship security updates to your users!