His Code Backs Up the World. Now the Internet Wants Him Flogged.

He returned from retirement to save the code under every backup on Earth. The people he protects turned on him for how he did it. He has no regrets.

Photo by Cord Allman on Unsplash

His code runs the backups on nearly every Linux server on Earth, and the sync algorithm he invented rides inside macOS, too. He is retired, and he would rather be out sailing.

Instead, his inbox keeps filling with security reports for rsync, the software he wrote three decades ago. Most of the reports are machine-generated noise. A few are real. He has to read each one to find out which.

So he picked up the same kind of tool that was burying him, and he turned it on the problem.

It worked…

But within days, the same people who depend on his code wanted him punished for how he’d done it.

The 1996 Algorithm Hiding in All Your Backups

In 1996, a doctoral student at the Australian National University had a problem that sounded boring and turned out to be everywhere. How do you copy a changed file across a slow connection without sending the whole thing again?

That student was Andrew Tridgell. Friends and mailing lists know him as “tridge.” He worked out the rsync algorithm with Paul Mackerras, and it does one clever thing.

Two computers each hold a version of the same file. The receiving side carves its copy into chunks and computes a small fingerprint for each one. A fingerprint is a short number derived from the bytes in that chunk, and changing a single byte changes the number. It sends only the fingerprints. The sending side rolls through its own version, matches the existing chunks, and ships only the bytes that changed. A 4 GB file with a one-line edit moves in seconds instead of an hour. Your backup finishes before you wake up.

Credit: Author, How rsync copies a changed file by sending only the bytes that changed

That mechanism is shipped preinstalled on every major Linux distribution and on macOS. I have shipped Linux systems since the early 2000s, and I have never once built a backup pipeline, a deployment script, or a data-migration job that did not call rsync somewhere in the chain. You probably have not either. You just never had to know its name.

The Man Who Accidentally (!) Started Git

rsync was only the start. Tridgell also wrote the first version of Samba, the software that lets Linux and Windows machines share files.

In 2005, he did something that changed how the entire industry version-controls code…

Back then, the Linux kernel team tracked every change to its source code with a commercial tool called BitKeeper. The tool was proprietary, owned by a company called BitMover, but the company let kernel developers use it for free. The free license came with a catch. You were not allowed to study how the tool worked or build anything that competed with it.

Tridgell wanted a free alternative, so a project as critical as Linux would not have to depend on one company’s goodwill. He first had to understand how BitKeeper’s software talked to its server over the network to build one. His method was almost comically simple. He opened a connection to a BitKeeper server and typed the word “help.” That is how you ask any system what it can do. The server answered by printing a list of its own commands. That was the whole of it. The software explained itself because he asked it to.

BitMover saw it as a breach. Connecting to and poking the server that way was exactly what the free license forbade, so the company revoked those licenses for every Linux developer at once. Overnight, the people building the kernel had no tool to manage their code. Linus Torvalds spent weeks trying to broker a truce between the two sides. When that failed, Torvalds sat down and, within days, wrote his own replacement, calling it Git.

Torvalds attacked Tridgell in a public forum post titled “Hypocrisy the worst of human traits,” saying he had “screwed people over” and “tore down something new (and impressive) because he could.”[1] Tridgell, and the free-software developers who backed him, held that he was only analyzing a network protocol as any engineer would, the same kind of work that had built Samba. Both positions are on the record, and the dispute was never cleanly settled, but both sides agree on the result. Every developer who runs git commit today is standing on a tool that exists because of that fight.

So when I tell you Andrew Tridgell is a legend in this field, I am not being generous. He has spent his whole career building the plumbing everyone else relies on. As he puts it: “I’m a software engineer with 40 years experience (yeah, I’m OLD!).”

Wayne Davison took over rsync as primary maintainer in 2002. Tridgell moved on. Davison ran it quietly for two decades, no major breaks, no drama. Good infrastructure does that.

Then the retired man who would rather be sailing came back. His first release landed on January 14, 2025, signed “Andrew Tridgell / rsync maintainer (again!)”.

Twenty-two years of silence, and then a return.

What pulled him back to a project he had handed off before some of its users were born?

A Promise Kept, a Fire Waiting

He came back for Wayne Davison…

