Tridgell: rsync and outrage

The way I see it, wide-scale, heavily subsidized and somewhat naive[1] use of LLMs has removed all of a sudden a lot of friction from within systems and processes. Removing friction sounds great if you want to move faster and get things done more quickly. But try walking without friction. Heck, try stopping without friction, it can be exhilarating. Or terrifying, depending on how much you prefer not to break your limbs. A few months ago, I suddenly noticed that the street where I live is actually quite steeply sloped downhill. Coincidentally, I arrived at this conclusion while trying to cross it when there was suddenly a lot of black ice covering it end to end. Never had to do the kind of "swing-by a lamp post and use the neighbors trashcan as a sort of angular momentum barrier" maneuver before. And I hope to not have to do it again. It made me appreciate friction a lot more.

The habits, processes, systems, and culture we are living with and in to create the things that are important to us have been established over a long period of time when friction was there. For better or worse, we have actually built the stuff we rely on with the inherent friction in mind. It is kinda insane (and frankly bewildering) to me that we expect systems that have been calibrated with and around friction to suddenly adapt to environments with a lot less friction involved. It is also somewhat sad to see people denying that there are downsides of suddenly switching it effectively off (or replacing it with frictions that are different, like "I can't justify the expenses of buying computer hardware to hack anymore because the world has gone crazy, so some projects I wanted to do are now on the back-burner") and pretending that there is no moral or ethical component to the wide scale shifting of habits, processes, systems, and culture. :shrug:, I guess?

Cheers,
szm

[1] As in "build unfathomable capacity with no regard for economic sense, ecological restrictions, ethical concerns and other "boring" things that start with the letter e; unleash it on society without discussion and deliberation or even a plan except to somehow either brute force your way to something akin to "AGI" and/or to maximise profits" naive.

You were asked by this site's owner to stop "This sort of name-calling". Please respect that request.

* People looking to move from closed source to FOSS, or start in FOSS, will find it more difficult because they have no established history.
* Somebody will create a Hello World project whose sole purpose is to collect stars and grant contributor status to as many people as possible. GitHub will have to do something about that, and all options are bad in one way or another.
* Real projects will get more bad pull requests from people who don't know what they're doing.

I am a long time rsync user - I thank you for the hard work you've put into this over the last 30 years. It is my go-to tool, not just for copying between hosts over SSH, but also copying recursively on a single host (rsync -rlpt sourcedir/. destdir/. always "just works").

From my perspective what matters is being able to "trust" that rsync will work correctly - and not contain malware.

I have three actual concerns at the moment:

1. Replacing the test suite all at once removes an old, stood-the-test-of-time test suite with one that merely has to be trusted to be correct and hasn't yet achieved that status. If I wanted to change a project's testing framework, I'd do it like this: create the new framework, but leave existing tests in the old one; then, moving forward, add all _new_ tests to the new framework, and when actively changing a test (as part of actively changing some behavior), take that moment to move that test on its own to the new framework. Then, ensure that "running tests" runs both old and new. After some years, there will eventually come a point where the remaining old tests are a small enough fraction of the total that moving them over all at once is not such a risk. Why has rsync not kept the old framework as well as adding the new one? and/or, would it be realistic now to reintroduce the old framework exactly as it was (in such a way that a git diff tells you the old one is unchanged) and run both in parallel for some time?

2. Binaries have been committed into the repo. These are purportedly old versions of rsync for the purposes of testing, and, my hope and expectation would be that they actually are. However; this is a red flag. Binaries are where one can easily hide malware. Ideally, a repo should not contain binaries; if the test framework needs such binaries it should compile them on the fly from what's in the repo, and any number of caching techniques can be used to avoid this compilation having to happen over and over again. Why have binaries been introduced in this case in preference to caching? and/or, would it be realistic now to remove them and switch to a caching technique?

3. When one looks at the history, one sees a flurry of activity over the last two months, compared to relatively slow activity before that. Why was this sudden speedup in development necessary? rsync is mature software; one would expect it should not need anything other than targeted security fixes.

While I would like to think that the user called "tridge" on GitHub is indeed the same person they have always been (and is, presumably, you!), I don't know that person; I don't know that the account hasn't been compromised; I don't know that they haven't been socially engineered. You mention the Jia Tan episode - the parallel to what happened there is now both worrying and ironic. Personally, I don't really care directly about the involvement of claude - what I'd like to see is that, whether or not AI is involved, diffs remain small and targeted, and thus more visibly trustworthy.

I've seen some of the commentary on GitHub and it's absolutely vile and very much not the right way of going about things, and I'm sorry that you have to put up with all that. But at the moment, from a logical/objective perspective my intuition is, due to the sudden change in development methodology, very much aligned with the camp of "don't upgrade past 3.4.1 and hope for a serious fork of that version that gets small, targeted security fixes moving forward" - and it would be, I am a Debian user, currently still Debian 12 at that :). I believe others may share my concerns, but in what I've read, amidst all the shouting about LLMs, I haven't seen them clearly enunciated.

If someone is accessing public rsync servers, where each endpoint is controlled by a different party, the protocol is an important security boundary. In the other case of running rsync over an authenticated ssh transport, the protocol is less of an issue, since the user has the same privileges on the remote system as the rsync instance.

I'd score the vulnerabilities quite differently for those two use cases, and for the second use case I can see why regressions outweighed the benefits of the security fixes.