On Friday Oct 2, 09:35am, 333 infected exit nodes started a coordinated campaign to intercept SSH connections and gather as much unencrypted data as possible.

To give you a sense of scale, all of Tor has around 3000 exit relays, so roughly 10% were under their control.

The attackers had gained access to the servers two months earlier, in August, and quietly deployed their Ebury 1.8.3 payload (an OpenSSH backdoor and credential stealer for Linux).

The Attack

The attack appears to have had two primary goals:

1. Gather as much unencrypted mail traffic as possible
2. Intercept SSH connections (MITM)

By blocking certain ports, they made their exit nodes handle only unencrypted mail traffic. An interesting writeup by one of the victims (a veteran Tor operator) goes into great detail about that: lists.torproject.org/mailman3

In this post I'll focus on the second attack, the SSH MITM. If you happen to get a circuit that exits over one of those 333 infected exit nodes, you won't notice anything at first. Encrypted web traffic is forwarded as usual, but if you attempt an SSH connection over Port 22, you're unknowingly redirected to one of 12 SSH interception servers.

That's exactly what happened to me on Friday morning. My SSH connection got redirected, and I was greeted with this warning:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E.
Please contact your system administrator.

But if you ignore the warning and go ahead with the login, the attacker does three things:

1. Steals your password
2. Opens a connection to your server and observes each command you type (MITM)
3. Opens a second connection to your server and infects it with Ebury

Getting them taken down

On Friday evening I contacted the Tor Project's network health team with my findings. They confirmed this was something new and got to work by contacting the affected relay operators.

"We've not seen an attack like that before."

• Tor Network Health Team

1. Fri Oct 2: Interception started.
2. Sun Oct 4: The Tor network health team made an announcement to the operators, who began shutting their exit nodes down.
3. Sun Oct 4: The relays were marked BadExit, so clients would no longer use them to exit traffic.
4. Mon Oct 5: The attackers restarted many of the relays, but since they were already flagged they could only serve as middle relays.
5. Mon Oct 5: All infected servers were shut down, partly by the operators and partly by the attackers.

In their announcement, the health team described the pattern:

"It seems the attacker is gaining access to Linux based hosts and when these machines are running non-exits they are editing the torrc file and turning them into exits to be able to carry out the SSH attack."

• Tor Network Health in the announcement

You can see the impact of those 333 exit nodes being shut down. On metrics.torproject.org a clear dip is visible on October 4th and has not recovered since.

Consider running a relay: community.torproject.org/relay/setup/

---

The technical part: how I found them

In this part I'll go into detail about how I found all the infected exit nodes.

Using exitmap, I built a simple script that did the following: it pinned an exit node, then opened an SSH connection from my server A to my server B.

• Server A checked whether it received the correct SSH fingerprint from server B.
• Server B checked whether the connection came from the pinned exit node or from one of the 12 SSH interception servers.

I ran the script against every single one of the ~3000 exit relays. Around a dozen served a fake fingerprint, and over 300 didn't intercept anything but redirected through those same interception servers. Redirecting alone was enough to confirm the exit was infected.

In some further analysis I used sshesame as a honeypot. Tricking the MITM into logging into the honeypot showed that they used paramiko (a Python SSH library) and also how they attempted to install Ebury using Perl.

> echo "U=$(id -u) S=$(command -v sudo >/dev/null 2>&1 && (sudo -n true 2>/dev/null && echo nopass || echo maybe) || echo none)"
> sudo bash -c 'echo <base64> | base64 -d | perl'

Checking for permissions first, then executing a base64-encoded command.

Open Questions

The biggest question is still how they got into all those servers in the first place. One theory is that the hosting company itself was hacked (discussed here: lists.torproject.org). But that's just a theory floating around. In truth, no one really knows.

Another is who's behind it. The use of Ebury and the broad collection of unencrypted data point to a financially motivated crime group. Though this too is just speculation.

"Given how many servers had Ebury between 2009 and 2023 (400 000!) there are most likely other compromised Tor relays out there."

• Marc-Etienne M. Léveillé (lists.torproject.org)

I also suspect they deliberately launched their attack on a Friday, hoping that no one would want to ruin their weekend by responding. All the more credit to the Tor Team for acting so quickly!

Takeaway

The lesson is the same as always: extra security is a worthwhile investment. Disable password authentication in favor of ssh keys. I for one am going to buy myself some hardware keys today. :)

"At the end of the day, relays/bridges need to be treated as highly targeted production machines."

• George (lists.torproject.org)

U.S. federal investigators pursuing the ShinyHunters hacking group that recently stole highly sensitive data from the FBI have identified executives at two different ransomware negotiation firms who maintained unusually close relations with the extortion group, KrebsOnSecurity has learned. Sources close to the investigation say one of the executives in the United States even helped ShinyHunters operate a website that pressured victims into paying a ransom.

Hackers aligned with ShinyHunters have claimed credit for dozens of major data breaches since 2019, when the group was primarily operated by cybercriminals living in France. As those original members were arrested or jailed one by one, control over the ShinyHunters brand eventually passed to “Rey,” identified last year as a teenage hacker from Amman, Jordan. According to the FBI, ShinyHunters has extorted more than $70 million from victims so far this year.

In late September, ShinyHunters hacked the FBI recruitment website fbijobs.gov and taunted the agency by threatening to publish the stolen files, which reportedly included medical and psychological records, Social Security numbers and home addresses, and information about each employee’s unit and specialization.

The FBI jobs site hack has prompted the agency to move with uncommon speed to arrest, detain and question people who had any communications with Rey or other ShinyHunters suspects. Reuters reported on October 3 that Rey had been detained by Jordanian authorities and was cooperating with the FBI.

Rey was able to assume control over the hacking group because one of its alleged senior members had just been nabbed. On the evening of September 15, 2026, authorities in the Netherlands arrested convicted hacker and ShinyHunters suspect Pepijn van der Stap. Dutch police reportedly used flash-bang grenades in an effort to stun and apprehend Van der Stap as he was logged in to various online accounts.

According to a source close to the investigation, the authorities arrested Van der Stap while he was using his Signal instant messaging account, which allowed them to read recent communications with frequent contacts — including ransomware negotiators based in Canada and the United States.

Multiple sources with knowledge of the matter told KrebsOnSecurity that Van der Stap’s messages were the key to unraveling a murder-for-hire plot that emerged immediately following his arrest. The Dutch news outlet RTL reported last month the two murders were allegedly to be committed abroad, and that there are indications Van der Stap gave the order for the attacks (there is no indication those orders were ever carried out).

On October 9, KrebsOnSecurity broke the news that the FBI arrested a 54-year-old Canadian cybersecurity executive named Edward Dubrovsky in connection with the ShinyHunters investigation. Dubrovsky, who recently published a book on handling cyber extortion that recommended always engaging with the hackers, was charged with threatening to disclose stolen or hacked data and interfering with interstate commerce through extortion, according to court records. Politico reports prosecutors have asked that Dubrovsky remain in custody pending trial, and that records related to his case remain under seal.

A source close to the investigation told KrebsOnSecurity that Van der Stap’s Signal messages showed he had frequent conversations with Mr. Dubrovsky and with at least one executive at a large U.S.-based consulting firm, and that these executives often knew the details about new ShinyHunters victims before the victims themselves had even learned of the breach.

That source shared another potentially explosive finding by federal investigators: the Dutch hacker’s chats showed Mr. Dubrovsky knew ShinyHunters had stolen highly sensitive data from FBI servers, and that he never informed the bureau of the data breach prior to ShinyHunters threatening on Twitter/X to publish the agency’s deeply personal personnel files.

SHINYWIRE

KrebsOnSecurity has learned from two sources close to the ShinyHunters probe that FBI investigators believe at least one executive at a U.S.-based consulting firm played an active role in operating the now-defunct ShinyHunters victim extortion website “shinywire[.]com.” KrebsOnSecurity is not naming the U.S. company or the suspected executive(s) for now because they have not yet been charged with a crime, but it is a prestigious firm with more than 1,000 associates.

A section of the homepage for the now-defunct Shinywire website.

The Shinywire website was active from approximately May 3, 2026 until October 16 and had entries for nearly 100 organizations hacked by ShinyHunters. Each entry urged victims to engage with the cybercrime group and discuss terms for payment. The pages also included samples of stolen files and promised those files would be published online if the victim ignored their demands.

The following screenshot shows a cached portion of the Shinywire extortion page for Intuitive Surgical, an American medical technology company that was breached in March 2026 after an employee fell for a targeted phishing email.

The Shinywire website, as indexed by urlscan.io. This listing is an extortion demand targeting Intuitive Surgical, an American medical technology company breached in March 2026 by a targeted phishing email attack that compromised an employee’s credentials.

Victim organizations that refused to engage or negotiate after seven days would find all of their stolen data published on the ShinyHunters victim shaming blog (a website that is only reachable via the anonymity network Tor).

In a story published October 15, The Globe and Mail wrote that a few months before Edward Dubrovsky was arrested by the FBI, the Canadian cybersecurity executive alleged in court documents he had become collateral damage in a campaign by a former business partner to “destroy” another industry executive.

The story noted that Dubrovsky filed the lawsuit in Ontario this year against Daniel Tobok, the former chief executive of Cypfer, a cybersecurity firm founded in Toronto with offices in the U.S., Britain, the Netherlands, the United Arab Emirates, and Mexico. The two first became business partners in 2017 and later developed Cypfer together, where Mr. Dubrovsky was a managing partner and chief operating officer. But by 2024, the two had a falling out, with Dubrovsky accusing Tobok of gradually excluding him from business matters and making “increasingly capricious business decisions.”

Mr. Tobok reportedly denied the allegations and filed a counterclaim, accusing Mr. Dubrovsky of accessing confidential information and unfairly competing with Cypfer through work at another firm called CyberSteward Inc. He also said Mr. Dubrovsky has misrepresented himself as a Cypfer founder, and is not a shareholder.

GHOSTBYTE

According to interviews with several former colleagues of Mr. Tobok, as far back as eight years ago he was known to ransomware purveyors by a particular nickname: Ghostbyte. In 2018, a Canadian company was hacked by Dharma, a prolific Russian-language ransomware affiliate program that first surfaced in 2016. The victim company told the Dharma ransomware representative they were leaning toward paying because some of the files were unrecoverable after being locked, but that they needed a better guarantee that Dharma would keep their word if paid.

A redacted copy of the Dharma rep’s reply is pictured below, and it shows the ransomware group urged the victim to contact a person at a Canadian IT firm that helps companies seeking such guarantees. The Dharma rep recommended the victim contact the email address ghostbyte@tutanota.com.

“If you want guarantees, you can write to the IT company,” the Dharma reply advised. “Take the phone and negotiate with them. This IT company often solves such problems in Canada. You can contact them and sign a contract for services. You’ll still have to pay.”

An email reply from the Dharma ransomware group to a victim, recommending they contact an email address that is connected to Mr. Tobok.

It’s unclear if Mr. Tobok ever used that Ghostbyte address offered by the Dharma representative, and he has not responded to multiple requests for comment. However, the breach tracking service Constella Intelligence finds an email address Mr. Tobok has frequently used — dtobok@me.com — is associated with two online accounts where the chosen username was “ghostbyte,” including a Snapchat account.

Incidentally, Constella also finds the Dharma rep’s email address luckygoodlucky@tuta.io is associated with a cryptocurrency address that processed 38 transactions totaling 43 bitcoin, ~$3.5 million at today’s value (the most recent transaction for this wallet is dated February 2019).

In a statement shared on October 14, Cypfer said the company’s business does not include making or facilitating ransomware payments, and that Cypfer learned of Dubrovsky’s arrest when the news first broke in the media.

“We had no prior knowledge of Mr. Dubrovsky’s arrest,” a spokesperson told KrebsOnSecurity via email. “CYPFER has not received any outreach from law enforcement and, to our knowledge, is not the target of any law enforcement investigation.”

The statement said CyberSteward and Cypfer are separate companies with no officers, directors or employees in common, and that Cypfer was recently acquired by the Apros Group, a holding company led by Jason Hogg, a former FBI special agent and former CEO of Aon Cyber Solutions Group. In 2020, Aon aquired Cytelligence, a security consulting firm where Mr. Tobok was founder and CEO and Mr. Dubrovsky was a managing partner.

CONFLICTING INTERESTS

It is not illegal in the United States to pay hackers for an encryption key to unlock servers infected with ransomware, or in exchange for a promise to delete any stolen files and refrain from publishing them online. While victim organizations can land in legal hot water if they pay a ransom to a group that is sanctioned by the U.S. Treasury Department, ShinyHunters is not among the ransomware groups currently sanctioned by the United States or by any other government.

Experts say ransomware victims are typically directed by their insurance provider to work with a specific incident response firm. But not all cyber forensics and breach response companies will agree to facilitate payments to ransomware groups on behalf of their clients. As a result, once victim firms make a decision to pay, the firms that eschew rewarding extortionists are invariably replaced by companies that have no such qualms.

In December 2024, ShinyHunters began extorting the education technology company PowerSchool, stealing private information on 62 million students and 9.5 million teachers in the U.S. and Canada. PowerSchool reportedly paid a $2.85 million ransom demand, and a “frequently asked questions” statement (PDF) about the breach says PowerSchool was assisted in that effort by CyberSteward (ShinyHunters affiliate Matthew Lane, 20, of Sterling, Mass., was sentenced in November 2025 to four years in prison for his admitted role in the PowerSchool hack).

But that ransom payment did not stop future extortion attempts using the same stolen data. By May 2025, individual school districts were reportedly receiving separate ransom demands using samples of the same stolen files. While nobody has alleged ShinyHunters was behind the second wave of extortion against PowerSchool users, the incident drives home the reality that there is no technical way to verify the threat actors have deleted the stolen data as promised, or prevent others from abusing the same records.

A number of leading cyber incident response firms, including Coveware and Unit 221B, have consistently warned victims against paying ShinyHunters, noting that “destroyed” victim data is often kept, resold or used to extort the company’s clients directly later on.

