Rsync and Outrage

st3fan1 pts0 comments

rsync and outrage. I gave up blogging a long time ago… | by Andrew Tridgell | Jun, 2026 | MediumSitemapOpen in appSign up<br>Sign in

Medium Logo

Get app<br>Write

Search

Sign up<br>Sign in

rsync and outrage

Andrew Tridgell

6 min read·<br>Just now

Listen

Share

I gave up blogging a long time ago (apart from an occasional thing about ArduPilot), I tend to just write code and hope people find it useful, so it feels a bit odd to be writing this, but given the volume of rage posts I’ve been on the receiving end of lately I thought maybe I should post something.<br>Like many developers of open source packages I’ve been hit by a flood of security reports lately in my role as the rsync maintainer. Many of those reports are AI generated (not all though, there are some notable ones with very careful and high quality manual analysis).<br>As this flood started to get more intense I realised I needed to raise the defences on rsync a lot — we needed much more thorough test suites, code coverage analysis, CI testing on a lot more platforms, deliberate and thorough scanning for possible security issues (so I find at least some of them before other people!) and the addition of a whole lot of defence-in-depth hardening techniques. This is all a huge amount of work. I’m retired (though my wife may dispute that!) and I’d rather be out sailing than working on rsync security issues, so I have reached for several AI tools to help with what needs to be done. I have absolutely no regrets about doing that, although from the storm of anti-AI rage it’s clear that many people think I should be hung up by my toe nails and flogged for even considering doing this.<br>Trying to answer all of the foaming at the mouth accusations against me would take far too long, so here are just a few:<br>— I rewrote the rsync test suite in python from the old shell script design. I did the design for that myself (and I’m really quite pleased with it), but used claude with cross-checks from codex and gemini to do the grunt work. I did not just vibe-code “convert test suite to python”. I’m a software engineer with 40 years experience (yeah, I’m OLD!), so I did a design first and had a plan for how to validate it. I used AI tools to do the grunt work because they are good at that. I reviewed every part of it myself and ran through a huge amount of CI time getting it right (I’m since moved to having a bunch of local VMs to do most testing to reduce the CI wait time). What you see in the commit history with co-authored by claude is the tip of the proverbial software engineering iceberg.<br>— for the people saying things like “I’m a PhD from xyz uni and I’m telling your LLMs are just stochastic tools that make everything up and the world will fall apart if you use them”, I’m here to tell you that you are out of date. The world of software engineering has changed dramatically in the last few months. The world of IT security and maintaining software in the face of the flood of reports has completely and utterly changed just in the last few weeks. Anything you learned about this stuff last year might as well be from another planet. Oh, btw, I also did a PhD in CS, and yes, I actually did quite a lot of work on neural networks, and yes, all my knowledge from that time in my life is utterly out of date too. Also, nobody actually knows if human intelligence is just finer grained stochastic prediction as well. Maybe some day we’ll work out that, or maybe not. Bottom line is I do know (well, roughly!) how LLMs work, but that doesn’t make them not useful. It does mean you have to be cautious, but I am being cautious, or as cautious as I can be given my desire to be sailing and not dealing with a flood of gunk from so-called internet experts.<br>— yes, there were regressions in some use cases of rsync in the 3.4.3 release. I quite deliberately tried to err on the side of fixing security issues for that release, and there were some valid (but unusual) use cases that got caught up in the changes. None of those cases were covered by the existing rsync test suite or by all the manual testing I did (yes, I use rsync, I don’t just develop it). I am working through those regressions, and I appreciate all the people who have reported them on the github repo as issues or PRs. I do read them even if I don’t respond quickly to all of them. I apologise if your use case of rsync was hit by these regressions. If you don’t mind the security risk then you can of course use an older release.<br>— for those saying “my god, he didn’t use pytest, does he know anything at all!”. I have used pytest extensively in other projects. It isn’t a good fit here. There is stuff I need to do in this test suite that would be very hard to do in pytest (at least based on my experience with it), so I designed the right approach for the specific task. I’ve done that all my life, I often end up creating new approaches because the existing approach isn’t quite right. I personally think this is a good thing to do.<br>Now to the future,...

rsync from security work time people

Related Articles