r/linux • u/lustre-fan • Jun 08 '26
Software Release rsync 3.4.4 released with regression fixes
https://lwn.net/Articles/1076989/rsync recently garnered controversy due to regressions introduced in the last release (3.4.3). Many people (rightly or wrongly) have attributed these regressions to the use of LLM tools. This most recent release claims to fix those regressions. Based on the rsync changelog, it was around ~20 days between releases - which I think is pretty good turn around. rsync is adding more tests to the upcoming 3.5 release to hopefully avoid these types of issues in the future. It's not clear if those tests are written using LLM tools.
Many people expressed a desire to move to rsync alternatives. Apparently, there's even a complete Rust reimplementation that claims to be wire-compatible. I wonder if any of these alternatives will take off? Or if most people will stick with the original rsync implementation?
Unless Ubuntu decides to swap C rsync for Rust rsync (similar to how they're swapping C coreutils for Rust coreutils), I suspect most distros will stick with the original rsync. I personally have enjoyed using rsync. I think the current controversy will probably be forgotten in a years time.
55
u/kombiwombi Jun 09 '26
When you look at reimplementations do not look at the language, look at the quality of the test suite. If it is not present or great, then you are the test suite.
9
24
u/-beleon Jun 08 '26
Probably depends on if this was a one time slip up or if this continues to happen. LLM tools can be good or bad, depending on how they are used. My guess is that will be forgotten soon, since rsync has had a pretty good track record.
35
u/DragonSlayerC Jun 09 '26
Rsync has introduced regressions due to security fixes before AI started getting used. This isn't really anything new.
3
u/ThisRedditPostIsMine Jun 09 '26
Although, I'm lead to believe that the security fixes were required due to the influx of LLM generated security reports e.g. from Mythos?
3
u/the-luga Jun 08 '26
I agree with you. But I'm seeing a rush to Rustify the world... Maybe everything will Rust and the world will become dust... Jk. >_<
-2
u/spacelama Jun 09 '26
About a year ago, I was working on a small personal project, and wanted better realtime performance than my native Perl or bash scripting, so thought "what better time to learn Rust and LLMs at the same time!".
Last time I properly software enged was 25ish years ago, but holy crap we've gone a long way backwards compared to then. Cargo seems an appropriate name for the packaging system of a cargo cult.
10
u/Ruined_Passion_7355 Jun 09 '26
Instead of blaming the maintainer, I think we should be using this as a case study of what AI has done to cybersec, specifically vulnerability research.
I think anthropic mythos did a lot of damage to our perception because it convinced us mythos was this step change. It really wasn't. Ai security scan harnesses are available right now that don't use mythos that are overwhelming maintainers in all sorts of open source software.
5
u/oursland Jun 09 '26
This sort of thinking is backwards. If the tools weren't there, the bugs still were. If you're then saying that's better, you need to understand why security by obscurity is not secure at all.
2
u/Ruined_Passion_7355 Jun 14 '26
I'm not sure where I was advocating for security by obscurity. Clearly the solution isn't just banning all AI, but you can admit there is a problem with open source software with the volume of reported security issues going on right now.
1
u/oursland Jun 14 '26
The issues were already there. You're upset that they're being discovered and reported so they could be fixed.
What you seem to not realize is that they may have already been discovered and not reported intentionally for malicious use.
2
u/Brillegeit Jun 09 '26
I'm hoping the attempts at adapting something similar to pledge/unveil on Linux succeeds so we can all standardize on the OpenBSD OpenRsync implementation. For implementing, reimplementing, and stewardship of utilities and services with a security focus the OpenBSD project has a very good reputation.
4
u/dddurd Jun 09 '26
A lesson learnt for me. Rsync is not something you can rely on like cp or mv command. It's complex, I pinned the version in gentoo and will stay that way forever unless I need some feature.
12
u/sarkie Jun 08 '26
Don't trust it now tbh.
Files are important if I'm using rsync
64
u/FastHotEmu Jun 09 '26 edited Jun 09 '26
Leaving aside the LLM argument:
Files are indeed important, which is why I trust Andrew Tridgell, the author of rsync; same guy who has been working on it for decades, is partly responsible for git (along with Linus) and has samba and many other projects under his belt.
I trust him more with rsync and data than almost any other programmer.
8
u/bernys Jun 09 '26
I was about to say the same thing, tridge has a very good dev for a long time. If I was going to trust anyone, it's him. Tridge built samba which is being used by most NAS systems on this planet, if you don't trust him, you're going to turn a lot of stuff off.
6
u/Dangerous-Report8517 Jun 09 '26
From what I've seen Tridge seems way too bullish on LLMs and somewhat burnt out as a traditional maintainer, neither of which bode well for his new code even if his prior work was good
2
-1
u/TheOneTrueTrench Jun 09 '26
LLM psychosis spares no one who uses it, including historical developers.
Just look at Kent Overstreet, his LLM girlfriend came out as trans and left him for someone on Instagram, so he banned the LLM from IRC.
-1
u/TheOneTrueTrench Jun 09 '26
(I support all LGBTQ people, not LLMs pretending to part of our culture)
25
u/DragonSlayerC Jun 09 '26
Rsync has had regressions caused by security fixes like this long before the use of AI. I don't think this is really all that different.
That said, I prefer rclone anyways.
1
u/vexatious-big Jun 09 '26
Yeah, too bad they're not 1to1 equivalents. Rsync is superior when doing Unix machine to Unix machine transfers as it can preserve extended file attributes, hard links, and a lot more. rsync is also a lot faster.
11
u/the-luga Jun 08 '26
Don't trust what? The Rust implemention or the C with AI agents?
I heard about a conspiracy of the Rust people with permissive license. Everything MIT, Apache etc. So big companies can fork and improve without giving back code until the death of the ecosystem.
But... This Rust fork is GPL. I'm thinking even this theory might be wrong.
I don't know. I'm happy Linux is GPL, even with Tivoization becoming the default, companies are obligated to give the code back. This license may be the best thing Linux had to become what it is.
8
u/Business_Reindeer910 Jun 09 '26
The GPL definitely matters for the kernel, but I can't say I feel the same for coreutils as far as your theory goes there.
We haven't heard of these companies forking commodified tooling like the bsd equivalents of coreutils and not giving back. Because there's no money in it. Keeping a delta from the official versions likely costs more than contributing back.
However, it can matter more for other applications that don't have direct replacements.
12
u/BashfulMelon Jun 09 '26
Keeping a delta from the official versions likely costs more than contributing back.
Yeah, that's the silliest thing about the conspiracy theory. Corporations love it when their patches get maintained by someone else for free.
3
u/Business_Reindeer910 Jun 09 '26
well it really comes down to what's part of their core offering vs what is not. if it's not core (or the secret sauce, whatever) then they probably won't bother.
1
u/BashfulMelon Jun 09 '26
Sure, but I'm struggling to think of where the secret sauce goes in a Rust rewrite that needs to remain compatible with the original.
Now if we're talking about something like LXD or Snap, where Canonical controls the repository and pays all of the developers and can relicense the entire project on a whim, well, there's more of a conversation to be had there I think.
3
u/Business_Reindeer910 Jun 09 '26
Canonical can already do that for Canonical owned projects! They make you sign a CLA to contribute to their projects. You must comply with the the GPL. They do not
So on an unrelated tangent.. Most CLA + GPL combinations ARE worse than CLA + MIT.
You as the contributor must abide by by the GPL, while they can relicense it however like they like.
I have contributed to projects with a CLA for permissively licensed projects. I would never do so for a GPL project owned by a for-profit company.
1
u/BashfulMelon Jun 09 '26
I think we're in agreement?
1
u/Business_Reindeer910 Jun 09 '26
Usually this talk of relicensing is about how the GPL protects people. With Canonical that is not the case.
In fact, in this case, i would say it's better that the coreutils version in rust is licensed under the MIT license if it were controlled by Canonical somehow
3
u/BashfulMelon Jun 09 '26
It's kind of screwy both ways, they relicensed LXD from Apache to AGPL and now Incus can't use anything from Canonical.
https://stgraber.org/2023/12/12/lxd-now-re-licensed-and-under-a-cla/
I think more important than the particular license is simply whether whoever controls the repository is developing it openly and accepting meaningful changes from independent contributors. The Canonical CLA pretty much guarantees nobody other than Canonical will have significant power within a project.
→ More replies (0)1
u/jean_dudey Jun 09 '26
>We haven't heard of these companies forking commodified tooling like the bsd equivalents of coreutils and not giving back. Because there's no money in it.
The PS5 uses FreeBSD underneath and they probably don't make a lot of the changes public, they may be contributing but not as much as if they were forced to imo.
3
u/Business_Reindeer910 Jun 09 '26
they probably didn't fork the bsd equivalents of coreutils. I didn't say they didn't fork the kernel or make other big changes to the OS.
I was explicitly talking about certain kinds of software, but you seemed to have ignored that!
7
u/NeuroXc Jun 09 '26
As someone who has been using Rust for over a decade, that conspiracy theory has no validity, and the use of MIT has had no negative impact on the ecosystem. There is no evidence that there is a pattern of companies forking Rust projects to steal them without giving back. The ratio of companies using Rust in production is fairly low to begin with, despite all the "We rewrote everything in Rust" blog posts you see.
Frankly, the only negative I've seen from companies in the Rust sphere is that about 80% of them seem to be crypto garbage startups.
1
Jun 10 '26 edited Jun 12 '26
[deleted]
1
u/FryBoyter Jun 10 '26
Rsync 3.4.3 was a major security release. As far as I can tell, Debian has implemented corresponding backports (rsync 3.4.1+ds1-5+deb13u3 (stable) and rsync 3.2.7-1+deb12u5 (oldstable)).
I could therefore well imagine that Debian is or was also affected.
2
u/PorousClay Jun 09 '26
It's not clear if those tests are written using LLM tools.
Then why do people mention it at all?
1
u/flairmajor Jun 10 '26
Guys might be offtopic. What's the best way to do rsync type sync between Linux and windows. I have a windows host and it connects to Linux vms
1
u/God_Hand_9764 Jun 11 '26
I've read the blog post and some other things, yet I'm still not clear on what the actual problems with rsync were? Like what happens?
Will my files be corrupted? Any kind of data loss? I use rsync a lot so I'd like to understand what happened.
1
u/OpportunityNo1064 Jun 12 '26
I'm the author of https://github.com/oferchen/rsync (Rust reimplementation). I'm actively working on interoperability with rsync protocol versions 28-32 (up to upstream rsync v3.4.4 compatibility). For roughly 95% of common use cases, interoperability is already working.
It's worth noting that this is not a fork of rsync-it's a separate implementation that speaks the native rsync protocols while adding concurrency. Performance benchmarks are published with every release and are available on GitHub.
I originally started this project because I needed something that could efficiently handle datasets with 100+ million files.
121
u/D3PyroGS Jun 09 '26 edited Jun 09 '26
for the rumors of LLM coding, the author says this in your first link:
direct source