The FBI echoed those sentiments in an alert on May 15, 2026 advising victims against paying the ShinyHunters group. Meanwhile, ShinyHunters members have been harassing and threatening employees at Coveware and Unit 221B for offering this advice.

The following screenshots show just how annoyed the ShinyHunters leaders were with Coveware’s relentless advice against paying the group. The first image is from a conversation on May 6, 2026 that took place between the group’s main account on Telegram and a co-conspirator. In that chat, snippets of which were shared with KrebsOnSecurity by a trusted source, ShinyHunters complained that Coveware was harming the group’s payment rates.

The operator of the ShinyHunters account on Telegram speaking privately with a co-conspirator and complaining that Coveware was harming their business.

“Go on my website, majority of those companies would’ve paid if it weren’t for Coveware giving them misinformation,” the ShinyHunters account wrote. “Someone (100% Coveware) is going out of their way to make sure i am not paid.”

In another conversation on April 11, 2026, the ShinyHunters Telegram account privately said they were trying to “eliminate the problem,” which they said was Coveware. Coveware declined to comment for this story.

“I’m sure the company will pay but in this specific case I am aware of Coveware and their involvement, and I’ve probably been not getting a lot of other negotiations mostly likely because Coveware keeps getting involved,” the ShinyHunters account bemoaned.

The operator of the ShinyHunters account on Telegram telling a co-conspirator they were “trying to eliminate the problem,” which they identified as Coveware advising victims not to pay the cybercrime group.

Mark Camillo is chief executive at CyberAcuView, an industry group founded in 2021 by a consortium of major cyber insurance carriers. Camillo said some firms charge a flat retainer fee, while those that specialize in helping companies negotiate a ransom payment tend to charge a percentage of the total ransom amount paid.

That latter dynamic, he said, is an inherent conflict of interest, as the negotiator has every incentive to make things more favorable to the attackers because they are financially incentivized to negotiate and pay out, and to not negotiate down on the price.

“It has come to the industry’s attention that many of the ransomware payers charge a percentage of the final payment which may or may not be disclosed,” Camillo said. “This makes no sense if they are also the negotiator. There needs to be more transparency in the process as no one in the ecosystem should be profiting purely on the size of the ransomware transaction or payment itself.”

Camillo said the firms doing this work would argue the fees are needed because there may be unexpectedly higher costs to secure larger quantities of cryptocurrency or more risk carrying the float, and because cryptocurrency exchanges may charge higher fees for high risk transactions.

“There definitely needs to be more visibility around the transaction and clarity on the increasing value of the crypto and the exchange’s percent in the transaction to get to the bottom of this and remove any misaligned incentives,” he said.

In recent months, the U.S. Department of Justice has prosecuted a number of ransomware negotiators alleged to have conspired with cybercriminals to defraud their clients. On October 7, the DOJ charged MonsterCloud CEO Zohar Pinhasi, 50, with wire fraud and conspiracy for allegedly charging customers to remediate ransomware attacks without paying the hackers. According to charging documents, Pinhasi secretly went behind his customers’ backs and paid hackers anyway, paying ransomware groups $8 million while charging customers $19 million.

In July, Angelo Martino, a 41-year-old ransomware negotiator from Land O’Lakes, Florida, was sentenced to 70 months in prison for conspiring with the Blackcat/ALPHV ransomware group to extort multiple victims. According to the DOJ, Martino was paid by BlackCat attackers to provide confidential information about the negotiating position and strategy of his employer’s clients and enable the ransomware actors to maximize the ransoms paid by the victims.

Cloudflare and VoidZero are now working with Max Schwenk of Owner.com on tsrs, a Rust port of the TypeScript compiler. We are doing this work in close collaboration with the TypeScript team, and incubating tsrs as part of the Oxc JavaScript compiler toolchain.

Our goal is to help developers spend less time waiting for their code to be checked and more time building. Making TypeScript faster and more memory-efficient also helps bring complete development environments to more places, including right in your browser.

To be clear, we are not forking TypeScript. We believe the TypeScript team should remain in full control of the language’s design and direction. They have maintained a long-term vision while guiding TypeScript’s adoption across the JavaScript community. We do not want to change that.

The TypeScript team can move quite fast on many things, but for some features they may spend years intentionally exploring options and making prototypes before picking the right implementation. A Rust port has to follow those decisions closely, or it will eventually fall apart and become incompatible. We have to preserve the TypeScript language strictly based on its original implementation – and the TypeScript team should remain solely responsible for deciding what that looks like.

Performance and memory improvements

Early benchmarks of our Rust port of TypeScript are promising: tsrs is up to 8x faster and uses ~70% less memory compared to TypeScript 7.0 when using the same number of type check workers:

As you can see, the next version of TypeScript already brings many performance improvements, making TypeScript 7.1 beta up to 2.5x faster than TypeScript 7.0. Some of these optimizations were upstreamed from tsrs, and we’re hoping to find more.

You may have seen recent benchmarks of different TypeScript ports with various performance claims, often due to using larger machine types and different options compared to TypeScript’s defaults. We worked with the TypeScript team to ensure the above benchmarks are comparing the same configuration.

By default, tsrs ships with an adaptive configuration dependent on the machine type that uses more memory but is even faster:

Try tsrs

TypeScript in Rust aims to be a faithful port of TypeScript. You can try an experimental release by installing the tsrs package from npm:

npm install tsrs
npx tsrs

Why now?

We’ve seen many attempts at porting TypeScript to other languages over the years. Because of the complexity involved, only one of the ports succeeded: the TypeScript team’s port of TypeScript from JavaScript to Go.

However, frontier AI models can now do large-scale ports almost independently in a matter of days. We have now seen slopforks, faithful ports, and completely re-architected versions of TypeScript in Rust or C++. There is clearly a demand for even faster TypeScript.

Why Rust?

You might be thinking: “TypeScript’s Go port already made TypeScript 10x faster and far more memory efficient than the previous version written in TypeScript. Why isn’t that enough?”

However, it’s not just about speed. Rust offers some unique advantages: running in WebAssembly. The Rust + Wasm story has always been strong, and one of the reasons comes down to the fundamentals of Rust’s language design. When you compile a Go program to Wasm, you have to compile Go’s garbage collector along with it. But Rust’s memory management model enables straightforward memory interactions between a WebAssembly guest and host. This is one of the key things that makes Rust a much better fit for the WebAssembly use-case: memory efficiency.

Cloudflare Workers have supported Wasm for a long time. Just a few weeks ago we announced supporting native Rust in Workers with the new Emscripten target for wasm-bindgen. When you run entire software build and deployment systems in tight loops on Workers, the benefits of a small memory footprint pay off quickly. It means you can run these workloads so efficiently that it’s now possible to run fully encapsulated development systems in places where they couldn’t have been run before.

This enables new possibilities when combined with agents: You are now able to run a development toolchain end-to-end in a fully sandboxed environment on Cloudflare. But with Wasm, you can also run those environments safely client-side in your browser, or on an embedded device, or an IoT application.

How will the tsrs port be maintained?

First, we are working with Theo Browne to merge tsc-rs and tsrs into a single package that supports all of TypeScript’s features including Language Server Protocol (LSP) and content mappers. Second, we’ve seen a lot of success with how we maintain Vinext in sync with its upstream, Next.js. We explained how we do this in a recent blog post:

Each morning, an agent reviews the changes, fetches diffs, and opens tracking issues for anything that could affect Vinext. Every night, the compatibility matrix is regenerated as we run the Next.js test suite against Vinext. When one of these tests or issues reveals a gap, agents are now in the position where they can identify the change across both codebases, build a reproduction, port any relevant tests, and propose a fix.

We will apply the same process to TypeScript, taking extreme care that we don’t introduce diverging behaviors from upstream TypeScript. When we come across performance improvements, we’ll attempt to contribute them back to the TypeScript Go codebase so everyone wins.

Finally, we recognize that there are some differences to the upstream version of TypeScript right now, like for example the order in which diagnostics are printed. We aim to reduce those differences to a minimum by the time we publish a stable release.

What’s next?

Cloudflare is already the home of many free and open source Rust tools that power the JavaScript ecosystem, such as Vite, Rolldown, Oxlint, and Oxfmt. With more than 10 million developers building on Cloudflare, we care a lot about making the underlying developer toolchain faster, more portable, and easier to run in more places. We are excited to experiment with deeper tsrs integrations into our stack, for example for type-aware lint rules in Oxlint.

Like with Vinext, our goal is to run tsrs as a well-maintained healthy open source project — without getting in the way of TypeScript itself. The Oxc team has already begun refactoring the codebase to make it faster, use less memory, and make it maintainable. We know the TypeScript team is taking this seriously – they are experimenting with memory and performance improvements for tsc. We are excited to collaborate with the TypeScript team and the JavaScript community to build the best and fastest implementations of TypeScript together.

You might have already noticed that 2026 seems to be a bit special year for Rust compiler. It seems like there's just a lot of stuff going on. Some things were already announced since I started writing this, but there's still a bunch more that's not as visible. I'll share some things that I personally find interesting.

To explain a bit of context, what happened this year is that multiple different initiatives are reaching final steps at the same time. In other words, 2026 is not that special with the amount of work being done, but it's a year when we see several long-term investments starting to pay dividends.

Next solver

Probably the biggest thing is the next generation trait solver. This is a reimplementation of a big part of the type system, and it has been in the works for a very long time - Almost 10 years in various forms. It fixes a bunch of soundness bugs and unblocks a lot of features and fixes for long-standing issues.

It's easy to understate how big of a deal this is for the compiler. This work resolves a major piece of technical debt that a lot of compiler developers dreamed about for years. It also frees up a bunch of people with a fresh and deep understanding of the type system to work on new things. The queue of things that get unblocked includes many common pain points of the language, even things that might seem benign or unrelated. It contains solutions to big problems in async Rust, or various limitations of impl Trait.

Polonius

Another big thing is Polonius, a new borrow checker implementation, long time in the making as well. It enables more code to compile and unblocks several related features - including (hopefully one day) internal references. The compiler impact of this is not as big as with the new solver, but it's still a pretty big deal.

Perf

My main area of interest is compiler performance, and here we have quite a few things going on. After 1-2 years of a sort of stagnation (at least in terms of results), we suddenly have a lot of things going on at once. So much so that I have a hard time remembering everything, but from the top of my head:

Parallel frontend is close to stabilization

Very old initiative that was put a few years on hiatus with many unclear blockers. The development restarted again a few years ago with a new contributor @SparrowLi, and over time a number of other people contributed to the effort.

Over the years, this turned out to be a massive can of worms. I get the feeling that almost nobody is really happy with the design. However, there doesn't seem to be a better alternative for the foreseeable future, and parallel frontend is highly desirable, so the solution ended up being just grinding through a number of annoying and hairy problems until there's nothing left.

The current project goal is driven by @petrochenkov and is getting close to stabilization.

LLVM is getting faster

LLVM 23 was unambiguous and unexpectedly large positive change in performance. For a long time, LLVM upgrades were not particularly great for rustc performance. This changed after LLVM 10 upgrade, which introduced a massive 10% regression, and @nikic, current lead developer of LLVM, called it out in his blog post, Make LLVM fast again. In the post he also introduced a system for tracking LLVM performance over time, inspired by the one we use for rustc.

Since then, LLVM started catching performance regressions earlier, and results for upgrades in rustc went from "less bad", to "somewhat mixed", to "mostly positive with caveats." The last one of those was LLVM 22, which was green on icount benchmarks, but almost universally red on wall time.

LLVM 23 is pretty much entirely positive. I don't follow LLVM development that much, but my understanding is that this is because there's now more work on actually optimizing it, as opposed to working on features without trying to regress performance. These days the improvements come both from new optimizations (those help optimize the compiler during bootstrap) and from LLVM itself getting faster.

Lot perf improvements landing (micro-optimizations)

Compiler performance has been on a steady streak of improvements in the past few months. There's probably no single explanation for it, just a combination of new contributors coming in, old contributors getting to do more perf work, and tooling improvements combined with architectural cleanups unlocking new opportunities.

With more people working in this area, I've noticed a lot of cross-pollination, where a certain idea would circle around a few people's minds, as people get inspired by each other's PRs and try related things.

I also feel like we got a lot better at managing regressions - triaging and addressing them. This is partially a tooling investment, but also a lot about processes and social structures. A major development here is the connection between tree ops and perf triage, represented notably by @JonathanBrouwer.

This means that people who manage merges often directly triage their performance impact. This is important because it shrinks the response time, but the connection is useful for other reasons as well. The perf impact informs how you group PRs into rollups, for example. Turns out that Conway's law is still a law.

I also greatly enjoy helping people interpreting the measurement results and diagnose regressions. I often find that even just a few sentences from somebody who's been looking at the results every day for many years go a long way towards getting the regression addressed.

All in all, I feel like the compile time concerns are integrated into the development better than they have ever been.

Move elimination

This seemingly came out of nowhere earlier this year, and it's quite interesting. @Amanieu proposed a MIR optimization pass that allows the compiler to eliminate copies that LLVM has trouble optimizing. It speeds up both compile time and runtime.

This is one of those passes that makes sense to implement in MIR instead of LLVM, because the Rust part of the compiler has better information about whether it's valid to apply specifically for Rust. Even more so because it actually requires changing the MIR semantics a bit.

It matters for Rust in particular because Rust typically generates more moves than C(++), which is the primary LLVM target.

Polymorphization

This one is particularly close to my heart because I've been following the efforts for a very long time. Polymorphization is one of the most impactful compiler performance optimizations we could ever do, but it's unfortunately really tricky to implement.

This would be the third experiment I'm aware of. This time it's slightly different from the previous ones, and it's inspired by a similar mechanism in Swift.

The difference is that the original polymorphization intends to only avoid duplicate or redundant monomorphizations, so it's purely a compile time optimization with no runtime impact, while the Swift-style one intends to polymorphize everything and pass around layouts of generic parameters as arguments. This will have a runtime cost, so it'll be something you can tweak with compiler flags.

