Sequoia’s New rsync
Michael Stapelberg (in January):
With macOS 15 Sequoia (released in September 2024), Apple has started shipping openrsync (created by Kristaps Dzonsons, from OpenBSD) as an alternative to the original rsync (“tridge”, from the Samba project).
When you run “rsync”, a wrapper will inspect your command and dispatch to either
/usr/libexec/rsync/rsync.sambaorrsync.openrsync.If you need one version over the other, select them explicitly — and probably
rsync.sambawill disappear eventually…How did I notice this? A formerly working transfer of mine broke (starting an rsync daemon via SSH).
Over 660,000 exposed Rsync servers are potentially vulnerable to six new vulnerabilities, including a critical-severity heap-buffer overflow flaw that allows remote code execution on servers.
It doesn’t seem to be documented, but Apple’s fix for this was to remove rsync.samba from macOS 15.4. The wrapper that Stapelberg linked to is now gone, though it lives on in the Git history.
Without going in-depth into the background legal issues, the reason for not providing rsync 3.x is that Apple decided that while it could comply with the terms of GPLv2 license with regards to rsync 2.x, it could not comply with the terms of GPLv3 license with regards to rsync 3.x.
What this has meant for macOS is that it has been shipping with a version of rsync which was last updated in 2006. While Apple has been updating the rsync 2.6.9 command line tool it shipped with macOS as needed in response to security issues and other problems, the fact remains that Apple’s version of rsync up until macOS Sequoia was almost twenty years old and did not include any of the new features introduced in rsync versions which came after version 2.6.9.
Now with macOS Sequoia, Apple has replaced rsync 2.6.9 with openrsync, an implementation of rsync which is not using any version of the GPL open source license. Instead, openrsync is licensed under the BSD family of licenses, specifically the ISC license.
Looking at the sparse documentation of openrsync does not create any confidence for me that it can be an acceptable substitute for rsync.
It seems to work fine for my purposes, but certainly a lot of the features are not supported.
Really annoying that Apple is more committed to being stubborn shout GPL than actually shipping good software that doesn’t randomly break people’s workflows
Openrsync aims for compatibility with modern rsync, but accepts only a subset of rsync’s command-line arguments. We have seen problems using this openrsync build with the SBGrid Installation Manager.
I updated a MacPro from Ventura to Sequoia and now the
rsynccommand have problems when wrapped in a script.
I have several directories with thousands of files that I synchronize to my Mac using rsync. With Sequoia Apple has switched to a new rsync -- I can tell because the verbose output has changed. But this rsync has a bug that shows up on both Intel and Apple Silicon. This has been persistent across all versions of MacOS 15 to date, and on two different Macs.
rsync has both -I and -c which promise to not use the quick method and instead will run a checksum on the files. It’s slower so you won’t want to do this normally, but it’s not a bad idea to add this to the mix of things that you do every so many rotations.
Previously:
- macOS 15.4
- Apple’s Dormant CUPS
- Mojave’s rsync From the Days of Tiger
- An Aging Collection of Unix Tools
9 Comments RSS · Twitter · Mastodon
I wonder if this accounts for a problem I've had with incoming rsync connections. A Linux box periodically rsyncs JPGs from a camera to my Mac. Frequently I get extra junk files-- if the photo were named photo1234.jpg, I'll have that, plus one called something like photo1234.qeMG24Ohbs. The file contents are identical. I keep needing to go clean up the junk files.
Apple has taught me through very harsh lessons never to rely on any of the command line tools that ship with macOS. This is not a good thing, and one of the myriad examples of how the operating system is decaying.
Should have just stopped shipping rsync, sheesh. Probably didn't make contributions, either, since who remembers how to use cvs ;-)
View included command line utils as Apple dependencies, not independent tools. The lag behind official releases, dumb Apple quirks, and possibility of being pulled in any release is not a reliable foundation.
@rajs has the best advice.
The new rsync seems to have broken --backup-dir for me, so I ended up disabling that feature.
As well, one of my daily rsyncs seems to fail with an assertion every other time it runs.
So yeah, not thrilled with the change.
"Really annoying that Apple is more committed to being stubborn shout GPL than actually shipping good software that doesn’t"
Is that what's happening, or are they just genuinely properly adhering to the licensing restrictions?
@Plume: My understanding is the concern is that if the ship anything that is GPLv3 with the OS, it will apply to the entire thing and they will have to open up everything. Not sure if that would actually happen, but they also don’t want to test it. Also, Apples devices are pretty locked down and the main difference between GPL2 and GPL3 is the anti-TiVo-ization clauses, iirc.
@Plume This is an old issue, but I have yet to see a good explanation for why Apple should be OK with GPL 2 but not GPL 3.
@gildarts Why would the anti-TiVo-ization be a problem for macOS?
