proxy.golang.org allows many Go packages to be silently broken August 6, 2021 on Drew DeVault's blog

GOPROXY (or proxy.golang.org) is a service through which all “go get” commands (and other module downloads) are routed. It may speed up some operations by providing a cache, and it publishes checksums and an “index” of all Go packages; but this is done at the cost of sending details of all of your module downloads to Google and imposing extra steps when using Go packages from an intranet.

This cache never expires, which can cause some problems: you can keep fetching a module from proxy.golang.org long after the upstream version has disappeared. The upstream author probably had a good reason for removing a version! Because I set GOPROXY=direct in my environment,1 which bypasses the proxy, I’ve been made aware of a great number of Go packages which have broken dependencies and are none the wiser. They generally can’t reproduce the problem without GOPROXY=direct, which can make it a challenge to rouse up the enthusiasm for upstream to actually fix the issue. Caching modules forever can encourage bitrot.

Packages which have these issues cannot be built unless Google keeps the cache valid forever and can be trusted to treat the personal data associated with the request with respect. Furthermore, as soon as a debugging session finds its way to an absent module, you could be surprised to find that upstream is gone and that fetching or patching the code may be a challenge. This has created ticking time bombs throughout the Go ecosystem, which go undetected because GOPROXY hides the problem from developers.

If you want to check if your packages are affected by this, just set GOPROXY=direct in your environment, blow away your local cache, and build your packages again. You might uncover an unpleasant surprise.

It may be worth noting that I already have a poor opinion of the Go module mirror — it’s been DDoS’ing my servers since February.2 Since I reported this, the Go team has been very opaque and non-communicative, and none of their mitigations have had a meaningful improvement. Most of the traffic is redundant — many modules are downloaded over and over again in short time intervals. I have the option of blocking their traffic, of course, but that would also block all Go programmers from fetching modules from my service. I hope they adopt my recommendation of allowing admins to configure the crawl parameters via robots.txt.

But, to be honest, the Go module mirror might not need to exist at all.

P.S. Do you have feedback on this post?

I said, in Cryptocurrency is an abject disaster, that I wanted to make my blog more constructive. As it necessarily required a critical tone, this post might have broken this promise. Taking extra care to avoid this, I made an effort to use measured, reasonable language, to address specific problems rather than making generalizations, and to avoid flamebait, and I sought second opinions on the article before publishing.

I would welcome your feedback on the results. Was this post constructive? Should I instead refrain from this kind of criticism in general? Do you have any other thoughts to share? Please email me if so.


  1. Mainly for practical reasons, since it busts the cache when I need to fetch the latest version of a recently-updated module. ↩︎

  2. I SSH’d into git.sr.ht just now and found 50 git clones from the Go module mirror in the last 30 seconds, which is about ⅓ of all of our git traffic. ↩︎

Have a comment on one of my posts? Start a discussion in my public inbox by sending an email to ~sircmpwn/public-inbox@lists.sr.ht [mailing list etiquette]

Articles from blogs I read Generated by openring

Summary of changes for November

Hey everyone! This is the list of all the changes we've done to our projects and apps during the month of November. We'll also be reporting in our on position in the world, and on our future plans. Summary Of Changes Donsol, designed a donsol tu…

via Hundred Rabbits December 1, 2021

Announcing chat.sr.ht: a persistent IRC session for sourcehut users

About one month ago, we began a private beta for chat.sr.ht, the next flagship sourcehut product. Starting today, this service is now available to all paid sourcehut users. chat.sr.ht is a hosted IRC bouncer service, which maintains a persistent IRC connectio…

via Blogs on Sourcehut November 29, 2021

Major errors on this blog (and their corrections)

Here's a list of errors on this blog that I think were fairly serious. While what I think of as serious is, of course, subjective, I don't think there's any reasonable way to avoid that because, e.g., I make a huge number of typos, so many tha…

via danluu.com November 22, 2021