If my understanding is still up to date, next-solver will also enable polymorphization in the previously intended way. Either way, both options run into the same problems, so the work is useful for both. It's also possible that both options come out of this same effort. Either way, this is still just an experiment with a bunch of problems to solve, so we'll have to wait to see how it turns out. The project goal has been proposed and driven by @camelid.

cargo check and cargo build sharing cache

@blyxyas is working on a project goal, which will enable cargo to share artifacts between cargo check and cargo build. The goal is actually more general, but this is probably its most recognizable outcome. This is something we wanted for ages, so it's really cool to see progress on this front.

no-embed-metadata option enabled by default

This was already announced, and it will shrink the target directory size by 5-30%, depending on the workload.

New cargo build-dir layout

Already announced as well, this is another project that has been in the works for quite some time. As with the other things above, this is major internal restructuring that unlocks other things - namely granular locking of the target directory and cross-workspace caching.

no-link/link-only

@bjorn3 has been working on fixing support for these two flags, which enable pipelining of build scripts and proc macros. As you can see in the proposal, this is yet another line of work that boils down to fixing a laundry list of internal issues and architectural problems until suddenly a big thing is unlocked.

Architecture

There have been a number of initiatives in the compiler architecture. I'll mention a few, just to (once again) underscore the point that big things don't happen in big-bang projects coming out of nowhere, but rather as consequences of sustained long-term investments into a healthy system.

Two years ago, @jdonszelmann started the effort to unify and cleanup how attributes are represented and checked in the compiler. Just a few days ago, the last remaining attribute was ported to the new system. This significantly improves how attributes are checked and unblocks improvements to diagnostics and other things.

Earlier this year, @Zalathar and @nnethercote cleaned up the implementation of rustc's query system. This improved performance but more importantly, made the system easier to understand, which was often a blocker for making improvements to it. The system is still a pretty scary part of the codebase, but this is a big step forward.

There's actually more architectural work in this area, @oli-obk has been working on architectural groundwork for expansion-time evaluation, and there's been a lot of work by @cjgilot, @petrochenkov and other people I'm forgetting (sorry) on queries and incremental in general. Similarly, a lot of work happened to enable const generics to progress further. A common theme of these efforts is that they enable the compiler to use its capabilities in more contexts where it was previously limited, often because of strict ordering of some compilation phases.

Project goals and funding

There's quite a bit of meta stuff as well. Rust project has been experimenting with a new organizational framework called "project goals."

It went through multiple iterations with various changes and experiments, but it seems that the system has finally reached some optimal steady state, and we see the benefits play out. I think you can clearly see that from the list above.

We now have a Fast Builds roadmap and multiple perf related project goals. That's pretty exciting.

There are also multiple new developments in funding. One is explicitly attached to project goals, we also have a new "Maintainers in Residence" program, and a new funding team was established as well.

One also can't help but notice how many results came out of Hexcat employing a bunch of people in the past year.

...and me

And lastly, 2026 is also an exciting year for me. After a few years of watching from the sidelines and eventually joining the perf triage, I decided to start working on the Rust project more seriously.

Earlier this year, it became clear that I need to decide what to work on next. My current work is slowly winding down and turning into maintenance, and I also started to feel a bit burnt out on web-based work. For quite some time, I've been feeling the desire to return to something more technical and challenging.

I was considering a few options, but somewhat unable to decide between them. To use the term from Marie Kondo, nothing really felt like it "sparks joy." After some exhausting events and feeling a bit down from all of this on one evening, I received an invitation to Rust All Hands. This was a pleasant surprise. I signed up for it earlier that year, but I didn't really expect much because I didn't know the likelihood of being invited. I took this as a sort of sign from the universe or something and booked the trip.

The experience was overwhelmingly positive. I have to say that this was one of the most exciting events I attended in a long time. It reminded me that there's this big part of my life that I don't get to share with anybody almost ever, especially in real life. It seems so easy to forget that until you actually experience it again.

Yes, sure, I can talk about some curious aspects of the Rust compiler with my friends, but it's a whole another level to talk about it with people who actually work on it and understand what you talk about on a deep level. It was really nice to meet people I know from their work and join the discussions about the development of the language.

Long story short, it became clear that this is it, this is what I want to do. I was thinking about it before, but I guess I needed some strong "spark of joy" moment to stop doubting my feelings and force me to make a decision.

How to get a job on Rust?

Now, of course, the question is how to actually do it. As you may know (and I somewhat hinted above), it's not exactly straightforward to find a job on the project. There's no "Rust inc." company you can send a CV to. There's a fractured and diverse space of possibilities where everybody finds their own way somehow.

It's getting more approachable with those new programs, but I still expect this to take some time. Part of it depends on connections and trust, and those are built over time. I don't have to rush this, so I'll keep working until I figure something out.

I've agreed to work on the target directory size reduction project goal if there is enough funding for that. I've also applied for MiR program, but I don't think that'll be available soon because the funds are limited and there are more important areas that need this specific funding.

btw. I also opened GitHub sponsors, so feel free to join if you want to support some compiler performance work ;)

Conclusion

There's so much happening in the project that I feel like it's really challenging to do it justice. I already feel like I left out a ton of interesting work, but I have to stop somewhere. I hope that even this incomplete overview has been interesting.

I think I should also say that not everything has been positive. The beginning of the year was overshadowed by a bunch of people losing funding and heated discussions around AI policy. Just a few days before All Hands, somebody posted the policy draft to social media, and our small moderation team and other people spent a stressful weekend trying to limit the damage.

In light of that, I have a feeling that All Hands was a turning point where everybody could recharge, refocus, and take the positive energy back to the project. I certainly feel that, and I hope I'm not alone.

What's New

This is a partial list of new features and systems included in OpenBSD 8.0. For a comprehensive list, see the changelog leading to 8.0.

• Platforms specific improvements:

  • amd64:
    • Raised the size of amd64 kernel virtual address space from 4G to 512G.
    • pmap(9) direct map now placed at a random location.
    • Sped up swap encryption by using AES cpu instructions.
  • arm64:
    • Added hibernate support.
    • Sped up swap encryption by using AES cpu instructions.
    • Implemented bounce buffers.
  • luna88k:
    • Fixed m88k multiple CMMU register writes.
    • Extended m88k kernel-mode CMMU fault handling to handle write protection faults.
    • Ensure luna88k m8820x_initialize_cpu() initializes logical CPU #0 on non-MP kernels.
    • Faster CMMU walk in luna88k m8820x_cpu_number().
  • riscv64:
    • Detect CPU extensions and advertise those usable by userland through elf_aux_info(3) AT_HWCAP and AT_HWCAP2 queries.
    • Added kernel support for the 'V' vector extension.
    • Implemented bounce buffers.
    • Added support for RISC-V Advanced Interrupt Architecture; added imsic(4) and aplic(4) drivers.
    • Added kernel support for the Sstc timer extension.
  • sparc64:
    • Added bounds check for the sparc64 relocation flags table.
    • Switched sparc64 to LLVM toolchain.
    • Improved memory alignment on SPARCV9.
  • Other architectures:
    • Retired support for loongson architecture (not working with Clang 22).
    • Various RISC-V and MIPS bugfixes for LLVM.
    • Fixed encoding of hppa protection bits.
  • More platform specific changes can be found in the hardware support section below.

• Various kernel improvements:

  • Fixed memory size calculation in open_wmemstream(3).
  • Fixed semop(2) semaphore id being destroyed/replaced during context switch.
  • Improved inactive page queue heuristics for pagedaemon swapping pages/freeing memory.
  • Added getexecpath(3) to provide copy of the elf(5) program's execution path.
  • More preparations for larger disklabel.

• Suspend/Hibernate Support:

  • Enabled suspend/resume for qwz(4).
  • Made ufshci(4) survive a suspend on the Samsung Galaxy Book4 Edge and HONOR MagicBook Art 14 Snapdragon.
  • Stopped waking a suspended laptop when lid is closed and machdep.lidaction=0.
  • Added a global sleep mode variable to distinguish hibernate from 'normal' suspend.
  • Added suspend/resume support for qcuart(4).
  • Added support for wakeup interrupts to bytgpio(4), fixes IdeaPad resuming from suspend.
  • Validate size of chunks copied to piglet during hibernate unpacking of disk image.
  • Validate on-disk image sizes against integer overflow when reading chunks in unhibernate.
  • Prevent disk image overreads when reading the chunktable in unhibernate.
  • Clean up the framebuffer after unhibernate.
  • Made failure to allocate a dedicated queue for nvme(4) hibernate support non-fatal.

• Direct Rendering Manager and graphics drivers:

  • Updated drm(4) to Linux 6.18.53.
  • Support for Intel Arc A-Series (DG2/Alchemist) graphics cards in inteldrm(4).
  • Increased kernel virtual address space on amd64 allows mapping more than 4GB of VRAM.
  • Workaround inteldrm(4) GuC timeout errors seen on some Alder Lake systems.

• VMM/VMD improvements:

  • Added MP support for up to 64 VCPUs per guest VM.
  • Redesigned to use files to manage VM ownership.
  • Added x2apic mode support for guest virtual machines.
  • Fix for when vmd(8) does not detect kernel on startup.
  • Provide faulting GPA to vmd(8) for MMIO exits from vmm(4).
  • Refactored vmm(4) exit handling and correct RIP adjustment.
  • Added support for variable length instructions in VMX paths to vmm(4).
  • Prevent OOB reads by vmd(8) in 32 and 64-bit elf(5) loaders with malformed elf(5) files.
  • Implemented missing lapic/ioapic modes to fix vmd(8) support for 32-bit linux guests.
  • Added checksum offload for vmd(8) guests.
  • MSI/MSI-X virtio device interrupt support added.
  • Support actually split split-virtqueues in vmd(8).
  • Added i82093aa ioapic and i82489dx-compatible lapic emulation to vmd(8).
  • Improved qcow handling.

• Various new userland features:

  • netstat(1) can now print interface multicast counter; made '-q' more specific.
  • Adjusted ddb(4) default 'ps' output, print 'struct process' and 'struct proc' separately.
  • Made mount(8) support DUIDs with -u; preserve DUID when updating file system.
  • Implemented control of midithru ports with sndioctl(1).
  • Allow list elements to be added or removed by sndioctl(1).
  • Added the sndiod(8) server.mode control making the setting dynamic, changeable via sndioctl(1).

• More bugfixes and tweaks in userland:

  • Ensure elf(5) header and program header fit into the shared library when loading.
  • Fixed leak of key memory in getpwent(3) yp_next().
  • In patch(1), solved an infinite loop on malformed ed(1) script input.
  • Use execv(3) absolute-path in authpf(8), pflogd(8), ldapd(8), ldpd(8), lpd(8), radiusd(8), snmpd(8).
  • uaudio(4) now tests the reported format and channels are usable.
  • Stopped sndiod(8) aborting if a MIDI endpoint connects with non-empty buffers.
  • Fixed two missing checks of file_new() return value in sndiod(8).
  • Fixed npppd(8) LCP MRU option handing.
  • Adjust pstat(8) to return the pid of the session leader process; allow '-t -M' to work.
  • Made eigrpd(8) validate the prefixlen to avoid overflow.
  • Made sndiod(8) allocate all midithru structures on the heap.

• Improved hardware support and driver bugfixes, including:

  • Enabled the GXTP7936 touchscreen on the Samsung Galaxy Book4 Edge.
  • Added support for the riscv64 K3 PCIe/USB3 combo PHY.
  • Enabled gpioleds(4) on riscv64.
  • In smte(4) (SpacemiT K1 Ethernet device), improved error checking of received packets.
  • Fixed regular MSI interrupts on the SpacemiT K1 SoC.
  • Added support for the SpacemiT K3 SoC to smtclock(4).
  • Added SC7280 support to qcgpio(4).
  • Added support for the SpacemiT K3 dwpcie(4) PCIe controller.
  • Added RK3528 I2C5 clock, used in the Radxa E24C.
  • Added ACPI hardware IDS for Qualcomm Glymur (X2) SoC.
  • Implemented page table mirroring in apldart(4); enable IOMMU for Apple USB controllers.
  • New samsabi(4) driver for the Samsung Advanced BIOS Interface (SABI).
  • New sambat(4) driver for Samsung laptop battery monitor.
  • New rkotp(4) driver for Rockchip OTP memory.
  • Added support for the RK8600 regulator used for CPU voltage on Radxa Zero 3 boards.
  • Added more AMD "Krackan Point" device ids.
  • Fixed HONOR MagicBook Touchpad multitouch support.
  • Fixed esp(4) FIFO memory overflow.
  • Fixed potential memory leak in softraid(4) rebuild.
  • Fixed softraid(4) rebuild on disks with 4096-byte sectors.
  • Fixed high memory mbufs for 64-bit DMA capable re(4).

• New or improved network hardware support:

  • Added support for Panther Lake and Wildcat Lake Ethernet devices to em(4).
  • Added support for Intel E610 Ethernet devices to the ix(4) driver.

• Added or improved wireless network drivers:

  • Properly handle potential case of empty packets returned from qwx(4) hardware.
  • Added missing DMA syncs for qwx(4) SRNG DMA descriptor memory.
  • Properly handle qwx(4) VIF DMA map allocation failures at attach time.
  • Fixed use of stale pointers on the qwx(4) vif list which caused crashes.
  • Properly reset qwx(4) driver and device state if it fails to get RUNNING in qwx_init().
  • Avoid race condition in qwx(4) device during power-on.
  • Use the ioctl rwlock correctly in qwx(4) qwx_activate().
  • Ensure qwx(4) rx_ring->bufs_max and freemap are always initialised correctly.
  • Stopped qwx(4) init task waiting for the ioctl lock to become available.
  • Made qwx(4) properly errors which occur in qwx_qmi_fw_init_done().
  • Fixed roaming between APs with qwx(4).
  • Always allow data frame interrupts in qwx(4) while the interface is UP.
  • Added support for 40MHz channels to qwx(4).
  • Made qwx(4) only allocate a new mbuf when a free Rx ring slot is available.
  • Avoid calling bus_dmamap_create() from interrupt context in qwx(4).
  • Handle country code events sent by qwx(4) firmware to make association more reliable.
  • Reset qwx(4) command ring 'queued' counter when the command ring gets reset.
  • Ensure that qwx(4) nq flags are always cleared when switching net80211 state.
  • Fixed number of tx/rx streams set in qwx(4) mac config.
  • Made qwx(4) send the PMF good-bye deauth frame when hopping out of RUN state.
  • Ensure no new tasks get scheduled while IFF_RUNNING is in qwx_stop(). Prevents qwz(4) crash.
  • Make qwx(4) prefer ic_bss over the ephemeral node in the scan tree.
  • Add peer to qwx(4) firmware after starting the vdev, not before. Fixes a firmware crash.
  • Add 802.11n support to qwx(4). Advertise HT capabilities and pass HT/QoS peer association.
  • Ask qwx(4) firmware to move into M3 state before resetting the device.
  • Avoid calling bus_dmamap_destroy() from interrupt context in qwx(4).
  • Added 802.11n with 40MHz width to qwz(4).
  • Let qwz(4) handle QoS in native WiFi frames.

