rsc

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

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.

The $20K was the total across all the files scanned, not just the one with the bug.

Worth noting these were not written as rules of programming generally but rules specifically targeted at complexity. They are lifted from the "Complexity" section of Rob's "Notes on Programming in C".

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

Raises hand.

FWIW, the versions are not semver but they do follow a defined and regular version schema: https://ai.google.dev/gemini-api/docs/models#model-versions.

[Also posted to Lobsters: https://lobste.rs/s/ms94ja/what_is_go_proxy_even_doing#c_vz2...]

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.

This is a strange and dangerous thing to try to do from assembly. In particular, all these details about write barriers being hand-coded in the assembly are subject to change from release to release.

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).

The parent comment is the first time I've said anything publicly (it has only been a few weeks). I didn't feel like it needed an announcement, but since it came up, it seemed worth correcting. It's not a state secret. :-)

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.

Officially, I have left the Go team too; I started on a new team at Google a few weeks ago. I still use Go quite a bit, I still talk to people on the Go team regularly, and you will still see the occasional code change, code review, or blog post from me. Most importantly, I have high confidence that the team we built will do an excellent job continuing the work.

Those are semantically different (one is nil and one is not) but neither allocates.

Not sure what the betrayal is? He contributed a quote for yesterday's post. https://tailscale.com/blog/tailscale-enterprise-plan-9-suppo...

We had to do some Plan 9 work, which makes sense when doing something new, but the actual Tailscale implementation is far _less_ work than for other Unixes.

https://docs.rs/txtar/latest/txtar/

In the link in the parent comment. :-)

People who go install it get an error that it's not a valid source tree at all.

While you can create and build a local package with U+FE0E in its file name, you cannot create or download a module using that character in a file name. So you could run this attack in someone's top-level repo but not in any of their dependencies. That's something at least.

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

No. It's just Go assembly. (It happens to be a Plan 9-derived syntax, but we call it Go assembly.) See https://go.dev/doc/asm.

I replied to the other copy of this comment: https://news.ycombinator.com/item?id=41136122.

This is definitely not true. "Inside of Google" would have been just linux/amd64 for a very long time. Now it includes linux/arm64 too, but that port happened before Google needed it. And all the other ports are not used inside of Google, except maybe the Mac port if you count developers laptops.

If you just want to run Go programs on Alpine, it works fine. (I put some effort in back in Go 1.21 to make sure that the downloaded binary toolchains for Linux even work fine on Alpine.)

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.

Happy to hear that. Still going to write and think. :-)

https://www.youtube.com/watch?v=ek1yjc9sSag&list=PLrwpzH1_9u...

I don't intend to make more of those, but that was a lot of fun.

Me too!

The wording may be a joke but the concept is real and widely used.

https://research.swtch.com/deps#watch_your_dependencies

Creeping dependencies can also affect the size of your project. During the development of Google’s Sawzall—a JIT’ed logs processing language—the authors discovered at various times that the main interpreter binary contained not just Sawzall’s JIT but also (unused) PostScript, Python, and JavaScript interpreters. Each time, the culprit turned out to be unused dependencies declared by some library Sawzall did depend on, combined with the fact that Google’s build system eliminated any manual effort needed to start using a new dependency.. This kind of error is the reason that the Go language makes importing an unused package a compile-time error.

There were certainly buggy tests that relied on the old behavior. We didn't find any actual code that relied _correctly_ on the old behavior.

https://go.dev/wiki/LoopvarExperiment

rsc, thank you very much for all the hard work on the language that brought me into software engineering.

You're quite welcome, and thank you for this comment. I never expected when we started that Go would have such a positive impact on people's lives, bringing new people into programming and software engineering. That's definitely the impact I'm most proud of.

Both Austin and Cherry are relatively unknown outside Google and are to my knowledge not active in the community outside Google.

I don't believe this is true at all. They are both highly active in external Go development, far more active than I have been these past few years. (It's true that neither gives talks or blogs as much as I do.)

I would frame it differently: stack hash bisect is only suitable where your code is linked into some other large program that you don't understand, and when your changes can be toggled on a per-invocation basis. Then you can use it to identify the exact stack through the larger program that leads to your code and works with the old behavior but breaks with the new behavior.

(saagarjha seems to be talking about 'git bisect', which is not really what the post is about.)

The assumption is that for a given test program, the call stack used at the specific moment where the failure begins is the same each run. If that's not true, there will be problems.

If there are two different call stacks that get to the function in question, but only one of them is where the failure begins, you absolutely want to distinguish those.

In practice we do cut off the stacks, using just 16 frames, but that's to avoid O(stack depth) overhead, not to coalesce different things.