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.

https://www.lysator.liu.se/c/pikestyle.html http://www.literateprogramming.com/pikestyle.pdf

I apologize for the traffic. We clearly need to look at the “thundering herd” you are observing. That shouldn’t be happening at all.

Separately, the bug we fixed last time were about repeatedly cloning a repo in sequence even if it was unchanged, not about redundant parallel fetches. We fixed that only for Git, because Git makes it very easy to look at a branch or tag and get the tree hash, without downloading the full repo. This is exposed as the go command’s -reuse flag. The relevant Git code is at https://go.dev/src/cmd/go/internal/modfetch/codehost/git.go#... (CheckReuse).

What we need from any VCS to implement the reuse check is a cheap way to download a list of every tag and branch along with a cryptographic file tree checksum for each one, without doing a full repo clone. At the time, I convinced myself Mercurial did not support this. Perhaps I was wrong or perhaps it does now. If anyone can help us understand how that works, we could implement the -reuse flag for Mercurial too. (Any other VCSs would be great too, but Git is #1 by a very wide margin and I believe Mercurial is #2 also by a wide margin.)

Again, apologies for all the traffic, and thanks to Ted for the excellent analysis. We will look into both.

Better to structure your code so that you do the pointer manipulation (and allocation) in Go code instead, and leave assembly only for what is absolutely necessary for performance (usually things like bulk operations, special instructions, and so on).

In my August announcement, I was careful to say I wasn't leaving the Go project. I'm still involved with the Go project and expect to keep being involved. I'm just not officially on the Go team at Google anymore. Stepping back from the actual team to give others room to lead always seemed to me both likely and appropriate.

https://go.googlesource.com/mod/+/refs/heads/master/module/m... https://go.googlesource.com/mod/+/refs/heads/master/module/m...

If you want to use c-shared mode and dlopen, then yes that only works with glibc, but that mode barely works at all anyway. It's not actively supported at all.