• Installer, upgrade, bootloader, and pkg-tools improvements:

  • Harmonise installurl(5) handling in pkg_add(1), sysupgrade(8), and syspatch(8).
  • Fixed free space check by fw_update(8) for unqualified filenames.
  • Set limit on the size of files fw_update(8) can download.
  • Stricter validation in fw_update(8) to no longer treat untrusted comments as data.
  • pkg_add(1) now detects and overcomes some endless loops with merge-sets.
  • Clean trailing slashes from fw_update(8) FWURL.
  • Removed current directory from default pkg_add(1) search path.
  • Improved downloading of firmware by filename in fw_update(8).
  • Improved fw_update(8) error when SHA256.sig is not found.
  • fw_update(8) now checks signature of local SHA256.sig.
  • In fw_update(8), made tar(1) skip files outside expected locations.
  • Stopped syspatch(8) downloading entire tgz file when looking for a potential update.

• Security improvements:

  • Fixed a pledge(2) in vfs(9).
  • Fixed out-of-bounds access attempts on aplmca(4) SOCs.
  • Stopped use of non-standard UID_MAX and GID_MAX in various utilities.
  • Improved ipsec(4) AES GMAC crypto.
  • Made iked(8) reject malformed and out-of-state IKEv2 messages.
  • Plugged memleak in x509_verify (CID 656293).
  • Avoid overflow in sysctl(2) KERN_PROC_ARGS.
  • Prevent bogus or malicious iaddr data from crashing dhcpd(8).
  • Avoid potential memory exhaustion via DHCPINFORM in dhcpd(8).
  • Properly use saltlen and min_saltlen in libcrypto RSA-PSS.
  • Reject invalid delta CRLs in libcrypto x509.
  • Fixed RFC 3779 inheritance handling in libcrypto's path validation.
  • Use execve(2) as $ORIGIN in ld.so(1) (otherwise fallback to realpath).
  • Hardened syspatch(8) against malicious scripts.
  • Restrict the characters that are allowed to pass through smtpd(8) environment and mda.
  • Fixed reading past the NUL by pax(1).
  • Stopped pax(1) extracting malicious archives outside the working directory.
  • Added 'mcast' to the pledge(2) for lldpd(8).
  • Tightened pledge_sockopt() level/optname checks for different types of sockets.
  • Extended the 'mcast' pledge(2) to allow multicast tweaks on Ethernet frame sockets.
  • Updated libexpat to version 2.8.4 (CVE-2026-66046 CVE-2026-76641 CVE-2026-76957).
  • Avoid script pathname TOCTOU in exec when the vnode changes.
  • Made execve(2) realpath processing more robust.
  • Switched luna88k to build kernel files with -fno-pie.
  • Unprivileged kernel memory read and write vulnerability removed from m88k 88100 data pipeline.
  • unveil(2) now restricts man(1), makewhatis(8), and man.cgi(8) read and write access.
  • dhcpleased(8) now validates the IP address the dhcp server acks.
  • Fixed signed integer overflow in perl(1) Storable (CVE-2026-57433).
  • Fixed integer overflow in perl(1) pack and unpack (CVE-2026-57432).
  • Fixed perl(1) incorrect regular expression matches (CVE-2026-13221).
  • Fixed memory leaks and race condition in profil(2).
  • Improved checking of elf(3) notes; prevent out of bounds access.
  • Reject elf(3) interpreters without loadable segments.
  • Disable kbind(2) and pinsyscalls(2) for static binaries inside exec_elf_makecmds().
  • Fixed elf(5) structs to avoid leaking kernel stack contents.
  • LibXfont 2 fixes for CVE-2026-56001, CVE-2026-56002, and CVE-2026-56003.
  • Xserver(1) fixes for CVE-2026-55999 and CVE-2026-56000.
  • Updated perl(1) Socket to 2.041 (contains fix for CVE-2026-12087, out-of-bounds heap read).
  • Fixed iked(8) to bzero(3) the mask data structure, rather than using mask4.
  • Fixes for CVE-2026-12244, CVE-2026-12245, CVE-2026-12246 and CVE-2026-12490 in nsd(8).
  • Stopped leaking transport in isakmpd(8) error paths of udp_encap_handle_message().
  • Enforce per-type ID payload size in isakmpd(8) ipsec_validate_id_information().
  • Avoid shift overflows in memmem(3) and strstr(3).
  • Multiple additional bounds checks in isakmpd(8).
  • Provide a separate executable file for syslogd(8) parent, for privilege separation.
  • Made smtpd(8) clear userinfo before sending over imsg.
  • Made smtpd(8) reject oversized sockaddr payloads received over privsep IPC.
  • Zero the temporary smtpd(8) envelope parsing buffers before use to strengthen privsep.
  • Clear pending asynchronous lookups at teardown, for stronger smtpd(8) privsep.
  • Fixed potential information leak from an uninitialised ktrace(1) stack variable.

• New features in the network stack:

  • Set ice(4) link state to full duplex.
  • Reduced maximum TSO segs in ice(4), to allow more interfaces to attach.
  • Enabled use of 128 DMA segments for TSO packets on ice(4).
  • Enabled 64-bit DMA for bge(4) BCM5720.
  • Enabled jumbo frames in ogx(4).

• Further changes and bugfixes in the network stack:

  • Stopped ipsec(4) overflowing the maximum packet size in the IP header.
  • Detect out of bound reads from an int overflow in the bpf(4) bpf_mem backends.
  • Moved bpf(4) for outgoing packets later in the transmit path.
  • Avoid leaking memory when mbuf chain allocations fail in tun(4) tun_dev_write().
  • Fixed hardmtu and rxmax in ixl(4).
  • Handle dynamic channel width changes correctly in iwx(4).
  • Hardened bpf(4) bpf_filter; block unhandled instructions with bpf_validate.
  • Added proper program bound checks to the bpf(4) engine (libpcap CVE-2026-31912).
  • Fixed bpf filter calls in ppp(4); use bpf_mfilter(9).
  • Improved imsg handling of LS_UPD, LS_FLOOD and LS_SNAP in ospfd(8).
  • Changed ospfd(8) imsg handling.
  • ospfd(8) now adds missing rtlabel references and update routes when only the label changes.
  • Preserve configured interface type on ospf6d(8) link update.
  • Ensure ospfd(8) does not leak information on memory address layout from process.
  • Made authpf(8) read_config() remove trailing white space to avoid misconfigurations.
  • Fixed veb(4) SIOCBRDGRTS and SIOCBRDGVRTS ioctls leaking kernel stack data.
  • Fixed packet corruption in veb(4).
  • veb(4) now returns ENOMEM when mallocarray() fails in veb_rule_list_get().
  • Fixed ifconfig(8) 'vebX -tagged ifX' which accepted too many arguments.
  • Improved em(4) K1 exit timeout, to receive non-broadcast packets.
  • Simplified mac type tests on em(4).

• The following changes were made to the pf(4) firewall:

  • Fixed off-by-one in pf(4) ioctl DIOCIGETIFACES.
  • Do not free the pf(4) caller's ruleset when attaching a table fails.
  • No longer allow un-terminated strings in pf(4) ioctl's.
  • Stopped pf(4) dropping valid MLD packets with unspecified source address.
  • Prevent pf(4) dropping TCP state if it receives a crafted reset packet.
  • Fixed races in pf(4) connection counters that caused connection counter underflows.
  • Fragment reassembly in pf(4)/inet(4)/inet6(4) now occurs in correct routing domain.
  • Stopped 'pfctl -s all' dumping all OS fingerprints loaded to pf(4).
  • Fixed NULL pointer dereference in pf(4) outbound packet path.
  • Fixed out-of-bounds read in pf(4) pf_rule_copyin().

• Routing daemons and other userland network programs saw the following improvements:

  • Altered smtpd(8) code to avoid false bug reports from LLM scanners.
  • Prevent size_t underflow on a malformed packets in agentx(3) and snmpd(8).
  • Widen httpd(8) server flags to 64-bit integers.
  • httpd(8) now enforces 'max request body' for chunked requests passed to fastcgi.
  • Made httpd(8) reject config of shared TLS listeners with different client CA or CRL.
  • In httpd(8) now sends one imsg fastcgi param struct per parameter, to preserve config order.
  • Added custom HTTP header support to httpd(8).
  • Fixed httpd(8) suffix range handling.
  • Stopped httpd(8) sending location fcgiparams twice.
  • Made httpd(8) drain abort response via bufferevent to prevent errors being truncated.
  • Restricted IMSG_CTL_PROCFD to parent and check process id/instance in iked(8), httpd(8), relayd(8), and snmpd(8).
  • Switched the default TLS cipher in httpd.conf(5) set from 'compat' to 'secure.'
  • Made httpd(8) and dhcpd(8) correctly error check timegm(3).
  • Random-relink smtpd(8) and httpd(8) at boot.
  • httpd(8) now rejects CL.TE request framing (per RFC 9112 sections 6.1 and 6.3).
  • Made httpd(8) reject obs-fold with 400 (RFC 9112 5.2).
  • Fixed uploads using httpd(8) chunked transfer-encoding.
  • httpd(8) will now advertise Vary: Accept-Encoding whenever gzip-static is enabled.
  • Made httpd(8) advertise static file revalidation, preserving Last-Modified and If-Modified-Since flow.
  • Added more config checks to relayd(8).
  • Explicitly flush relayd(8) redirect rules after reloading.
  • In relayd(8), removed wrong disable flag for routers.
  • Use a per-host random ICMP echo id in relayd(8).
  • Added Lua patterns(7) support for relayd(8) filter rules; improved glob(7) documentation.
  • Use getexecpath(3) and execv(3) in bgpd(8), eigrpd(8), httpd(8), iked(8), ntpd(8), relayd(8), and smtpd(8).
  • Fixed relayd(8) deferring connections log.
  • Made relayd(8) check proc_compose and imsg_compose_event return values.
  • Allow setting log level from relayd.conf(5).
  • Added ECDSA support to the relayd(8) CA privsep engine.
  • relayd(8) now rejects duplicate Content-Length headers with 400.
  • Switched the default TLS cipher in relayd.conf(5) set from 'HIGH:!aNULL' to 'secure.'
  • Switched relayd(8) to new imsg API.
  • Made relayd(8) strip Content-Length for chunked messages (RFC 9112 section 6.1).
  • Made relayd(8) reject obs-fold to prevent parser differentials (RFC 9112 5.2).
  • Removed relayd(8) X509_dup() call that leaks memory; add error checks for X509_set_*.
  • In relayd(8), added support for the MKCALENDAR HTTP method.
  • Fixed debug build of relayd(8).
  • Let relayd(8) support multiple resolvable addresses.
  • Let relayd(8) handle HTTP responses without bodies.
  • Fixed NULL dereference in isakmpd(8) message_alloc_reply() callers.
  • Fixed possible unaligned 32-bit read by isakmpd(8).
  • Validate isakmpd(8) DELETE payload SPI array size.
  • Validate proposal and transform sizes in isakmpd(8).
  • Added length checks for the Port-Message and State attributes in login_radius(8) Access-Challenge.
  • Prevent the dhcpleased(8) engine from sending us a negative amount of routes.
  • Made dhcpleased(8) accept correct amount of routes from the engine process.
  • Make sure dhcpleased(8) UDP header length field at least covers the UDP header.
  • Extended smtpd(8) mask-src to suppress session details.
  • Switched smtpd(8) over to imsgbuf_get(3).
  • Free dispatcher in smtpd(8) mda_envelope_free() to avoid a leak.
  • smtpd(8) now rejects empty or slash-bearing usernames before building the mbox path.
  • smtpd(8) now rejects CR/LF in argv-derived fields before starting the SMTP enqueue dialogue.
  • Properly free the copied envelope on the smtpd(8) smarthost lookup failure path.
  • Properly free mda_subaddress in smtpd(8) mda_envelope_free() to avoid memory leak.
  • Made smtpd(8) use inflateEnd() to tear down the inflate stream in uncompress_gzip_chunk().
  • smtpd(8) now stops parsing DNS answers once unpack_rr() reports failure.
  • Validate encrypted smtpd(8) queue buffer sizes before processing auth tag and IV data.
  • Imported rtrd(8) RPKI-To-Router protocol daemon and rtrctl(8).

• tmux(1) improvements and bug fixes:

  • Keep the scroll position in tree mode when the list is rebuilt (issue 5631).
  • Do not leak waiting clients (in wait-for) if they are killed (issue 5614).
  • Do not cancel mark when a click is on the border.
  • Added support for borderless menus, like panes.
  • Added utf8 terminal-features.
  • Ignore focus events earlier to avoid them interfering with prefix.
  • Added -K flag to new-pane to make a modal pane capture all keys.
  • Always unzoom before splitting windows, including for floating panes.
  • Added 'T' to change pane title.
  • Added refresh-now command.
  • Ignore Ms if it is invalid (eg no %p1), report in client mode.
  • Fixed crash when synchronising groups and there is no current window.
  • Added pane_private_modes format with list of DEC private modes.
  • Prevented core dumps upon startup on landisk.
  • Added modal panes, created currently with new-pane -O.
  • Major rework of prompts.
  • Fixed cursor calculation when the status line is at the top.
  • Added -H flag to capture-pane to show hyperlinks.
  • Added -L to show line numbers with capture-pane and -F to show line flags.
  • Clear entire lines when removing from history or freeing.
  • Redraw entire session when making a new pane.
  • Added -g flag to kill-session to kill all sessions in a group.
  • Fixed crash when freeing layout cell.
  • Added missing argument to %unlinked-window-renamed.
  • Increase escape delay if the buffer contains a partial paste end.
  • Fixed crash caused by including unattached clients on sorted list.
  • Added new-pane command.
  • Fixed infinite loop due to underflow when redrawing scrollbar.
  • Fixed control mode teardown ordering for queued pane output.
  • Added Emacs-style re-centre-top-bottom.
  • Added time limits to some loops.
  • Added missing flags to screen_mode_to_string.

