Growing convinced we could and should ship new version cooldown in the Go modules ecosystem.

[filippo@abyssdomain.expert]

Growing convinced we could and should ship new version cooldown in the Go modules ecosystem.

The subdb and MVP get us far, and supply chain attacks are not much of a thing in Go beyond typosquatting, but we want to stay ahead of them.

proposal: cmd/go: support dependency cooldown in Go tooling · Issue #76485 · golang/go

Proposal Details Background Supply chain attacks on open-source software dependencies have become a regular occurrence. Go already takes measures against supply chain attacks. While Go libraries aren't a common target, this year GitLab d...

GitHub (github.com)

[cks@mastodon.social]

@filippo My experience is that I've seen multiple cases where dependabot updates raced with the dependency re-publishing a different thing under the same tag. The result was something that would only build if you used the proxy (which had cached the original published version). This is obviously bad practice (possibly in multiple places), but I think it suggests a cooldown would be useful even with MVP.

(Also maybe dependabot needs a cooldown itself, but ... good luck persuading them.)

[markd@hachyderm.io]

@filippo If cooldown becomes common would that mean that supply chain attacks would mostly affect early adopters who presumably are more sensitive to the risks?

[drwho@masto.hackers.town]

@filippo But then coders will go back to node.js!

[raggi@don.rag.pub]

@filippo we should work on review attestation, given mvs I don’t think this will have a ton of impact

[filippo@abyssdomain.expert]

@cks Editing a tag is indistinguishable from an attack, so it will never work, cooldown or not. The cooldown clock starts when the sumdb captures the first contents, which then are it forever.

[filippo@abyssdomain.expert]

@markd Why wouldn't clients that are most sensitive to risk adopt a longer, instead of shorter, cooldown?

[filippo@abyssdomain.expert]

@raggi Review attestation is one of those things I heard talked about for all of my career and never once saw implemented successfully at scale. Even at large companies with employees!

There's a fundamental incentives problem which I mostly saw ignored or anyway unsolved.

[cks@mastodon.social]

@filippo Sorry, I didn't manage to say my actual thought. I think the dependabot race shows that today, people are updating rapidly as soon as new versions become visible to them, even with MVP. So slowing down visibility through a cooldown would buy time.

[raggi@don.rag.pub]

@filippo seeing Google finally publishing rust ones gives me hope. We need to keep breaking the seal, not let people freak out, and just get on with it

[cks@mastodon.social]

@filippo This has made me think of a little attack that's basically a reverse tag replacement attack:
* get access to a repo and publish a compromised version with a new version tag
* get the Go proxy to fetch and cache your new version
* force-push an innocent version under the same tag

People will look at your repo and see harmless code under the tag, but I believe actual 'go mod' updates use the proxy's cached version (compromised) and its cached sum, unless you force upstream use?

[filippo@abyssdomain.expert]

@cks yep see https://words.filippo.io/go-source/

There is no “unless you force an upstream fetch” though: unless you turn off the sumdb there is only one true version. The issue is using an unverifiable view like the GitHub UI to try to view it.

Not different from any other ecosystem though: plenty of malicious npm packages with innocent code on GitHub.

[cks@mastodon.social]

@filippo If you force an upstream fetch you get a big fatal error about the checksums not matching (which will detect the substitution). Otherwise you'll pull without any way to discover that the upstream and the proxy don't match.

(I force pulls of upstream for my own eccentric reasons so I get to see this every so often.)