FRESH

Hacker News

Home

Rsync 3.4.3 has hundreds of Claude commits

83 points by fooker

by himata4113

2 subcomments

Looks fine? most of the commits are tests, ci, docs and issues that could cause memory corruption / hidden bugs rather than any new feature development. Of course it's unfortunate that it caused this bug to surface and it would be curious to investigate exactly why this happened, maybe the "safe" c operations have different (unexpected) behavior instead of immediately pointing out that "ai bad". I think patching issues that could cause future CVE's is pretty important especially because rsyncing a file -> client compromise could be pretty devestating as it often runs unsandboxed.
Everyone is still learning how and how much AI should be used and we shouldn't be too harsh on opensource developers. (edit: if someone hears "you are irresponsible if you don't let claude review your code", it would be pretty natural to let AI review your code and fix issues without knowing the full implications of it)
I suspect this commit: https://github.com/RsyncProject/rsync/commit/4fa7156ccdb2ad3..., appears to be changing behavior and changes like these shouldn't be in a patch version (unless it's an active security exploit).

by Tiberium

0 subcomment

Reposting some of the (likely) bad commits with issues open against them, just to show that this isn't a one-off:
- https://github.com/RsyncProject/rsync/commit/4fa7156ccdb2ad3...: https://github.com/RsyncProject/rsync/issues/905 https://github.com/RsyncProject/rsync/issues/900
- https://github.com/RsyncProject/rsync/commit/1d5b5ab83af84db...: https://github.com/RsyncProject/rsync/issues/924
- https://github.com/RsyncProject/rsync/commit/859d44fa4f14207...: https://github.com/RsyncProject/rsync/issues/897
- https://github.com/RsyncProject/rsync/commit/30656c5e358b1c6...: https://github.com/RsyncProject/rsync/issues/896 https://github.com/RsyncProject/rsync/issues/915
- https://github.com/RsyncProject/rsync/commit/8112445318a35e4...: https://github.com/RsyncProject/rsync/issues/910 https://github.com/RsyncProject/rsync/issues/927

by Tiberium

1 subcomments

Currently there are 130 Claude-coauthored commits, and the maintainer seems to not be engaging with any of the recent issues and just pushing more of the "security in depth" fixes that are breaking real features for people.

by stock_toaster

1 subcomments

Maybe time to pursue alternative implementations[1].
[1]: https://michael.stapelberg.ch/posts/2026-05-24-minimal-memor...

by eunos

5 subcomments

It's rather ironic that in profit making enterprises using AI are not only encouraged but also part of KPIs. But in open source it's scourge

by solarkraft

3 subcomments

So they’re just kind of implying a relationship between the 2 things?
Maybe there is one, but it doesn’t support the underlying “and that must mean AI bad” hypothesis as much as the author may think.
Somebody on the Rsync team has a new tool. They may have neglected their traditional responsibilities using it, but that’s not really a fault of the tool.

by jasonvorhe

2 subcomments

So, has anyone actually checked if it's just an issue with 3.4.3? Going to back to 3.4.1 skips 3.4.2 which features many contributions that aren't either by Andrew or Claude.

by jasonvorhe

0 subcomment

The first actually constructive attempt of figuring out the root cause can be found in this issue: https://github.com/RsyncProject/rsync/issues/897

by My_Name

1 subcomments

This is a problem of insufficient checking happening in-between a PR being made, and it being committed.
Imagine you have a low quality coder in your coders, they produce a lot of code, but while some of it is fine, some of it is... dubious. That is no different from an AI and the way you deal with it is the same. You check the PR before committing it.
To allow PRs from them (or anyone really) to get merged without proper checking for bugs etc is just sloppy repo management. The problem is not "AI bad, human good", it is that a human is allowing PRs through to release without properly checking them.

by sph

1 subcomments

I reckon we will soon see a growing movement of maintainers forking popular open-source projects to the point before vibecoding was introduced to the development process.
I can definitely see myself supporting this. Vibecoding promotes the uncontrollable growth of features, and thus bugs, when the vast majority of software benefits from stability. It should be possible to be done with development, barring security patches and bug fixes.

by mariopt

0 subcomment

I suspect that many of the new cute CLI tools that people are vibecoding will turn into malware given some time.
Seeing this happening in trusted CLI tools makes me wonder what will happen to Linux

