6 ms·

Tridge 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 maintai

Tridge 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 4mo ago
I 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 4mo ago
  As 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 4mo ago
Is using calloc for everything fixing a security issue or hardening it?
- ekidd 4mo ago
  Calloc 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 ago
    Uninitialized 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.

Eufrat 4mo ago

I 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 4mo ago
As 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 4mo ago

Is using calloc for everything fixing a security issue or hardening it?

ekidd 4mo ago
Calloc 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 ago
  Uninitialized 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.