
So, not going down with the rship?
Don't panic. Yes, there were a bunch of CVEs, affecting potentially hundreds of thousands of users, found in rsync in early December – and made public on Tuesday – but a fixed version came out the same day, and was further tweaked for better compatibility the following day. There are no known attacks exploiting the flaws in …
1) it does not parallelize transfers and does them one by one using a single core on each end. One a fast, low-latency connection like a LAN, this does not take full advantage of the CPU and network resources to speed things up.
2) transfer is unidirectional. There is another utility called Unison, however, that uses the rsync algorithm to provide bidirectional sync
The primary drawback, imo, is that it doesn't split blocks.
It uses (used) an RC4 hash (a few bytes of an rc4 hash..) of the file blocks looking for matching blocks. Any non-matching blocks, it sends wholesale. It was originally designed to do this given the intent of a high-capacity, high-latency link. Now-adays, we have pretty low latency links, regardless of the capacity, so it makes some sense to split blocks. Even in olden days, "capacity" wasn't that great, so it would still have made a *lot more* of sense to split blocks, almost regardless of latency. (There's a way around that "regardless".)
Take that 1MB initial block size, and split again - faster to round-trip 4 bytes of an RC4 hash than a whole megabyte block. Split it into 512KB, 256, 128, and find the 32KB or so that you need. *As long as you have a queue*, your transfer pipe is full - process hashes first before file data transfer, and keep splitting. When you don't have hashes in the queue, send file data.
This gets you an extra benefit: whether the file is 1GB in size (probably doesn't change so often..) or 100KB in size, hash the whole file. If you're "keeping things synchronized", then your data is probably majority the same - this will save you loads. If you actually need any pieces, split and hash each half. Maybe there's a maximum block size, maybe there's a minimum block size - but one block size for the whole session is not it.
It still doesn't do this, and it's really not that complex a feature to implement.
>It's open source
No it is not - it is licensed under the GPLv3-only, which is a free software license.
Of course everyone is free to submit a patch, which may or may not be accepted, although you're free to instead use your modified version or share it yourself.
"The primary drawback, imo, is ..."
You're starting to sound like a programmer. There must be a thousand ways to improve it, most of which will at the very least add numerous unwanted issues which will take years to iron out.
It Works Fine For Me, and like the vast majority of users I have absolutely no need for it to be improved.
If it ain't broke, don't fix it.
When somebody found it was broke, it got fixed.
The vulnerability finding/reporting/fixing process worked here in textbook fashion, and I'd like to tip my hat to all involved.
Rsync and unison are fundamentally different. Unison understands which direction files should be transferred in and when there is a conflict. That requires keeping a history.
Rsync just looks at the status quo. It will do bi-directional sink perfectly well, but if you are not carefully about what you tell it to do, it will either delete data or restore files that you wanted to delete.
on Port 873.... Using it on Windows with that port with a low privilege user listening on that port is straightforward, not many ways, and works fine. Easy to lock in. But the last time I used in on linux was long ago, when --fuzzy still had some bugs, so is it easier now to run it as non root on port 873? A short search came up with too many, partly ugly, answers. So which is the method you prefer to run rsync on port 873 with a low privilege user?
As noted elsewhere the preponderance of memory safety errors fixed in this release might prompt the rustards to reimplement the application in Rust which wouldn't be a bad thing at all.
RustySink would be as good a name as any.
In these times of huge data volumes rsync's halcyon days might be over (as much the protocol as the application.)
You forgot a tiny detail: He has no official responsibility when it causes damage, cannot be sued. log4j is the latest well known example of this: The original creator and current maintainers got threatened with big lawsuits which would have cost, US-typical, those accused so much they would be ruined for several lives - unless a "gofundme" campaign would have worked - by big-corp-can-afford-lawyers trick. Only the "Do we have a support contract? No. Did you buy it? No." way of communication avoided that, and it being open source was part of it.