by abc123abc123

0 subcomment

Who cares? Is the quality good? Bug free? Readable? If so, I couldn't care less who developed the code.

by firtoz

1 subcomments

I see that people are recommending rclone instead

by blurbleblurble

1 subcomments

Maybe he got notified from the mythos team of a bunch of vulnerabilities and then followed up using claude. Doesn't seem that unlikely.
What would you do if suddenly there were a dozen exploitable CVEs in your highly used open source project staring you down? Maybe you'd use the tool that found them to patch them as quickly as possible.

by vbtechguy

1 subcomments

What's the difference between experience a human made bug versus an AI made bug in software?

0 subcomment

by devinprater

0 subcomment

Meh, I wonder how many Claude commits iOS, MacOS, or Windows has that we just don't see?

by CursedSilicon

1 subcomments

I saw an exceptionally long and thoughtful post on Mastodon from "Space Hobo" https://teh.entar.net/@spacehobo that definitely deserves reprinting here
-----
I actually worked at the same place as Andrew Tridgell, over a quarter-century ago. I got to know a few of the OzLabs folks during their immediate post-IBM years, and always had the highest respect for them in that way where you feel acute impostor syndrome when they're in the room.
Tridge almost walked backwards into implementing the Windows SMB protocol (he was just debugging some funny NetBIOS extensions IIRC). But his paper on the #rsync algorithm was groundbreaking, and actually writing the tool to implement it was brilliant. It's become one of those tools like #curl that just forms one of the major structural supports of the modern Internet. I still remember the day that the SSH transport became the default, and I remember being able to thank him in person when he came to the San Francisco office (although IIRC by that point he'd handed control of rsync over to mbp).
I remember at my next job he came to a summit of folks working on print driver/spooler software. When he pointed out that some problems were effectively a cache-consistency algorithm, we all kind of put our fingers to our temples and said "Oh wow, you're SO right!" He was always insightful and sharp, while being gentle and approachable.
I write in the past tense because I haven't crossed paths with him in two decades, and only know what I see him put out. A friend of mine in Australia noted that he hasn't posted to the Canberra LUG list since 2020, thanking someone for congratulating him on receiving the Medal of the Order of Australia. He's very much alive, but from what little I see I grow concerned for him.
In 2024 he took over maintenance of rsync once more. The 3.3.0 release was the last one from the previous maintainer, and Tridge is currently working on 3.4.x releases.
Well... Tridge and #Claude, it seems: https://mastodon.gamedev.place/@JeremiahFieldhaven/116654345...
The issue tracker for rsync has recently lit up with regressions, showing features that worked reliably for almost 30 years are suddenly coming crashing down in 3.4.2 and 3.4.3. People are scrambling to find ways to pin rsync to known-good versions. The considerate, incisive mind I briefly knew is letting the stochastic parrots do his work for him, and it just seems so astonishingly unlike the person I met back in the day.
I am still willing to give him the benefit of the doubt. I hope all is well for him, but I will not cast aspersions on his goals or his abilities. No, instead I draw this conclusion:
If TRIDGE of all people can't handle #LLMs without a slopocalypse, no one can.
That means you. That means someone you admire who is intelligent and careful and considerate. Not even someone whose opinions on technology you respect a great deal.
-----

by einpoklum

0 subcomment

Oh, no :-(
I was hoping that at least some solid bedrock of stadalone command-line tools would withstand the deluge of AI slop.
Will we need to start to label programs with a "written by humans" sticker? :-(

by Ozzie-D

0 subcomment

[flagged]

by zx8080

0 subcomment

LGTM, ship it.
/s
Is there any sign of enough code review this release got?

by megous

0 subcomment

Well, there's 1 +claude commit prior Mythos/Glasswing announcement and the rest are after the announcement. Take of it what you will.
Anyway, seems blown out of proportion. There are a few issues in the tracker, some repeated or obscure. Linux 5.10, really? You want to run frankenkernel from 5 years ago with 30 000+ patches never meant or developed against it applied on top? Good luck. Rsync is least of your worries.
Linux stable, especially these 5 year old trees are mostly a pacifier for companies that don't want to upstream and maintain their drivers and keep up with evolving internal kernel interface. It's nothing good for users, technically.
And I guess if I clone the repo and do a diff against pre-claude and claude assisted state, most of the changes will not be in the actual C code.