Davison had carried rsync alone for twenty-two years, and he ran short on time in April 2024 as life events piled up, so he reached out. “Because various life events have been monopolizing my time, I reached out to Tridge,” Davison wrote. The reaching out cashed in an old promise. Years earlier, Tridgell had told him to call if he ever needed to step back, and Davison made that call. Tridgell kept his word. He returned to honor a twenty-two-year-old handoff, with no idea what was already moving toward him in the code.

The fire was still months away. Three security researchers at Google Cloud, Simon Scannell, Pedro Gallegos, and Jasiel Spelman, sent a private report in late 2024. They had found five vulnerabilities in rsync, and Aleksei Gorban of Loqpa reported a sixth. Six in total. Two of the Google findings, chained together, were the worst kind.

A company runs an rsync server to receive its nightly backups. An attacker connects to that server as an ordinary client. A normal backup job makes the exact same connection every night. But rsync had a heap buffer overflow, a memory bug rated 9.8 out of 10 for severity, and just connecting let the attacker run their own code on the backup server. No password or admin account needed. The Google researchers proved it by building a working attack against Debian 12.

His first job back was to put out the fire. He released rsync 3.4.0 on January 14, 2025, and closed all six holes in a single release. The fix held for exactly one day. Something he had changed broke something else, and he was back the next morning with 3.4.1, patching his own patch. Anyone who has shipped a security fix against a deadline has lived this. You move fast, and the fix you ship needs a fix of its own. That is just what shipping a security fix under a deadline looks like.

Then the reports kept coming… And the nature of them changed.

Reports From a Senior Engineer Who Does Not Exist

“Like many developers of open source packages I’ve been hit by a flood of security reports lately in my role as the rsync maintainer,” Tridgell wrote.[2]

The flood had a new quality. “Many of those reports are AI-generated,” he wrote, “(not all, though, there are some notable ones).”

Somewhere, a scanner points a language model at the rsync source. The model writes a security report. It files it. It does this again and again, with no human reading the output in between. The maintainer opens his inbox and finds new reports that look plausible, with correct formatting and references to functions that exist in the code. Some describe real holes. Most describe behavior the code does not have, written with the calm confidence of a senior engineer who does not exist. Each one has to be opened, read, traced through the source, and confirmed or dismissed by hand, because the one report he ignores might be the one that is real.

That triage is not free. Every hour spent ruling out machine-generated nonsense is an hour not spent fixing actual problems. “As this flood started to get more intense I realised I needed to raise the defences,” he wrote.

Three AIs on the Keyboard, One Human on the Brakes

rsync was old and stable. It was also barely tested. The test suite was a pile of shell scripts, with no real code-coverage analysis and no continuous integration running across platforms. That is thin armor for a tool sitting under nearly every Linux backup and mirror on the planet.

So Tridgell rebuilt the armor. In his words, the project “needed much more thorough test suites, code coverage analysis, CI testing on a lot more platforms…and the addition of a whole lot of defence-in-depth hardening techniques.”

Defense in depth is a security idea older than rsync: stack multiple independent barriers so that getting past one does not get you in. No single check is perfect, so you make an attacker beat several. Tridgell rewrote the test suite from shell scripts to Python, added coverage analysis, and set up continuous integration to run it on far more systems than before.

He used AI for the mechanical work, and he has been specific about which tools and how to use them.

In his words, he “used claude with cross-checks from codex and gemini to do the grunt work.” Claude was the primary tool. Codex and Gemini were the second opinions. And then the human part: “I reviewed every part of it myself and ran through a huge amount of CI time getting it right.”

He drew a hard line on what the visible commits represent. “What you see in the commit history with co-authored by Claude is the tip of the proverbial software engineering iceberg.” A diff does not show the design, the judgment, the review, or the many approaches he tried and dropped before one worked. “I often end up creating new approaches because the existing approach isn’t quite right,” he wrote. The model typed. The engineer decided what was worth keeping.

If you have worked on production code, you know exactly which part of that is the hard part, and it was never the typing.

Credit: Author, How AI flooded rsync with reports and how Tridgell used AI to harden it

The hardening shipped on May 20, 2026, as rsync 3.4.3, closing six more security holes. Tridgell announced it himself on the oss-security list, a separate patch for each hole and a public advisory. It was a careful release, done by the book. The defenses went up fast. A decade of users had bent rsync into shapes few others ran, and the new code found every one of them and drew blood.