• LibreSSL version 4.4.0:

  • Portable changes:
    • Numerous compatibility layer fixes for AIX, FreeBSD, macOS, MinGW, NetBSD, and especially Windows.
    • Fixed incorrect code generation by the MSVC ARM64 optimizer in constant-time bignum code.
    • Improved assembly support on many platforms.
    • Fixed openssl(1), nc(1), and ocspcheck(8) silently running without pledge(2) and unveil(2) on hosts that provide them.
  • Internal improvements:
    • Minor code cleanup for PKCS#7.
    • Clear unused bits for the maximum of RFC 3779 IP address ranges.
    • Cleanup passes over the DTLS code, avoiding many contortions.
    • Zero out the failure_key in ML-KEM code.
    • Improve portability in preprocessor based SHA assembly.
    • Removed a few vestigial #ifdefs from public and internal headers.
    • Introduce and use dtls12_handshake_msg framework.
    • Rename union from _ to u in the ui code. Avoids Windows CE #ifdef.
    • Clean up and simplify signature algorithm handling after removal of TLSv1.0 and TLSv1.1.
    • Add a point at infinity check to ecdh_compute_key().
    • Fix incorrect purpose check in unreachable non-legacy path of the modern X.509 verifier.
    • Improve TLSv1.3 server handling of no shared groups.
    • Correct secondary key share handling for HelloRetryRequests.
    • Fix EXFLAG_CRITICAL mishandling in the crl_cb().
    • Among CRLs with the same score prefer the one with the most recent thisUpdate to match BoringSSL and OpenSSL behavior.
    • Clean up sequence number and message header handling in DTLS.
    • Remove redundant BIO_write() length assertions in b64_write().
    • Report invalid base64 BIO state as an internal error rather than asserting.
    • Improve SHA-3 performance by using an unrolled and interleaved algorithm.
    • Allocate TLSv1.3 receive buffers lazily.
    • Simplify handling of remaining record content on switch to the legacy stack.
    • Avoid harmless narrowing of the return value in dtls1_ctrl().
    • Remove NID_md5_sha1 support from tls1_PRF().
    • Remove DTLS unprocessed records queue.
    • Remove DTLS application data queue.
    • Remove SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS which was never set.
  • Compatibility changes:
    • The misnamed tls_peer_cert_chain_pem() has been deprecated and may be removed in a future release. tls_peer_cert_chain_verified_pem() and tls_peer_cert_bundle_unverified_pem() should be used instead.
    • Use X25519MLKEM768 as the preferred group for TLSv1.3 connections in libtls.
    • Ensure libtls keeps working with future OpenSSL releases that will stop NUL-terminating ASN.1 strings. This is an old bug in libtls that will bite, probably starting with OpenSSL 4.2.
    • CRYPTO_cleanup_all_ex_data() is now a no-op. It was not thread safe and the actual cleanup is now done by OPENSSL_cleanup(3).
    • Align X509_check_ca(3) with modern OpenSSL. While it has long been documented that it only works after calling X509_check_purpose(3), it still makes sense to "fail closed", i.e., indicate a non-CA.
    • Added OIDs for CCR, ErikIndex, ErikPartition, ErikSegmentIndex, and communityDefinition.
  • Bug fixes:
    • Fix PKCS7_set_{un,}signed_attributes(3) to allow caller to free on failure rather than risking a double free.
    • Initialize decode_error and invalid_key variables in TLS key share code to avoid branching on uninitialized memory.
    • Record extension length between type and data in the ClientHello hash to ensure identical framing in first and second CH.
    • Fix out of bound writes in the s_client XMSS mode.
    • Ensure EC_GROUP_check(3) and X509_CRL_verify(3) failures result in "app" failures in openssl(1) ecparam and openssl crl.
    • Do not fail accept on reverse DNS lookup failures in s_socket.
    • Ensure X509V3_EXT_print(3) only returns 0 and 1.
    • Avoid calling memcmp() on NULL in IPAddressFamily_cmp().
    • In libtls disallow wildcard matching of a TLD specified as a FQDN.
    • Unbreak some aspects of TLSv1.2 with custom curve lists.
    • Ensure a peer-provided EC public key uses uncompressed encoding.
    • Send decode_error alert on failure to decode an EC peer pubkey.
    • Avoid NULL dereference and out-of-bounds read in password-based CMS decryption.
    • Add some missing bounds check to ASN1_mbstrinc_copy().
    • Avoid freeing a caller-owned buffer in PKCS7_verify(3).
    • Remove SSL_OP_LEGACY_SERVER_CONNECT from default options.
    • Send illegal parameter alerts for various HelloRetryRequest violations.
    • Check that the server selected ciphersuite is valid for use with TLSv1.2.
    • Unlock CRYPTO_LOCK_UI on ui_open_session() failure to avoid a deadlock.
    • Check HMAC(3) return value to avoid later use of uninitialized in openssl(1).
    • Use correct alert for key_share without supported_groups.
    • Don't drop X509_V_ERR_HOSTNAME_MISMATCH when verify callback returns 1. It has long been documented that this is ill advised but some applications still do it.
    • Ensure the server selects an ALPN protocol that we advertised or abort the handshake with illegal_parameter.
    • Fix streaming of PKCS#7 objects with omitted content.
    • Avoid OOB access due to type confusion in PKCS7_stream().
    • Plug leak and various other bugs in asn1_multi(), a helper to handle sequences and sets in config parsing.
    • Fix RFC 3779 inheritance checks for leaves as far as possible without breaking the RPKI. Still allow the immediate issuer to omit one of the extensions because otherwise about one third of RFC 9286 Manifests would become invalid.
    • Correct a botched size check in dtls1_process_fragment().
    • Avoid confusing delta CRLs as full CRLs.
    • When copying an RSA-PSS EVP_PKEY_CTX, ensure saltlen and minimal saltlen restrictions are copied rather than using the defaults.
    • Allow DTLS clients to receive unexpected Finished messages.
    • Cache the leaf's extensions before adding it to a validated chain to make name constraints check work more reliably.
    • Ensure the whole subject is searched for email addresses and common names.
    • Check for embedded NULs in emails and subjectAltname in the essentially unused legacy NAME_CONSTRAINTS_*() API.
    • Remove support for nameRelativeToCRLIssuer in the CRL Distribution Point extension. Per RFC 5280 it SHOULD not be used by conforming CAs and it was eating memory for breakfast pre-signature.
  • Security and reliability fixes:
    • Fix parsing issues in X.509 name constraints URI host parsing. Handle IPv6 literals correctly and don't allow specially crafted userinfo to bypass host checks.
    • Limit size of buffered DTLS handshake messages to avoid overly large memory consumption on small handshake message fragments.
    • Fix an OCSP responder authorization bypass for clients using tls_config_ocsp_require_stapling(), of which only OpenBSD nc(1) and ftp(1) are known when they're used with the "muststaple" key word.
  • Testing and proactive security:
    • Improved test coverage for DTLS and TLS renegotiation.
    • Add X.509 CRL regress from pre-Apache2-licensed BoringSSL.
    • Rework the testing framework to be memory based rather than file based. Match Go's output format more closely.

• OpenSSH 10.6:

  • Security fixes:
    • Disabled ssh(1) LZ77 dictionary coder to avoid a potential side-channel leak.
    • Fixed ChannelTimeout and RekeyLimit not being applied in sshd_config(5).
    • Made ssh(1) authorized_keys "restrict" keyword apply correctly to tunnel forwarding.
  • Potentially incompatible changes:
    • Use IANA allocated codepoint for ssh-mldsa44-ed25519 instead of '@openssh.com'.
    • Made sshd_config(5) DisableForwarding=yes override PermitTunnel=yes.
    • Enforce a maximum size for usernames in ssh-agent(1) agent key use constraints.
    • Disallow NUL byte in scp(1) '-O filename'.
  • New features:
    • New ssh-add(1) option '-P' to skip PIN entry (bz3635).
    • ssh(1) signal handling with readpassphrase(3) fixed.
    • Switched ssh(1) from supercop ed25519 to libsodium.
    • Extended ssh(1) TCPKeepAlive to support forwardings (bz3921).
    • Added ssh-keygen(1) 'hexdump' to dump the key blob in hex format.
    • Allow setting/clearing ssh-keygen(1) touch-required/verify-required flags on FIDO private keys when resetting the passphrase.
    • Added ssh(1) '-Z user@host' mode that lists pubkeys that will be tried for authentication.
    • Added experimental ssh(1) support for composite post-quantum mldsa44-ed25519 signature scheme.
    • Added an explicit-seed variant of the ssh(1) keygen function.
    • Added signature malleability and pubkey validity checks to sshd(8) ed25519 verification.
  • Bugfixes:
    • Check ssh(1) compressed payloads don't inflate beyond the maximum payload length.
    • Avoid race between multiple ssh(1) processes establishing multiplexing control socket.
    • Plugged memory leak in ssh-add(1) (CID 913600).
    • Fix for ssh(1) CIDs 913601 and 913602.
    • Fix for ssh(1) CID 913600.
    • Converted ssh(1) channel timeouts to allow fractional and subsecond timeouts.
    • Made ssh(1) masking signals correctly use sigaddset (bz3981).
    • Fixed ssh(1) memleaks (CID 913598 and 913599); added missing semicolon (CID 913599).
    • Corrected Daylight Savings Time timestamp conversion by ssh(1) (bz4004).
    • Fixed ssh(1) proxy socket breakage in t-multiplex after recent pledge(2) changes.
    • Reading server banner by ssh-keyscan(1) no longer blocks/freezes on a many-host keyscan.
    • Allow session-bind@openssh.com requests when the ssh(1) agent is locked.
    • Avoid potential realloc use-after-free in the ssh(1) client.
    • Reordering of certificates tried during ssh(1) pubkey authentication.
    • Fixed ssh(1) ML-KEM/ECDH interop problem.
    • Removed some key ssh(1) parsing and verification paths from the pre-auth attack surface.
    • Avoid download to server-controlled path when performing ssh(1) download via commandline.
    • Avoid possible NULL deref in ssh(1); sanitise filenames received via remote glob.
    • Large refactoring of sshd(8) config management code.
    • Made sshd(8) force domain name received from the system resolver to lowercase.
    • Fixed two one-byte out-of-cound reads in sshd(8).
    • Stricter validation of transport state passed from the preauth to postauth sshd(8) process.
    • Fixed ssh(1) client use-after-free on error path if cipher_init() fails.
    • Added ssh-agent(1) -V to print version, use it to test the binary is functional after relinking.
    • Stopped ssh(1) validating bad cipher/mac lists arguments as valid.
    • Fixed ssh(1) NULL deref during pubkey auth.
    • Dropbear recently added a -Q option; make ssh(1) use it to query KEX if available.
    • Classify ssh(1) dynamic-tcpip channels as bulk, not interactive (bz3958).

• Ports and packages:

  Many pre-built packages for each architecture:

  • aarch64: 12907
  • amd64: 13060
  • arm: XXX
  • i386: 10659
  • mips64: 9072
  • powerpc: XXX
  • powerpc64: 9564
  • riscv64: 11116
  • sparc64: 10621

  Some highlights:

  • Asterisk 20.21.0 and 22.11.0
  • Audacity 3.7.9
  • CMake 4.3.5
  • Chromium 154.0.8037.92
  • Emacs 31.1
  • FFmpeg 9.0.2
  • GCC 16.1.0
  • GHC 9.10.3
  • GNOME 49
  • Go 1.27.1
  • JDK 11.0.32, 17.0.20, 21.0.12 and 25.0.4
  • KDE Gear 26.08.1
  • KDE Frameworks 6.30.0
  • KDE Plasma 6.7.5
  • Krita 6.0.3
  • LLVM/Clang 21.1.8 and 22.1.8
  • LibreOffice 26.8.0.3
  • Lua 5.1.5, 5.2.4, 5.3.6, 5.4.8 and 5.5.1
  • MariaDB 12.3.3
  • Mono 6.14.1
  • Mozilla Firefox 157.0 and ESR 153.4.0
  • Mozilla Thunderbird 153.4.0
  • Mutt 2.4.2 and NeoMutt 20260616
  • Node.js 24.21.0 and Deno 2.9.7
  • OCaml 4.14.2
  • OpenLDAP 2.6.15
  • PHP 8.3.33, 8.4.26 and 8.5.11
  • Postfix 3.5.28 and 3.11.7
  • PostgreSQL 18.6
  • Prism Launcher 11.1.0
  • Python 2.7.18 and 3.14.7
  • Qt 5.15.19 (+ kde patches) and 6.11.2
  • R 4.6.1
  • Ruby 3.3.12, 3.4.11 and 4.0.7
  • Rust 1.98.1
  • SQLite 3.53.2
  • Shotcut 26.8.1
  • Sudo 1.9.17p2
  • Suricata 7.0.7
  • Tcl/Tk 8.5.19, 8.6.18 and 9.0.4
  • TeX Live 2026
  • Vim 9.2.1125, Neovim 0.12.5 and Vim-Classic 2026091
  • Wayland 1.26.0 with compositors CoW, Labwc, Mango, Niri, Sway and Wayfire
  • Vulkan 1.4.357.0
  • Xfce 4.20.0

• As usual, steady improvements in manual pages and other documentation.

