rsync and outrage

# rsync and outrage Source: [https://medium.com/@tridge60/rsync-and-outrage-d9849599e5a0](https://medium.com/@tridge60/rsync-and-outrage-d9849599e5a0) [](https://medium.com/@tridge60?source=post_page---byline--d9849599e5a0---------------------------------------) 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\. 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\)\. 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\. Trying to answer all of the foaming at the mouth accusations against me would take far too long, so here are just a few: — 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\. — 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\. — 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\. — 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\. Now to the future, because we’re not done yet by a long shot\. The security reports keep rolling in\. I’m working on a bunch of CVEs right now\. Luckily I’ve been joined by some other very good developers with great systems development skills and security knowledge\. Some of these people came to my attention partly because of all the rage happening at the moment, so I get some rage storm clouds have silver linings\. Watch out for some credits for some great new rsync developers in the next release\. I’m trying to decide at the moment between a 3\.4\.4 release that softens some of the regressions and going for the 3\.5\.0 that I had planned with much larger changes\. The 3\.5 release will raise the bar enormously with regards to rsync security, but it is a huge change\. The large change set that is needed was a big motivation for the effort on the test suite rewrite — you can’t do a rapid large change to a piece of software like rsync without a really comprehensive test suite\. I thought it would be a good idea to do the core structure for the new test suite in public on master first though given all the rage that has generated maybe that was a bad idea\. Anyway, the new test suite has helped a lot, and I have a big pile of additional tests for security related issues that you can all enjoy reading when 3\.5 comes out\. I’m hoping \(perhaps naively\) that with this push at the moment I’ll get ahead of things and the flood will turn into trickle then dry up\. I can dream\. Now if any of the people posting the rage stuff want to actually review any of the code I’ve published and make constructive criticisms then that would be great\! If you just want to rage some more then I’m sure you can find some corner of the internet where that would be welcome\. As to all the people saying “I’m going to package openrsync for platform XXX and we’ll use that\!”\. I find that rather amusing\. If you do decide to go down that path I’d suggest you try the new rsync test suite on openrsync if you can stomach something that an AI has helped write\. I tried it today and openrsync currently fails 85 of 98 tests, so I’m sure it won’t take you long to get it up to speed\. You run it like this “\./runtests\.py — rsync\-bin=\.\./openrsync/openrsync — use\-tcp”\. Admittedly a lot of the failures are just features openrsync doesn’t have, but still, it’s not a great result\. To finish up, I had a good laugh when I came across this page the other day[https://www\.tridge\.com/](https://www.tridge.com/)so it seems that maybe I’ve actually been a robot all my life, maybe that is why I don’t hate AI tools quite as much as others\.