
And no doubt now, with the news coverage mentioning the typosquatted URL, LLMs will be parroting it as the real URL
I am amazed that Go have not removed it yet, but then again, there are not many humans left at Google
A security researcher says a backdoor masquerading as a legitimate Go programming language package used by thousands of organizations was left undetected for years. Kirill Boychenko, threat intelligence analyst at Socket Security, blogged today about what seems to be a supply chain attack on the BoltDB database module, which …
Ok, I'll bite (and let you point out my gross ignorance of serving up files):
It may appear as though counting the number of downloads might[1] be of interest in judging the impact of this problem[2], but aside from that possibility, you seem to be very certain that they should be tracking all the individual downloads even when/if everything is all hunky-dory.
Can you please explain why? What would they - Google or all the devs using Go - get from doing that?
They aren't (AFAIK) using this mirror to, say, build a list of most popular downloads this week, they very explicitly aren't looking to only mirror the 1000 favourite packages (and saving space by deleting the rest). It isn't something humans are supposed to be excited about reading and starring their favourites.
For what purpose - and at what level of detail - would they need to be tracking to avoid being "clowns" when it comes to running an immutable cache server?
[1] it is a cache - does 100 downloads indicate 100 separate projects hitting it, 100 people/build machines all on the same project or 1 person who isn't bothering to keep a local copy? What is the cost of trying to track and separate those cases - and what would be the use of that data to warrant the cost of gathering and keeping it?
[2] back to cost and likelihood of that spend actually helping (other than making for an exciting headline).
You mean the one to steal crypto keys from er, at least 7 people?
Although yeah, not really taking off, which is fortunate.
What I mean is, said crypto scheme ought to be investigated as a possible source of the fake package. If they are the sole project on GitHub using it, then it is more than a little suspicious that they might not be innocent victims.
Since I'm spending more time fiddling with go, I was interested in how go would deal with a malicious package once reported.
The answer is https://pkg.go.dev/vuln/ -- this issue is the third one down.
GO-2025-3451
Affects: github.com/boltdb-go/bolt
Published: Feb 05, 2025
The issues are reported by the govulncheck tool which I guess should be part of most go-related CI pipelines.
The source repo (github.com/boltdb-go/bolt) has also been disabled so it doesn't work for "go get" module retrieval.