Even great programmers can be terribly misguided [LWN.net]

Even great programmers can be terribly misguided

Posted Jun 3, 2026 13:20 UTC (Wed) by bignose (subscriber, #40)
Parent article: Tridgell: rsync and outrage

Andrew Tridgell:
> This is all a huge amount of work. I’m retired (though my wife may dispute that!) and I’d rather be out sailing than working on rsync security issues […]

Certainly, it's a huge amount of work, that I wouldn't want anyone to do in a rush. The solution to this is the same as it's been for decades.

Responsible stewardship must include a good succession plan, well ahead of retirement from the project. If you can't keep up with the work, please don't do it badly.

Tridge is no more immune to self-delusion than any other human. His LLM-generated changes resulted in a rash of new regressions. But he insists, in the face of that evidence, that the LLMs helped him do better work.

You did a great thing in starting and basically perfecting this project, Tridge. Please, step away now and let humans do the careful work necessary.

to post comments

Even great programmers can be terribly misguided

Posted Jun 3, 2026 13:37 UTC (Wed) by alex (subscriber, #1355) [Link] (1 responses)

It's a classic FLOSS problem but there was a succession plan and the previous maintainer retired and handed the reigns back to Tridgell. While there are now people on the brigaded issue trackers offering to take over maintainership I doubt it would be responsible to hand the project over to some random github handle without seeing the quality of their work.

There were a lot of commentators who were sure the reason for the regression was LLM usage but precious few willing to do the work to identify the offending commit or redo the CVE fixes on an "LLM free" branch of the code.

Even great programmers can be terribly misguided

Posted Jun 3, 2026 19:47 UTC (Wed) by raven667 (subscriber, #5198) [Link]

> It's a classic FLOSS problem but there was a succession plan and the previous maintainer retired and handed the reigns back to Tridgell.

This is the part where I think the most issues are, when big companies ship volunteer-created code (that they found on the Internet) for commercial purposes, then they need to be responsible for the long-term maintenance and security of that code, and can't just defer to the original volunteer maintainer as an accountability sink. "No warranty express or implied for any purpose" is not really ethical for widely-deployed software but no one person can/should be held accountable for all the ways something like rsync is being used, so you can't just forward all CVEs to Tridgell and say "job done", he _can't_ fundamentally accept that responsibility, its too much.

I think it'd be healthy for orgs which ship FOSS to others if they planned on forking and having some vendor consortium to handle maintenance, like Linux Foundation, that might hire the original maintainer, but can also develop a team capable of handling the responsibility incurred when shipping code in products to other people. The idea that major software projects should be organized around individual BDFLs seems crazy to me now that FOSS is such a part of modern infrastructure.

I think there might be some resistance from FOSS maintainers though, a lot of people are attached to the prestige that comes with creating a successful project (eg "my code is interplanetary because it's on the Mars Rover"), but we don't organize other human infrastructure projects around individual engineers, we don't design airplanes or bridges that way, and while small projects the equivalent of building your own garden shed don't require a lot of rules, because the potential harm is low, the more people affected the more responsibility for safety exists and the less its fair to have borne by individuals and should instead be borne by organizations, institutions, culture, etc.

Even great programmers can be terribly misguided

Posted Jun 3, 2026 13:40 UTC (Wed) by darthcloud (guest, #111462) [Link] (2 responses)

I'm not a fan of LLM use, but it's his project, so he get to deside what he does with it. Unhappy? Fork it!

Even great programmers can be terribly misguided

Posted Jun 3, 2026 14:48 UTC (Wed) by rsidd (subscriber, #2582) [Link] (1 responses)

Drew DeVault (who forked Vim recently) has forked it. Or, no, he hasn't. He just says use tar and ssh instead.

Oh, and he says this because "apparently rsync is slop now". Without considering whether someone with Tridge's decades of experience would ever put out "slop".

Even great programmers can be terribly misguided

Posted Jun 3, 2026 20:43 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

Heh. Yeah, we have `rrsync` in use to not allow arbitrary execution on the production host. Authentication is via SSH key which is limited to a single location (so you need multiple keys to access multiple locations). Much more auditable than allowing `tar -C` and symlink considerations.

Really, `rclone` would be the better alternative suggestion (though I'm not aware of its "infection" status with LLM output to know if that is also discounted).

Even great programmers can be terribly misguided

Posted Jun 3, 2026 14:29 UTC (Wed) by nhippi (subscriber, #34640) [Link] (1 responses)

> His LLM-generated changes resulted in a rash of new regressions

More like his security bug fixes (reported with help of LLMs) caused regressions that were not catched by the testsuite despite the testsuite being significantly expanded (with help of LLM).

That is hardly news that closing security holes causes regressions - some because users relied on insecure behavior, some because maintainer went overboard when closing the hole and disabled valid usecases too.

Even great programmers can be terribly misguided

Posted Jun 5, 2026 0:27 UTC (Fri) by cesarb (subscriber, #6266) [Link]

> That is hardly news that closing security holes causes regressions - some because users relied on insecure behavior, some because maintainer went overboard when closing the hole and disabled valid usecases too.

I was hit by one of these recently. A recent CUPS release fixed a bunch of vulnerabilities (https://github.com/OpenPrinting/cups/releases/tag/v2.4.17), and the fix for the first one in that list was so broken that it needed to be repaired not once (https://github.com/OpenPrinting/cups/releases/tag/v2.4.18) but twice (https://github.com/OpenPrinting/cups/releases/tag/v2.4.19). In the middle of tax filling season in my country. And the computer connected to the printer didn't have a user account with the same username as the user account being used to do the taxes on the other computer. The log messages weren't exactly helpful.

(The workaround, once I found https://github.com/OpenPrinting/cups/issues/1557 which explained the issue, was: print to PDF, and copy the file to a user account which has the same username as an account which does exist on that computer connected to the printer. Printing from that user account worked fine, which was really confusing until I found the explanation that the username somehow matters, even though it's not authenticating to the server at all.)

Even great programmers can be terribly misguided

Posted Jun 3, 2026 14:43 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (5 responses)

> Tridge is no more immune to self-delusion than any other human. His LLM-generated changes resulted in a rash of new regressions. But he insists, in the face of that evidence, that the LLMs helped him do better work.

You assume it would have been any better without using LLMs. I doubt it. The way new models find security bugs is forcing hurried rewrites on rsync-like projects, and those have never been regression-safe.

Right now the security researchers are focusing on high-visibility FLOSS projects like curl or rsync, which have first-class maintainers like Tridge. As soon as those projects fix their security debt and it gets harder to earn some quick fame the same tools will be turned on average projects (the ones no one bothered auditing seriously so far because it was too much manual work). And then all hell will break lose.

I doubt the maintainers of projects that relied of the tediousness of manual auditing to ship average code will be able to pull a Tridge and perform a rewrite, complete with test suite rewrite, in a hurry (not to mention how easy it has become to import a babel tower of third-party components, that will need fixing at every level, with the same regression risks).

And the next stage of hell will be when LLM analysis will progress to decompile proprietary code. Those guys definitely have zero plan on how to deal with mass analysis of binary code, and would not know how to ship fixes to their customers if they had to. It’s turtles all the way down, their binary blobs use other people’s binary blobs and they could not fix those even if they wanted to because no source code access and no licensing right even if they wanted to. What happens to security by obscurity when the obscurity gets torn down? No one knows but I guess we’re all going to find out pretty soon.

Even great programmers can be terribly misguided

Posted Jun 3, 2026 19:44 UTC (Wed) by ballombe (subscriber, #9523) [Link] (4 responses)

> You assume it would have been any better without using LLMs. I doubt it. The way new models find security bugs is forcing hurried rewrites on rsync-like projects, and those have never been regression-safe.

If a fraction of the money spent on LLM has been used to pay maintainers of critical project, the situation would be different.
Cue to Ted Tso quote: https://lwn.net/Articles/1074105/

Even great programmers can be terribly misguided

Posted Jun 3, 2026 23:37 UTC (Wed) by jwarnica (subscriber, #27492) [Link] (1 responses)

Ted might very well have been busy making sure some huge insurance companies last print run works on the second try.

Either way, insofar as he isn't living in a box, when he does have free time he can work on his hobby.

The problem is that it is a hobby, not that he can afford to have a hobby

Even great programmers can be terribly misguided

Posted Jun 13, 2026 14:27 UTC (Sat) by tytso (✭ supporter ✭, #9993) [Link]

When I started at Google over 15 years ago, the deal was that I could spend half my time working on ext4, and half my time working on Google specific issues. These days, the ratio has shifted quite drastically. But the problem is I'm not unique. Oracle has laid off 30,000 engineers in the last six months. Amazon has laid off 30,000 engineers as well, after one of their most record-breaking profitable quarters. The numbers for the Facebook/Meta layffs aren't as clear, but Meta laid off 7800 people in May and transferred another 8,000 to AI specific roles. It's been quite clear that the Oracle Linux department has been gutted, and many people who attended a recent Linux invite-only workshop needed to get travel scholarships because their company was no longer willing to fund them --- or they no longer had a company.

At that workshop, I talked to two people from Facebook that were now doing AI infrastructure projects as their primary role, and I'm aware of one engineer from Samsung which couldn't attend because he was moved from Filesystem work to (you guessed it) AI Infrastructure projects. I suspect there is something about people who have experience in Systems work, either in the proprietary or open source context, having a good set of skills for building AI Infrastructure in the great AI race.

If I could win enough money in a lottery or receive some other windfall so I could self-fund doing Linux kernel work full time, I would do that. But the reality is that this is a terrible environment for engineers to find jobs, and we shouldn't be too judgemental and self-righteous over people preferring to have food with their meals.

Even great programmers can be terribly misguided

Posted Jun 4, 2026 1:04 UTC (Thu) by AdamW (subscriber, #48457) [Link]

Sure it would. But that being a fact doesn't *help* anybody. Nobody is, in fact, offering to spend all those trillions of dollars on F/OSS maintenance, so we must live in the world as it is.

Even great programmers can be terribly misguided

Posted Jun 4, 2026 8:04 UTC (Thu) by NYKevin (subscriber, #129325) [Link]

If we had some ham, we could have ham and eggs, if we had some eggs.

Even great programmers can be terribly misguided

Posted Jun 3, 2026 20:02 UTC (Wed) by geofft (subscriber, #59789) [Link]

> Responsible stewardship must include a good succession plan, well ahead of retirement from the project. If you can't keep up with the work, please don't do it badly.

The amount of commitment required to "keep up with the work" has skyrocketed out of almost nowhere in the last couple of months. Quite possibly we'll get to a steady state where we've resolved all the bugs that were unintentionally added over the past 30-40 years and we aren't adding new bugs at the same rate (especially for a "done" piece of software like rsync). But I don't think this is a fault of a bad succession plan, any more one can look at the kernel security team or the curl maintainers now drowning in valid bug reports being found by LLMs at a rate much higher than humans reported them, and say this is the fault of a bad non-succession plan.

Even great programmers can be terribly misguided

Posted Jun 13, 2026 14:16 UTC (Sat) by tytso (✭ supporter ✭, #9993) [Link] (1 responses)

What people may have missed was that Tridge handed of the maintenance of rsync 22 years ago to a long-time collaborator, Wayne Davidson, with the promise if he needed any help, to let Tridge know. Twenty two years later, with Tridge literally retired from his day job and sailing and working on open-source drone software for fun, Wayne had some personal issues and asked Tridge for help, and so Tridge stepped back into the maintainership role, keeping a promise he made over two decades ago.

Just as he stepped into that role about 3 months ago, the rsync security emergency happened. So instead of criticizing Tridge for bad judgement, how about commending him for stepping back in when the maintainer that he had handed it off to couldn't continue on? What would you consider a better outcome? If someone like Jia Tan had volunteered to step in instead?

Plus one informative

Posted Jun 13, 2026 21:34 UTC (Sat) by Klaasjan (subscriber, #4951) [Link]

Hear, hear!