• The system includes the following major components from outside suppliers:

  • Xenocara (based on X.Org 7.7 with xserver 21.1.24 + patches, freetype 2.14.3, fontconfig 2.17.1, Mesa 25.0.7, xterm 410, xkeyboard-config 2.20, fonttosfnt 1.2.5 and more)
  • LLVM/Clang 22.1.6 (+ patches)
  • GCC 4.2.1 (+ patches) and 3.3.6 (+ patches)
  • Perl 5.42.3 (+ patches)
  • pkgconf 3.0.7
  • NSD 4.15.2
  • Unbound 1.26.1
  • Ncurses 6.4
  • Binutils 2.17 (+ patches)
  • GDB 6.3 (+ patches)
  • Awk 20250116
  • Expat 2.8.4
  • zlib 1.3.2 (+ patches)

How to install

Please refer to the following files on the mirror site for extensive details on how to install OpenBSD 8.0 on your machine:

• .../OpenBSD/8.0/alpha/INSTALL.alpha
• .../OpenBSD/8.0/amd64/INSTALL.amd64
• .../OpenBSD/8.0/arm64/INSTALL.arm64
• .../OpenBSD/8.0/armv7/INSTALL.armv7
• .../OpenBSD/8.0/hppa/INSTALL.hppa
• .../OpenBSD/8.0/i386/INSTALL.i386
• .../OpenBSD/8.0/landisk/INSTALL.landisk
• .../OpenBSD/8.0/luna88k/INSTALL.luna88k
• .../OpenBSD/8.0/macppc/INSTALL.macppc
• .../OpenBSD/8.0/octeon/INSTALL.octeon
• .../OpenBSD/8.0/powerpc64/INSTALL.powerpc64
• .../OpenBSD/8.0/riscv64/INSTALL.riscv64
• .../OpenBSD/8.0/sparc64/INSTALL.sparc64

Quick installer information for people familiar with OpenBSD, and the use of the "disklabel -E" command. If you are at all confused when installing OpenBSD, read the relevant INSTALL.* file as listed above!

OpenBSD/alpha:

If your machine can boot from CD, you can write install80.iso or cd80.iso to a CD and boot from it. Refer to INSTALL.alpha for more details.

OpenBSD/amd64:

If your machine can boot from CD, you can write install80.iso or cd80.iso to a CD and boot from it. You may need to adjust your BIOS options first.

If your machine can boot from USB, you can write install80.img or miniroot80.img to a USB stick and boot from it.

If you can't boot from a CD, floppy disk, or USB, you can install across the network using PXE as described in the included INSTALL.amd64 document.

If you are planning to dual boot OpenBSD with another OS, you will need to read INSTALL.amd64.

OpenBSD/arm64:

Depending on your hardware, you can write install80.iso or cd80.iso to a CD and boot from it, or write a system specific miniroot to an SD card and boot from it after connecting to the serial console. Refer to INSTALL.armv64 for more details.

OpenBSD/armv7:

Write a system specific miniroot to an SD card and boot from it after connecting to the serial console. Refer to INSTALL.armv7 for more details.

OpenBSD/hppa:

Boot over the network by following the instructions in INSTALL.hppa or the hppa platform page.

OpenBSD/i386:

If your machine can boot from CD, you can write install80.iso or cd80.iso to a CD and boot from it. You may need to adjust your BIOS options first.

If your machine can boot from USB, you can write install80.img or miniroot80.img to a USB stick and boot from it.

If you can't boot from a CD, floppy disk, or USB, you can install across the network using PXE as described in the included INSTALL.i386 document.

If you are planning on dual booting OpenBSD with another OS, you will need to read INSTALL.i386.

OpenBSD/landisk:

Write miniroot80.img to the start of the CF or disk, and boot normally.

OpenBSD/luna88k:

Copy 'boot' and 'bsd.rd' to a Mach or UniOS partition, and boot the bootloader from the PROM, and then bsd.rd from the bootloader. Refer to the instructions in INSTALL.luna88k for more details.

OpenBSD/macppc:

Burn the install80.iso image from a mirror site to a CDROM, and power on your machine while holding down the C key until the display turns on and shows OpenBSD/macppc boot.

Alternatively, at the Open Firmware prompt, enter boot cd:,ofwboot /8.0/macppc/bsd.rd

OpenBSD/octeon:

After connecting a serial port, boot bsd.rd over the network via DHCP/tftp. Refer to the instructions in INSTALL.octeon for more details.

OpenBSD/powerpc64:

To install, write install80.img or miniroot80.img to a USB stick, plug it into the machine and choose the OpenBSD install menu item in Petitboot. Refer to the instructions in INSTALL.powerpc64 for more details.

OpenBSD/riscv64:

To install, write install80.img or miniroot80.img to a USB stick, and boot with that drive plugged in. Make sure you also have the microSD card plugged in that shipped with the HiFive Unmatched board. Refer to the instructions in INSTALL.riscv64 for more details.

OpenBSD/sparc64:

Burn the image from a mirror site to a CDROM, boot from it, and type boot cdrom.

If this doesn't work, or if you don't have a CDROM drive, you can write floppy80.img or floppyB80.img (depending on your machine) to a floppy and boot it with boot floppy. Refer to INSTALL.sparc64 for details.

Make sure you use a properly formatted floppy with NO BAD BLOCKS or your install will most likely fail.

You can also write miniroot80.img to the swap partition on the disk and boot with boot disk:b.

If nothing works, you can boot over the network as described in INSTALL.sparc64.

How to upgrade

If you already have an OpenBSD 7.9 system, and do not want to reinstall, upgrade instructions and advice can be found in the Upgrade Guide.

Notes about the source code

src.tar.gz contains a source archive starting at /usr/src. This file contains everything you need except for the kernel sources, which are in a separate archive. To extract:

# mkdir -p /usr/src
# cd /usr/src
# tar xvfz /tmp/src.tar.gz

sys.tar.gz contains a source archive starting at /usr/src/sys. This file contains all the kernel sources you need to rebuild kernels. To extract:

# mkdir -p /usr/src/sys
# cd /usr/src
# tar xvfz /tmp/sys.tar.gz

Both of these trees are a regular CVS checkout. Using these trees it is possible to get a head-start on using the anoncvs servers as described here. Using these files results in a much faster initial CVS update than you could expect from a fresh checkout of the full OpenBSD source tree.

Ports Tree

A ports tree archive is also provided. To extract:

# cd /usr
# tar xvfz /tmp/ports.tar.gz

Go read the ports page if you know nothing about ports at this point. This text is not a manual of how to use ports. Rather, it is a set of notes meant to kickstart the user on the OpenBSD ports system.

The ports/ directory represents a CVS checkout of our ports. As with our complete source tree, our ports tree is available via AnonCVS. So, in order to keep up to date with the -stable branch, you must make the ports/ tree available on a read-write medium and update the tree with a command like:

# cd /usr/ports
# cvs -d anoncvs@server.openbsd.org:/cvs update -Pd -rOPENBSD_8_0

[Of course, you must replace the server name here with a nearby anoncvs server.]

Note that most ports are available as packages on our mirrors. Updated ports for the 8.0 release will be made available if problems arise.

If you're interested in seeing a port added, would like to help out, or just would like to know more, the mailing list ports@openbsd.org is a good place to know.

What I learned about AI search when I made up 50,000 stats that got cited by ChatGPT...

About 7 months ago, I launched a website with 50,000 statistics. Every one of them was fake.

Google has forgotten the site exists and deindexed the pages, but ChatGPT hasn't. Since the website went live 7 months ago, it has sent more than 10,000 AI sessions its way. And now more than 330 referring domains, including Shopify, Bluehost, and DHL, link to the site. Its made-up numbers have also ended up in an academic paper and in a bank's investment research.

At Peec AI and in the industry, we talk about GEO and SEO every day, and we keep looking for new tactics. I’ve been working on this stats page one for a long time, sharing pieces of it publicly along the way. Of course, it’s experimental, but the results have been hard to ignore.

Where the idea for publishing fake statistics came from

The impetus to seed a site with statistics came out of long-running research I've been doing on LLMs, relevance engineering, and grounding (credit to the iPullRank team, Dan Petrovic, and Wil Reynolds).

In the course of my work, I noticed a pattern: as more teams write time-sensitive and breaking content with LLMs, those LLMs have to look for (seemingly) reliable data during their research to fill the gaps in their knowledge. Statistics are often exactly what they’re looking for.

Most GEO advice focuses on one moment: getting your brand into the AI answer. This experiment looks at what happens after the answer, when people take that output and use it, putting it into presentations, adding it to a shopping list, and yes, publishing it on their website.

I didn't come up with the idea for this experiment alone. Hat tip to Seer Interactive, who already published an eye-opening study in August 2025 that got a few thoughts bouncing around in my head. Several months later, those thoughts came together and finally made it to the top of my to-do list. In March 2026, I started working on building the site that would let me test my ideas.

The setup: a website and 50,000 made-up stats, created in one day

Quick context for anyone who wasn’t following along in real time as I ran this experiment:

I bought a brand-new domain, stateglobe.com, and generated 50,000 statistics pages in a single day with GPT-4.1. The site purports to provide stats on SEO, content marketing, social media, e-commerce, and web technology from 200 countries. Except every number was totally invented. I never checked a single one. I pushed them to the site with a basic AI web design template. This cost me around $30. Later, I added 15,000 listicles on top of the statistics. That was about $20 more, so all in all, this is an experiment that came in at the very low price of about $50.

The reaction when I first shared it was wild. When my friend Kevin featured it in Growth Memo, it reached a much bigger audience. I think people responded so enthusiastically to this work because it showed great results while also speaking to the fears people have about what ends up in AI search results.

What happened

1. Google buried the site almost immediately

When I launched the site, traffic, indexing, and engagement were initially going really well. Using indexer tools, I got almost the entire site indexed within a week, and it started to appear in Google results.

Then two Google updates came out right after launch, and my Google visibility collapsed.

I've been invisible on Google for many months now. Indexed pages bounce between 5 and 20 impressions. At one point, I got curious and created a subdomain to see if I could increase impressions, but it didn't really help.

Other than that, I haven't touched the site. Some pages might even fail to load now and then. I don't know.

But when I sat down to write this, I checked the crawl data in Cloudflare after 7 months.

In the last 30 days alone, the site got more than 600,000 requests from bots. Around 72,000 of them came from ChatGPT-User. That is the agent ChatGPT uses to open a page in real time while answering someone. So these are not training crawls. Each one is ChatGPT fetching a fake statistics page to answer a real question.

2. Unlike Google, ChatGPT never stopped pulling from the site

And when I say, “never stopped,” I mean ChatGPT really never stopped.

After 7 months, the site now has 330+ referring domains

According to Ahrefs and Semrush, the site has links from 330+ other sites. That includes well-known brands like Shopify, DHL, and Bluehost. With strong Google performance, the numbers might have been even better.

ChatGPT is still citing it to this day

Google may have forgotten about the site, but ChatGPT clearly hasn’t. The site is still earning citations and traffic more than 7 months after launch.

If you've read Tomek's ChatGPT Index research, you're lucky, because it’s a great intro to how ChatGPT search works. If you haven't, add it to your reading list right now, because it helps explain why my website has been living in ChatGPT/OpenAI Index for so long.

A completely made-up website still performing so well is shocking. Since March, GA4 shows 10,000+ sessions from ChatGPT alone, and Cloudflare shows the site has high marks for retrieval.

I didn’t include direct sessions in overall visits, because it mostly looks like bot traffic. Remember the dead internet theory!

Right after I joined Peec in June 2026, I also set up a visibility dashboard in our tool to track a few prompts. Performance for them is still strong. On October 7, stateglobe.com was ranked second for visibility on these prompts, behind only data powerhouse Statista.

Retrieval is not ranking

The constant retrieval is the first big lesson: ranking on Google and being retrievable by an LLM are two different problems.

When ChatGPT searches, it doesn't just copy Google's top 10. It rewrites your prompt into its own sub-queries (called fanout queries), pulls candidates from its search sources and its own cache, reranks them, and then opens a handful of pages to ground the answer. A page can be invisible on Google and still perform well in every one of those LLM steps.

StateGlobe is a good example. While Google dropped it, the AI retrieval bots kept coming back.

For GEO, this means Google rankings are only one signal, not the whole picture. If you only track Google, you are missing a channel that can work even when Google says “no.”

3. Fake data turned into real citations

You’d expect that if a site performs well with information retrieval tools, its information would begin to appear out in the wild. And you would be right.

StateGlobe was built entirely on fake data, using the cheapest model available and a prompt that was nothing more than a list of countries and topics plus two sentences. Nevertheless, the output was…

…cited in an academic paper…

…used in investment research by Qatar's largest financial group…

…cited by an economics publication in India…

…and used as a source in a research report from a Canadian influencer community.

Note that these are only the citations that linked back to the StateGlobe site. Presumably, many more used the data without a link.

The uncomfortable implication: citation laundering

On day one, a fake number on StateGlobe had zero authority. It was a random stat on a brand-new domain.

Then an academic paper cited it. Then a bank. Now the next person, or the next model, that finds this number sees a stat with a source. And that source is cited by serious institutions.

The fake data certainly didn't become true, but every citation made it look more trustworthy.

It has the potential to get worse: after so much retrieval and citation, these pages end up in web crawls, and web crawls end up in training data (I hope it hasn’t!). A number that started as a GPT-4.1 guess can become something the next model "knows."

This points to the larger risk suggested by this experiment, and it's why I'm sharing this as research, not as a playbook for fake content. Verifying sources should become an essential part of writers’ and researchers’ workflows.

4. Lastly, we tried running our experiment with real data

Once I began working at Peec, I decided to try a version of this test again. As the GEO Research team, we talked through the results up until that point and quickly launched a simple new page. This time, there were no made-up numbers, and we checked every stat and properly cited its source. You can view it here: peec.ai/ai-search-geo-statistics.

Almost immediately, sites we suspect use AI to write their content started linking to us. For the second time, using a second site, earning links by publishing statistical content proved that a hypothetically strong tactic worked in reality.

Lessons learned

Why publishing statistics leads to LLM citations