This is the work that actually protects your backups, and most of the outrage walked straight past it. If that is news to you, clap so other engineers see it, comment with how your own team tests the tools it depends on, and share it with the person who owns your backup pipeline.

Finished and Sacred, Then Co-Authored by Claude

Somewhere, a team runs a backup script that has gone untouched for nine years. It calls rsync with a combination of flags almost no one else uses. The job runs unattended every night. After the 3.4.3 update, the file copy that always finished clean now exits with an error that no one on the team has seen before. The backup does not complete. The morning shift finds the failure in the log and starts the day debugging a tool they have never had to think about.

That is what a regression in an edge case actually does to people. The common paths held. The new code broke on the odd flags and the configurations people had piled up over a decade.

The reaction was immediate, and it watched the commit history. Through May and into early June 2026, entries tagged “Co-authored-by: Claude” piled up. Dozens of them… Covering CI workflows, test harnesses, and version-mixing checks… This was a violation of a community that had treated rsync as finished and sacred.

On May 30, someone opened a GitHub issue titled, word for word, “Please Do Not Vibe F*** Up This Software.”[3]

The Clean Alternative Failed 85 of 98 Tests

Then, as usual in open source, people started naming the alternative.

The alternative is openrsync, a BSD-licensed reimplementation started by Kristaps Dzonsons for the OpenBSD project. It rebuilds rsync’s behavior from scratch instead of forking the original GPL code, which is why Apple could ship it at all. macOS Sequoia quietly switched to openrsync in 2024 to sidestep the GPLv3 license. Distribution maintainers started talking about following Apple out the door. Alpine Linux, the slim base image that runs a large share of the world’s Docker containers, now packages openrsync and is weighing the same swap.

The angry threads did not lead with this part. Tridgell pointed his new Python test suite, the one he built with AI, at openrsync. It failed 85 of 98 tests. The “clean” alternative passes thirteen.

He was fair about why. Many of those failures are missing features, not bugs. Openrsync does not do everything rsync does, but the framing lands hard anyway. The same test suite that critics treated as proof of rsync’s decay also shows how far behind openrsync is.

“I Have Absolutely No Regrets”

On June 3, 2026, Tridgell published a post titled “rsync and outrage.”

He did not apologize.

He acknowledged the regressions directly. He described his AI usage in detail, the test rewrite, the coverage work, the hardening, what he designed, and what he delegated. He stated his position without hedging: “I have absolutely no regrets about doing that,” he wrote, “although from the storm of anti-AI rage it’s clear that many people think I should be hung up by my toe nails and flogged.”

I have made this exact decision several times on a smaller scale and lived with both outcomes. When a system is on fire, and you are the only one holding a hose, you reach for whatever will move water. Sometimes the tool you grab leaves a mess on the carpet that you spend the next month cleaning up. You still do not regret reaching for it, because the alternative was watching the house burn while you read reports about the smoke.

He is now weighing two paths. A 3.4.4 release that softens the regressions and steadies the edge cases, or a 3.5.0 that goes further, a larger security-hardening push that accepts more change to close more holes.

The regressions are not new. rsync had them before Claude, and it has them after. rsync 3.4.0 did the same thing more than a year earlier. It was shipped, then needed 3.4.1 to fix what it broke, and no AI was anywhere near it. The tool did not get sloppy because a model was involved. Software under a deadline is just like that.

Credit: Author, The inversion of every prior AI and open source maintainer story

The Retiree Holding Up Your Backups

rsync is not a tool you chose. It chose you the moment you bought a Mac or stood up a Linux box. It is underneath your backups, whether or not you ever typed its name.

The man kept the lights on with what he had in private life, and the people who depend on them told him he should be flogged for it.

He has no regrets.

He carried water while the house burned, and the rest of us are still arguing over the bucket’s brand.

But the real argument is that the backups of the entire world still rest on one retiree after more than three decades, while a whole generation pours its money into buying digital football players to win matches online.

If this changed how you think about the tools under your backup, clap so it reaches the engineers who maintain the tools the rest of us take for granted, drop a comment with where you stand on AI-assisted maintenance, and share it with whoever owns your infrastructure.

Your contribution matters! Here is the map of possible actions you can take:

Medium Actions

[1] https://www.realworldtech.com/forum/?threadid=49168&curpostid=49169

[2] https://medium.com/@tridge60/rsync-and-outrage-d9849599e5a0

[3] https://github.com/RsyncProject/rsync/issues/929