"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 honestly think the main problem is Tridge just failed at communicating any of this correctly and I don’t think the implication he gives that all of this was due to the urgency of the impending security apocalypse really holds water.
Why was all of this written straight to the master branch? Now that the release is out, why not better explain what the urgency of this release was? Why wasn’t he proactive in communicating this and instead let the mob make up their own story? I think a lot of people are inclined to give Tridge a lot of leeway due to the fact that he literally is the reason why rsync exists, but this was avoidable and I think the comment in his response post where he mentions that, “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,” speaks volumes as to what is going on.
Tridge doesn't owe anyone anything as far as rsync is concerned. Yet he is spending his time maintaining it, only to be attacked for his efforts.
To respond to the specific technical point, there really _is_ a flood of security reports arriving everywhere in the past few months. The jury is out on whether Mythos is that much better than alternatives, but even the publicly available models are _highly_ capable of finding real problems, and they are being employed to that end quite effectively. Here are the counts of security issues fixed in each monthly Go minor release going back to the start of 2024:
0 2024-01-09 Go 1.21.6, Go 1.20.13
0 2024-02-06 Go 1.21.7, Go 1.20.14
5 2024-03-05 Go 1.22.1, Go 1.21.8
1 2024-04-03 Go 1.22.2, Go 1.21.9
2 2024-05-07 Go 1.22.3, Go 1.21.10
2 2024-06-04 Go 1.22.4, Go 1.21.11
1 2024-07-02 Go 1.22.5, Go 1.21.12
0 2024-08-06 Go 1.22.6, Go 1.21.13
3 2024-09-05 Go 1.23.1, Go 1.22.7
0 2024-10-01 Go 1.23.2, Go 1.22.8
0 2024-11-06 Go 1.23.3, Go 1.22.9
0 2024-12-03 Go 1.23.4, Go 1.22.10
2 2025-01-16 Go 1.23.5, Go 1.22.11
1 2025-02-04 Go 1.23.6, Go 1.22.12
1 2025-03-04 Go 1.24.1, Go 1.23.7
1 2025-04-01 Go 1.24.2, Go 1.23.8
1 2025-05-06 Go 1.24.3, Go 1.23.9
3 2025-06-05 Go 1.24.4, Go 1.23.10
1 2025-07-08 Go 1.24.5, Go 1.23.11
2 2025-08-06 Go 1.24.6, Go 1.23.12
1 2025-09-03 Go 1.25.1, Go 1.24.7
10 2025-10-07 Go 1.25.2, Go 1.24.8
* 2025-10-13 Go 1.25.3, Go 1.24.9
0 2025-11-05 Go 1.25.4, Go 1.24.10
2 2025-12-02 Go 1.25.5, Go 1.24.11
6 2026-01-15 Go 1.25.6, Go 1.24.12
2 2026-02-04 Go 1.25.7, Go 1.24.13
5 2026-03-05 Go 1.26.1, Go 1.25.8
10 2026-04-07 Go 1.26.2, Go 1.25.9
11 2026-05-07 Go 1.26.3, Go 1.25.10
3 2026-06-02 Go 1.26.4, Go 1.25.11
You can see that 2026 has been quite different from the previous years. There are plenty of other contemporaneous accounts from other security teams about the load increase they've seen (which again is almost entirely not Mythos).
Also, the number of reports we are receiving has gone up far faster than the number of actual vulnerabilities. Over the 75-month period from January 2020 to early April 2026, the final 30 days accounted for ~16% of the reports.
It is easy to believe that Tridge is seeing a similar flood of reports. More reports means more fixes means more code changes means more bugs.
Which, in general, is totally legit. Doing something voluntarily doesn't relieve you from criticism if what you are doing isn't good.
Recent examples are certification validation logic, one issue after an another... because it's a mess of thing to implement.
> More reports means more fixes means more code changes means more bugs.
Sounds like we'll be riding a downward spiral for the foreseeable future? It will be very interesting to see how stats like the ones you shared develop in the coming year(s).
From the article I find this a bit concerning:
> So: the Claude releases changed way more lines of code than historical ones, but didn't have more bugs. More code, same bugs. That's not what you'd expect if Claude were making things worse.
More code, same bugs, is a net negative, no? I mean unless it's strictly needed for the inherent complexity of the program. But I've seen a tokenizer written by Rob Pike and I've seen a tokenizer written by Claude.... they are not the same :D
Much of the language from both groups is incredibly off-putting, frankly. Tridge in his blog post describes people as "foaming at the mouth"?!
The rhetoric around this has gotten way too emotional from both groups.
I'm glad I'm just a hobbyist.
I agree that the entire episode is obscene, but I am also unsure of what to do here either. On some level this is the same problem movie stars run into. I agree that guessing or waxing about the motivations of anyone is a nosy and overall unproductive exercise (yet paparazzi exist because of this very human behavior), but I also think that there is a modest duty owed to users to explain things.
> Tridge doesn't owe anyone anything as far as rsync is concerned. Yet he is spending his time maintaining it, only to be attacked for his efforts.
I am reminded of this piece: https://mikemcquaid.com/open-source-maintainers-owe-you-noth...
Which, I empathize with, but I fundamentally disagree that maintainers owe users nothing. I will die on that hill. If you are getting to that point where you actively loathe working on the project, I agree you should be able to walk away. However, I strongly believe that when you create something for people to use that there’s an implicit social contract about how to go about doing certain things.
I suppose in a very extreme and intentionally histrionic example, having a project carry the MIT license, getting frustrated and then changing the project to delete the entire system is a crime. The average person and the courts don’t care if the license is “as-is”. There is a duty that is understood that you don’t do that and I think we need to make it clear what that duty is for OSS.
Ultimately, though, I think this is all symptomatic of the fact that the OSS model has gaps that the increase in security reports whether AI generated or not has exerted more pressure on. I have certainly been on the receiving end of a lot of frivolous security reports that were discarded because it was obvious that it was just someone with a security scanner wandering around the Internet. You still have to review that nonsense and it eats into your time. Doing this on your own time, without pay and having to listen to the peanut gallery is just infuriating.
Is any business built on top of rsync going to donate their money in a sustainable manner?
Well, then maybe it's already overdue to find a new maintainer for the project and let someone else continue it? The tool will not get better from someone working on it who doesn't want to.
> Luckily I’ve been joined by some other very good developers with great systems development skills and security knowledge... Watch out for some credits for some great new rsync developers in the next release.
The person owning the project is using the master branch in the way he sees fit.
Incidentally, there is no amount of communicating "correctly" that quells a mob. There's a Venn diagram of concerns, and those with concerns not being met will generate (now infinite) outrage.
You can avoid this overhead if you use a language that forbids reading from uninitialized memory, but C is not that language.
For some uses, you do genuinely need (specifically) zeroed-out memory before you start to use it, and that's where calloc() is truly useful. But that need not have anything to do with security.
[0] The allocator will often hold onto memory that has been freed in order to quickly service future requests for new allocations, without needing a context switch into kernel space.
[1] Granted, the correct way to handle that is to zero it out before freeing it, in a way that the compiler won't optimize out.