The two tests show that LLMs have a strong preference for seeking out statistics when asked to write articles. The mechanism is simple:

1. More and more content is written with LLMs.
2. When an LLM writes, it researches the appropriate topic.
3. When the LLM hits a gap, it looks for a number to fill it.

The reasons behind this process are equally clear.

Research means fanout queries asking for statistics

When a prompt requires research, the model breaks it into sub-queries, adds modifiers like "statistics," "data," "report," or the current year (if also requested in the prompt text). If someone asks for the model to compose a blog post about remote work, the model will search for "remote work statistics 2026." Pages that optimize for what models search rather than for what humans type will appear more often in LLM results.

A number looks like evidence that can fill knowledge gaps

When a model is asked to draft a piece of writing, a citation to a page that says "Remote work is growing" adds little authority and remains vague. If that page instead says "X% of employees work remotely at least once a week," there’s suddenly something that is specific, quotable, and additive. When a model grounds an answer, a specific number is the most useful thing it can find. These numbers look like evidence, though as this experiment proves, sometimes they aren’t.

The model doesn’t check the number

A search-grounded piece of LLM-written content has a tight budget for latency and cost. The system fetches a few pages, pulls the relevant passages, and starts to write. Fact-checking doesn’t happen anywhere in the process.

Verifying a single statistic would mean finding independent sources, comparing them, and resolving conflicts. Across billions of prompts by millions of users, the costs in both time and money would add up, making verification too slow and too expensive for practical purposes.

To get around this, LLMs use rerankers that score relevance, but not truth. That means if a passage matches the query and looks authoritative, it gets used.

Statistics have a built-in freshness that models like

I've written before about ChatGPT's recency bias in how it scores sources. Statistics pages contain the year in the title, the headings, and the URL. Three built-in signals to the model that what’s on the page is fresh.

How to build a statistics page the right way

The two tests I ran show that statistics pages are a very powerful way to get your content cited by LLMs. While I absolutely do not recommend coming up with bogus data, you can use the learnings from our small test to create your own pages with real data. Here's what worked for us at Peec and what I would do if I were making a statistics page again.

• Make one claim per sentence. Each stat should make sense on its own, out of context. Retrieval doesn’t work on pages, but rather on passages. If a number needs the paragraph above it to make sense, it probably won't get pulled.
• Put the source and year next to every number. "According to [Source] (2026), X%..." This helps the model, the human editor, and your credibility. It’s one small piece of information hygiene that benefits the broader information environment.
• Match headings to fanout queries. The headings on your page should match the way LLMs search the internet: "[Topic] statistics," "[Topic] market size," "[Topic] adoption by country." Think in the queries models run, not just the keywords people type.
• Show the update date (and actually update it). Freshness is a real signal that models take into account. A stale stats page will lose to a newer one.
• Make the stats easy to fetch. Use server-rendered HTML instead of hiding data behind JavaScript, tabs, or images. Also, be sure to check your robots.txt and your CDN or WAF rules. Your site may be blocking AI retrieval bots without your knowing it.
• Keep it simple. Our Peec AI GEO statistics page is basically a list. Yours doesn’t need to be anything more than that, either. Save design resources for sites and assets that can actually benefit from them.
• Add original data when you can. Aggregated stats may get you a few citations, but when you say something no one else does, you can become the primary source.

How to track whether your page is getting picked up

Google Search Console won’t show you what’s going on with AI bots on your site. Here is what I track instead:

• AI bot activity in your server logs or Cloudflare. Look for retrieval bots like ChatGPT-User, OAI-SearchBot, and PerplexityBot, not only training crawlers. We have this feature!
• AI referral sessions in GA4 from chatgpt.com, perplexity.ai, and similar sources.
• Citation and visibility tracking across a set of prompts. At Peec, we use our own tool for this, obviously.
• New referring domains in Ahrefs or Semrush.
• Unlinked mentions. Search your exact numbers in quotes. You will find people using your data without linking to you.

A word on ethics

It should go without saying that you should never publish fake content. While my experiment relied on tens of thousands of unverified stats, I ran it in order to share the results with the public, and the website, while still live, now carries a disclaimer. When putting out content we hope gets picked up by LLMs, our job should always be to put out accurate, accessible information.

To add another caveat, there’s no guarantee this tactic will continue to work. We tested it, and these are the results, but now that they’re published, LLMs might close this gap. For now, it works, but in the future it may not, and of course it should never be abused.

And one final point: this is a tactic, and neither can nor should be the basis for your organization’s entire GEO strategy. The results I got with StateGlobe were extreme, but the brands most likely to benefit from using the technique are those people already trust.

What's next from GEO Research at Peec

At Peec, our research team is running close to 40 experiments like this one. Some are still in progress, and others are already showing results. Building a long-term strategy for your brand means testing, measuring, and sharing what we learn along the way.

More soon!

Despite being the most widely consulted reference work ever created Wikipedia faces existential challenges from generative AI companies whose products divert traffic away from it. Helen Choi argues academics, by virtue of their responsibilities as researchers and teachers in higher education, have an ethical duty to defend and support open knowledge communities such as Wikipedia.

When people use AI products like Google’s Gemini or ChatGPT, they are treated to immediate answers. Sometimes such answers include links to Wikipedia. However, most users of AI products do not click the links to Wikipedia, choosing instead to accept machine-generated outputs without further verification. If this practice continues, readership on Wikipedia will continue to decline.

The AI threat to Wikipedia

This is a problem for Wikipedia because it is run by a volunteer community that does everything from writing, coding, and administration, and this community comes from Wikipedia’s readers. A decline in the number of readers means fewer articles, updates, and corrections – and ultimately, a derelict and quite possibly defunct encyclopedia. This would be a loss for humanity as well as for the AI industry itself, as it is heavily reliant upon Wikipedia and its five billion words for training the systems that run their products.

Wikipedia, of course, is more than training data for machines; it is a self-governing community of people that exists independently of commercial or governmental controls. This community of volunteers exists to produce and share knowledge for the common good. It is difficult to think of any other volunteer endeavour that has been more influential, pervasive, and powerful than Wikipedia. It has been more successful than commercial enterprises like Microsoft’s encyclopedia, Encarta and xAI’s machine-generated Grokipedia, and it is perceived to be so influential that it has been banned in some countries, like China.

However, the powerful AI companies that now control online search pose existential challenges for a weakened and demoralised community, as in addition to stripping Wikipedia of readers, they have misappropriated the hard work of volunteers for their own profit, reducing writing and research to machine feed. Some AI companies take Wikipedia’s content through unauthorised scraping, while others, including Microsoft, Amazon, and Meta, pay Wikipedia for high-speed API access to its pages.

Academia’s duty to protect open knowledge

Academia’s duty to protect open knowledge like that produced on Wikipedia is grounded in its privileged position within and structural connection to knowledge. According to Iris Marion Young’s Social Connection Model, one’s duty to remedy injustice is determined by one’s connection to processes and structures in which one participates. As a participant in knowledge processes, academia has a responsibility to address injustices in those processes – such as those committed by the AI industry against vital sources of knowledge like Wikipedia.

With its access to resources and higher status than the largely anonymous group of Wikipedia volunteers, academia has the power and influence to address the injustice of an endangered Wikipedia, as well as the capacity to do so. As people who are trained in producing knowledge and who teach the next generation of knowledge producers, academics are in fact uniquely qualified to support Wikipedia’s current and future reserves of knowledge, as well as its community of volunteers.

How can academics support Wikipedia?

Academics are not the ones that have harmed Wikipedia, they – as fellow stewards of knowledge – have a duty to help defend it from those that have. And academics are well-equipped to do so; their subject matter expertise can be used to address content gaps, correct errors, and provide context on complicated topics on Wikipedia. Academics’ access to and facility with high-quality sources can help improve Wikipedia’s quality. And as Wikipedia’s citation practices mirror those academic practices, academics may find editing Wikipedia to be less daunting than others do.

Along with contributing their expertise and knowledge to Wikipedia’s pages, academics can also support Wikipedia by integrating it into their scholarly work. Just as academics must cite any AI-generated machine outputs they rely upon in their research and writing, they can also cite Wikipedia if they use it in their work. Doing so can highlight Wikipedia’s value to other academics as a source of knowledge and provide greater transparency in one’s research processes. Despite longstanding skepticism of Wikipedia among some scholars, citations to Wikipedia in academic journals appear to be increasing – even in high-impact publications in subject areas like the health sciences.

Academics can also support Wikipedia by teaching their students how to contribute to Wikipedia. This practice can enhance knowledge and understanding about Wikipedia among future generations and has the added benefits of helping students bolster their subject matter knowledge and information literacy skills. Many instructors are already supporting Wikipedia in this way. Through the non-profit Wiki Education Foundation, more than 152,000 students at over 8,000 colleges and universities in the United States and Canada have contributed more than 125 million words to Wikipedia since 2010.

Students report that writing for Wikipedia provides them with motivation to produce high-quality writing, as they are writing for a real-world audience. Students also develop practical information literacy skills in source evaluation, copyright compliance, and source attribution. In addition, because Wikipedia currently bans AI-generated writing, instructors may find assigning Wikipedia work to be one way for students to build writing and thinking skills independently. As about 19% of Wikipedia’s new active editors come from Wiki Education’s programs, teaching students to contribute to Wikipedia is a viable way to sustain and renew it with a new generation of contributors.

The fulfilment of ethical obligations to support knowledge communities, however, requires support from institutions of higher education. Currently, most academics are evaluated on their scholarly and research achievements, teaching performance, and service duties to their departments. Public service, like contributing to Wikipedia, goes largely unrecognised, if it is even counted at all. If academics are to fulfil their responsibilities to protect knowledge and knowledge communities, institutions must recognise efforts like contributing to Wikipedia and provide resources and support. Doing so may also help to address the public’s eroding trust in higher education itself, as a greater commitment to serving the public would reassert the role of universities as stewards of knowledge that exist to serve humanity – a role shared by Wikipedia.

This post draws on the author’s article, Towards a practice of knowledge commoning: academics’ ethical duties to defend Wikipedia in the age of generative AI, published in AI and Ethics.

What is the purpose of education in the age of AGI?

Yesterday, the title The End of Education by Neil Postman called to me from my bookshelf, whispering that it might be the right book at the right time. It was. Published in 1995, it was surprisingly appropriate balm for the soul of a confused programmer and soon-to-be father.

My wife and I are expecting our first child. My economically valuable skillset – programming – suddenly feels less valuable. What shall I teach my son? And to what end?

Mr. Edison says
That the radio will supplant the teacher.
Already one may learn languages by means
Of Victrola records.
The moving picture will visualize
What the radio fails to get across.
Teachers will be relegated to the backwoods.
With fire-horses,
And long-haired women;
Or, perhaps shown in museums.
Education will become a matter
Of pressing the button.
Perhaps I can get a position at the switchboard.

– Quoted in The End of Education by Neil Postman, quoting Teachers and Machines: The Use of Technology Since 1920 by Larry Cuban

In Edison’s own words:

Books will soon be obsolete in the public schools… Our school system will be completely changed inside of ten years.

– Thomas Edison, The New York Dramatic Mirror, 1913

Back in 2013, I boldly predicted that MOOCs would upend education. Ah, my past self, you sweet summer child.

Nassim Nicholas Taleb has helped me appreciate the staying power of staying power, sometimes called The Lindy Effect. Merely staying alive implies some anti-fragility to adapt and survive. Consider that Harvard, Yale, and Princeton were founded to educate the clergy. From The End of Education:

In the Western world, beginning in the thirteenth century and for five hundred years afterward, that God was sufficient justification for the founding of institutions of learning, from grammar schools, where children were taught to read the Bible, to great universities, where men were trained to be ministers of God.

Schools survived what happened to religion. It should be no surprise that they’ve survived the radio, motion pictures, and the internet.

We typically confuse why something claims it exists, ie to glorify God, vs the forces that actually perpetuate it, which are subtler, we’d prefer not spoken aloud, and more prosaic, ie endowments, prestige, and needing someone to watch one’s kids.

It has been a surprisingly good bet that schools will continue to exist in roughly their current form for many years to come. Ironically, there also seems to be some staying power to technologists boldly (and so far incorrectly) doubting the staying power of schools! I myself have contributed to this grand tradition multiple times, and find myself at risk of doing it yet again.

Surely this time must finally be different, right? We have captured intelligence in a bottle, and you’re telling me that “Ok class, turn to page 17” and “Does anyone know how to solve for x” are still going to be around in the 2030s?

There are many shifting purposes to education, which underpin how it has survived this long. As the times change, so do its purposes shift and adapt, such as:

• become a good person
• become a good citizen
• earn a living
• make the world better
• learn basic facts

I once tried to come up with a single-word purpose for education, and I landed upon the word “resourceful”, because I reasoned that if you “were able to use arbitrary resources to uncover and solve problems”, you had no more need for schooling. In the age of Google, email, and the internet, a person was educated when they could wield them. But now I see my vision of resourcefulness perfected in the AI agent and its tool loop. Maybe resourcefulness will go the way of the Dewey Decimal System which in turn supplanted memorization and an oral tradition.

Imagine education as a table held up by its many purposes. I didn’t realize how centrally important “the ability to earn a living” was for me until it started to wobble. A big reason is because I’m looking for a more objective arbiter of “good” in education. Education’s own tests and measures can feel stifling. The market offered a counterpoint. Steve Jobs and Bill Gates were college dropouts, but the market deemed them good. Now that I think of it, apparently Einstein was a mediocre student, but his contributions to science were his way out. With recent advances in AI mathematics, both of these paths to glory are under fire. Clara Collier makes similar points in her exceptional essay “After Work, We’ll Have Each Other.”

If AI takes our ability to contribute, what’s left for our children?

Neil Postman offers a few suggestions for positive purposes for education that I found heartening, not mainly for their content, but for the fact that it’s possible to make up new purposes for education and advocate for them. My favorite suggestions of Postman’s are:

