6 ms·
Also the amount of commits is suspicious. In the last two months, rsync had about as much commits as in the last two years before that. Most of them written wit
by wolletd 3mo ago
Also the amount of commits is suspicious. In the last two months, rsync had about as much commits as in the last two years before that. Most of them written with claude. And then stuff like this is in there.
That's exactly what I'd expect when someone is excited about AI usage and becomes... well, sloppy.
- logicprog 3mo agoTridge already explains this: "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. " https://medium.com/@tridge60/rsync-and-outrage-d9849599e5a0 https://medium.com/@tridge60/rsync-and-outrage-d9849599e5a0
- Eufrat 3mo agoI think Tridge is simultaneously trying to be proactive and kinda giving too much credit to marketing. Anthropic has not been able to really give numbers or actual values on what Mythos can really do. It just waved Mythos in front of the public like a boogeyman screaming that AI is going to cause a security nightmare (and it has, but mostly through vibe coded trash from what I’ve noticed); I’m hard pressed to find their statement that they spent less than $20,000 to find a Kerberos bug in FreeBSD a compelling win without a lot more context and they seem disinclined to provide that data. I really do wonder what evidence they have provided to their approved partners, all of this smells…weird. 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.
- rsc 3mo agoAs a long-time open-source maintainer, I find all the second-guessing and armchair psychoanalysis here (not just in this comment, all over HN) about Tridge's motivations, state of mind, and so on incredibly off-putting. 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 * The Go 1.25.3 and Go 1.24.9 releases were a fast follow to fix a problem introduced by one of the security fixes the previous week. 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.
- rendaw 3mo agoIs using calloc for everything fixing a security issue or hardening it?
- ekidd 3mo agoCalloc is generally hardening, because it zeros out any stale memory contents left over from previous uses of the memory. You can avoid this overhead if you use a language that forbids reading from uninitialized memory, but C is not that language.
- kelnos 3mo agoUninitialized memory is not a problem (the OS is never going to give a program memory that has data in it from another program). The problem is memory that you allocated in the past, have freed, but hasn't been returned to the OS[0]. It might have key material or other sensitive data in it[1]. Or it might just have random garbage in it that could be misinterpreted by the code that's about to use it, if it hasn't been initialized to a known state. 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.
- ekidd 3mo ago> The problem is memory that you allocated in the past, have freed, but hasn't been returned to the OS[0]. There are at least two different ways in which memory might be semantically "uninitialized": 1. The memory was provided by the OS. On modern desktop and mobile OSes, this memory will normally be zeroed automatically. 2. The memory was provided by the language's allocator. This may contain a mix of data used by previous allocations and memory that has never been touched (perhaps because previous allocations reserved it as end-of-array "capacity" that never got used). From the perspective of a language like Rust, this memory is considered uninitialized, and safe code should never be able to read it without first setting it. In ancient C code, it makes a fair bit of sense to preemptively calloc everything. Or better, to wrap the allocator with one that zeroes on free. Though even there, you need to be careful not to expose recycled heap block headers in the middle of newly allocated objects. My opinion for the last 30+ years has been that C is unfit for purpose, and that using it almost inevitably introduces large numbers of dire security holes. But until the last 10-15 years, there hasn't been any seriously viable alternatives.
- gravypod 3mo ago> Also the amount of commits is suspicious. In the last two months, rsync had about as much commits as in the last two years before that. I wonder if the data looks worse or better when not doing per-10commit and instead do per-commit.
- echelon 3mo agoSeems like someone could use Claude to port rsync to Rust and the whole enterprise would be safer from things like this. Start with unsafe then gradually convert into idiomatic Rust.
- yubblegum 3mo agoYour let's redo this in Rust made me wonder if generative AI will also be susceptible to software fads. One LLM writes a few blog posts extoling a new framework/lanaguge. Other agentics read these and get 'influenced'. Then they start clamoring for 'lets redo this in X!'. Can't wait to see it. /g
- whattheheckheck 3mo agoWe will need rigorous agnostic statistical experiments to know what stuff is better
- globalnode 3mo agoits bad enough when humans do it
- bryanrasmussen 3mo agoPrompt: automate writing commits to increase safety in these software projects so that my profile increases and I can snag a high-paying Rust job. LLM: this commit changes whole codebase to Rust!
- kajaktum 3mo agoYou can get 80% there with rust which is what is impressive. Then you have a reference implementation that you can always check against. If a Rust library have 0 unsafe, i dont care if it is written by a dog, it still have 0 UB.
- klabb3 3mo agoUB is especially bad but also not as big as all other concerns combined. Two of the most reliable software ever to exist, curl and SQLite, are C/C++. There are also cases in system programming, drivers etc where the unsafe is necessary and then your code is only as good as the boundary, and lots of bugs can seep in. Another issue with Rust is ecosystem - the dependency trees required to do fairly basic things are often deep and vast, meaning other risks. That said if something like rsync was written today, I still think Rust may be a better choice. Mainly because a 95 percentile skilled Rust programmer is less dangerous than for C. The people that are skilled enough to be trusted with C are few and diminishing every year.
- lokar 3mo agoI would expect a 10x change rate, even carried out by clones of the existing maintainers to result in more bugs.
- whateveracct 3mo agomythical man month only gets more prescient as time passes