• Spaceship Earth – we’re all in this together; let’s take care of each other and our planet
• The American Experiment – let’s revive our sense of wonder, curiosity, and responsibility about what America is and can be
• The World Makers – as a student of McLuhan, Postman would be remiss if he didn’t invite students to make the tools and narratives that thereafter make us

At the risk of going too meta, I do strongly believe in Postman’s point (in his other education book, Teaching as a Subversive Activity) that “the medium is the message.” That the way we teach what we teach is often more important than the what. And likewise, I believe in Dr. Alfie Kohn’s notion that we should relate to our educational charges as humans, not objects – “doing with” vs “doing to”. Thus, I believe it may be most honest and effective to invite our children to help us craft the purpose for their education as we figure it out together.

Wish me luck.

In 1996, I was a Ph.D. student at Syracuse University. One evening I was sitting in my office and the phone rang, “Hello?”
“Is this Paul Tyma?”
“Yes?”

Bob replied in very fast English.
“This is Bob Cringely. I just read 7 Java books and yours is the best.”

My first thought was “Huh. He actually said my last name correctly”.

But my quick 2nd thought was that there were not, in fact, 7 Java books in existence. I did indeed write a Java book, but to my knowledge, mine was the 2nd on the market and even then, I’m not sure it was the best. My Ph.D. advisor, Doug Lea, had been an early member of the Java project at Sun Microsystems. He introduced Java (and the JVM) to all his grad students and I believe something like 4 of us wrote books piggybacking upon the hype at the time.

In any case, as you might know, it is not common to get accolades or even much attention for writing a programming book1. I had no idea who this “Bob Cringely” person was, but, um, Thanks! So glad you liked it - let’s talk some more about how great it is!

I didn’t know it then, but Bob was way ahead of me. It’s likely he pictured me as some lonely computer geek (or “nerd” in his parlance) sitting in a tiny office tip-tapping away at some code enjoying yesterday’s pizza. (He was right). He also knew computer nerds like me were typically a bit starved for attention, especially around anything related to computer-centric achievements. Again, Bob knew his audience.

He continued, “Do you do Java programming too?”

Writing a programming book in the 1990’s afforded many of the same benefits as today. In other words, nearly nothing. You sure weren’t getting rich off writing books. But it did get me invites to teach Java at some Software Conferences. Which then got me invites to train Java to teams inside different companies. Because of that, my friend and I started a company around Java training. We hadn’t done any contract programming until then, but we’d talked about it plenty.

“Sure we do!”, I rather lied.

From there, Bob hired us to build him a system called (or codenamed?) “Pronto”.

Pronto was to be the distribution future of print Magazines. The big idea was for customers (who were paper magazine subscribers) to install a small daemon process on their computer that would monitor for times where their Internet connection (i.e. often dialup modem at this point) was online but mostly idle. Our system would then slowly but persistently download their next month’s issue of “Good Housekeeping” or “Car and Driver””. Once it was fully downloaded, the daemon would lie in wait until 2am the next morning and send the PDF off to their home printer. The customer would wake up to be happily surprised by a fully printed copy of their magazine waiting for them2

Like many at the time, Bob didn’t believe that reading online would replace reading a full-color, paper magazine. But how that magazine got to your house could change, and that’s where Pronto came in.

Bob had secured funding for Pronto - from someone in Japan I think. I don’t remember, but I remember Bob paid us consistently for the time it took to develop Pronto. After we finished, I don’t know what happened to Pronto, except that it never released in any meaningful sense. But this did begin my 30-year relationship with Bob (or “Cringe” as we called him).

As I said, before this, I had no idea who Bob was. I didn’t know about his claim-to-fame book “Accidental Empires”. His PBS series “Triumph of the Nerds” was released right around the time I was working with/for him. Well after Pronto somehow I got put on Bob’s list of “People I’m going to send my next startup idea to for thoughts” email list. I was by no means alone on that list, and sometimes I got into email threads with some interesting Tech personalities.

I just took a look - and I have had 320 emails with Bob in the past 13 years. Mind you, those aren’t unique emails, most are part of long email chains so I’d estimate I’d email with Bob about 3 times a year since the late 90’s.

Usually, the email chains started with Bob emailing me a wall-of-text about his new startup idea. While the first half of the email was about the idea, invariably, the 2nd half was about how much money it was going to make. I was always impressed at how “to the penny” he got with his projections for something that was basically an idea written on a virtual napkin.

Some ideas were good, and some were not so good. Through my career, I actually joined him in 2 ventures - home-account and Sonisafe. I have the pitch decks for a few, and the detailed descriptions of a bunch more ideas that maybe no one else has seen. This was a great honor in the beginning, especially as his fame grew. But all along the way, I felt Bob was missing the point.

If you ever met Bob - or heck, just saw him in any of his TV specials, you could see Bob charmed everyone he met. He was good-looking, disarming, and curious. He was also an excellent writer, but it was on the screen he really shined. He was comforting and fun to watch. He was fearless and made people feel special. He wasn’t a “nerd” but if, like me, you were; he understood you and he made it OK. In fact, at times, he even made it look glamorous.

Despite his innumerable gifts, Bob seemed to really want to be a superstar startup founder. I’m sure if one of his startup ideas had exploded, Bob would have filled the role fine. But to me - he was a pure natural in front of the camera. I always thought he should start a Youtube channel interviewing Silicon Valley celebrities. I sent him a few emails along those lines, but Bob would mostly just ignore me. He was usually too excited about his new/current startup idea.

When I lived in San Francisco, he and I had lunch or dinner occasionally. He really was a Silicon Valley celebrity. When the inevitable person(s) would come up to him telling them they were a huge fan, he’d act like it the first time anyone ever recognized him. Every time. The TV Cringe instantly came to life and it was always a pleasure to watch.

Goodbye Mr. Cringely. I’m very sorry to see you go. I will miss you.

A few more Cringe stories

2001

Right after the C# language was released (it must have been around 2001 or so?), I spent the evening and into the morning reading about it. Finally around 2am, with bleary eyes and a racing mind I emailed Bob - “Dotnet is going to squish Java”.

I got a response 2 minutes later, “Why?”.

I spent the next hour writing an overly long and terribly rough email, in a half-awake, caffeine-induced state and sent it off. I woke up the next morning to Bob’s new blog post - a rather lightly edited version of my rant!

Sharper Than Ever. Microsoft’s C# Language Might Be the Death of Java, but Sun’s the One to Blame

I just remember being grateful he didn’t mention me. But then, he called me later that day, “Sun is a bit unhappy with the blog post. I’ve been summoned to Sun Headquarters tomorrow and you’re coming with me.”

The next day Bob and I went to Sun Microsystems. He and I sat in a room with Jonathan Schwartz (CEO) and Rich Greene (C-something-else) while they defended Java and gave me nasty looks wondering who the hell I was and why the hell I was even there. They seemed plenty interested in impressing Bob though. By the way, Dotnet didn’t squish Java but I did get a Sun t-shirt.

After that, Whenever I emailed him, I often tacked onto the bottom of my emails - “Do whatever you want with this email, but don’t mention me. And know this email could be totally wrong or silly - either way, it’s yours now”.

2004

In and around 2004 I was living in NYC and I got a forwarded email from Bob. It was a forward from a Producer at the TV network VH1 telling him they were doing a video series called “My Coolest Years” and had a special episode about “Geeks” and they needed a computer geek. They asked him if he wanted to be interviewed about what it was like being a “geek” in high school.

He replied to the Producer, cc’ing me:

“Sorry, but I got laid plenty in high school. However, I have cc’d my friend Paul who actually was a geek in high school. He also lives in NYC.”

I ended up with a total of about 8 minutes in the show alongside Mark Cuban, John Tesh, Ben Stein, and Wil Wheaton. Bob would have been way better.

2026

Randomly, a few months ago I once again watched Bob’s “Plane Crazy.” A classic. And because of the comments surrounding his death I found that his special “The Transformation Age” is also on Youtube which I had never seen (in 8 or so separate videos). It’s quintessential Cringe.

Plane Crazy

Bob’s The Transformation Age

1. I once did a Book Signing at the SD West conference; I believe in 1998. Mind you, I did a “Book Signing”, not to be confused with a “Books Signing”. I signed one book. I bet that copy is worth something. ↩
2. We always seemed to ignore the challenges around the idea of having 100 loose-leaf, one-sided pieces of paper that were this month’s issue of their favorite magazine. ↩

Ofcom Concedes Defeat in the 4chan Case

Insofar as a political organization like Ofcom is even capable of admitting defeat, it did so in the 4chan enforcement today.

In testimony before the Commons Digital, Culture, Media, and Sport Committee, Ofcom admitted it knows its jurisdiction ends where a foreign court’s jurisdiction begins.

“We won’t be able to recover every single fine on online safety. If foreign courts decide to try and get in our way, there will be a point at which we have to accept that we won’t be able to recover that money.”

– Dame Melanie Dawes, Chief Executive, Ofcom

Guido Fawkes characterizes this admission thus: “Ofcom Admits Defeat.”

Guido is right. American courts have, by now, provided their preliminary view on the likelihood of Ofcom’s enforcement powers being successful in U.S. courts – the obiter dicta in 4chan v. Ofcom, the opinion in the case we filed against Ofcom in the federal District Court for the District of Columbia a little over a year ago.

Those dicta made it awfully clear that Ofcom can expect a very chilly reception in an American courtroom if it ever tries to enforce its fines in the United States. By way of reminder, the Court in 4chan said:

Because Plaintiffs represent that they have “no presence, infrastructure, or operations abroad,” Pls.’ Opp’n at 5; Compl. paras. 20, 24, that likely means enforcing any judgment in the United States. At that point, Plaintiffs could avail themselves of the protection of American courts.

Unless Ofcom is prepared to sail a British invasion fleet here and land ground troops, enforcement would indeed have to proceed through American courts. Which presents the following problem for Ofcom:

American courts generally decline to enforce foreign judgments that violate the United States Constitution, if indeed Plaintiffs are correct in their constitutional claims. See, e.g., Matusevitch v. Telnikoff, 877 F. Supp. 1, 4 (D.D.C. 1995) (refusing to enforce a British judgment because it contravened the First Amendment and was therefore “repugnant to the public policies of the State of Maryland and the United States”)[.]

Suffice it to say, 4chan’s constitutional arguments are correct.

The Court then added, gratuitously and sua sponte as this was not an issue which was actually briefed by either party in the case,

Finally, at the risk of gilding the lily, to the extent any foreign judgment against Plaintiffs were penal in nature, Plaintiffs may find a receptive audience before American courts regardless of the judgment’s compatibility with the United States Constitution. That is because American courts are not necessarily required to enforce foreign penal judgments[.]

Put another way, even though the Court ruled against 4chan on the sovereign immunity motion, the Court nonetheless went out of its way to communicate a message to Ofcom in this decision.

That message was: your writ doesn’t run here.

Losing the sovereign immunity motion was a price well worth paying for those dicta on enforceability and their associated deterrent value, especially considering that the only remedy 4chan sought from the D.D.C. – the one the Court couldn’t give due to sovereign immunity – was a declaration of the rights of the parties. What we got instead was the Court’s opinion as to the state of the law, inviting the parties to read between the lines; the substance of what 4chan had asked for, albeit in a different form.

Thus ended this dispute, for all practical purposes. Ofcom can’t enforce the Online Safety Act in America. Ofcom knows it, Ofcom has known it for a long time, and now, Ofcom has, finally, admitted it.

It would be a gift – to 4chan – if Ofcom decided to show up in an American court after all this, waiving sovereign immunity and thus facing the prospect of an adverse merits ruling in the process. Filing that lawsuit would be suicidal, leading to virtually certain defeat and total loss of enforcement credibility in the United States. It will almost certainly never happen, not for 4chan, and likely not for any other American target, either.

Defeat, for all practical purposes, in one matter, however, will not stop Ofcom and British parliamentarians in their continuing mission to censor the British people, and the world. Ofcom has targeted 200-ish American platforms with censorship orders; only four of those sites, all of which are my clients, refused, and only one is 4chan. The First Amendment remains very much under direct, sustained assault from foreign censorship agencies, who rely on their orders to cow U.S. companies who don’t have the stomach for a prolonged and public regulatory fight.

We have a long way to go until our fight with the foreign censors is done. We need permanent U.S. law reform to turn the tide.

The GRANITE Act, a foreign censorship shield now before both the House and Senate (H.R. 10174 / S. 5478), is one proposed legal response America could adopt. The HOMEFRONT Act, H.R. 10309, is another. Either of GRANITE or HOMEFRONT would strip sovereign immunity from foreign censors and let Americans targeted by their orders drag those agencies into federal court, where they could be held accountable for their actions. As we learn from Ofcom’s admissions today, foreign censors won’t start litigation fights they know they will lose.

Ofcom conceding defeat over 4chan because it fears American courts is the entire case for the GRANITE Act.

Ofcom won't do things that generate court losses.

Pass the GRANITE Act, and foreign censors will lose every time they try to censor Americans.https://t.co/ksa6wgVkjG

— Preston Byrne (@prestonjbyrne) October 20, 2026

What will happen next is that Ofcom is going to go back to Parliament to ask for the authority to obtain “interim business disruption measures” – i.e., more or less unilateral censorship powers to block foreign websites in the UK before starting an enforcement process, rather than after. These powers were explicitly rejected by Parliament the last time around and have even now been repudiated by Nadine Dorries, the former MP who introduced the Bill, having seen what a mess Ofcom has made of it. These powers will also be easily defeated through the use of a VPN.

They may also seek to block 4chan. My client has already priced that in and it is a price worth paying, as this will constitute the UK censoring its own people and ISPs, rather than censoring my client. The UK has the sovereign right to do that. My client has the constitutional right to decline to assist the UK in that terrible work.

The UK thus continues its authoritarian backsliding. Sorting out their own country is, ultimately, a matter for the British, and opposing the grant of new powers for Ofcom – an agency which was held off by a pair of American solos working for free – on domestic policy grounds is a task for the growing UK free speech movement to take up, with urgency.

I wish them luck in that important work. In the meantime, we Americans have plenty more work to do on this side of the pond to protect our border and prevent the British, Australian, Russian, and other foreign censorship regimes from crossing it.