> but it is better understood as exploiting the natural lack of verification in the GitHub web interface, which doesn’t show the authentic (and in this case malicious) source of a module version, as used by actual Go tooling.

That's a load of crap. It can never become a github issue that the Go ecosystem has chosen to make it look like the packages you pull come from github, but are actually diverted to be served by Google from some strange pull-through cache.

Calling this a "lack of verification in the GitHub web interfaces" completely inverts the abstraction layers and asks GitHub to implement specific features for your incorrect usecase.

Then there's the misnomer of a hash database being anywhere close to analogous to PGP signed sources. This is amateur level stuff.

▲

antonvs 4 hours ago | parent | next [-]

FTA:

> “For example, there is no guarantee that the code displayed at https://github.com/example/mod/blob/v1.2.3/exp.go is the actual contents of exp.go from v1.2.3 of module github.com/example/mod: GitHub allows force-pushing git tags and even built its recommended GitHub Actions workflows on top of mutable tags.”

In a sense this is a git issue: the fact that git is mutable instead of append-only. Git wasn’t designed to serve as part of a code integrity system - you’d have to add that at some other level, such as Github.

Or in the case of this example, recognize that tags can’t be secured and implement everything in terms of commit hashes, etc.

▲

embedding-shape 3 hours ago | parent | next [-]

> the fact that git is mutable instead of append-only

Remind me again how I change a commit in the middle of a branch without affecting the commits that come later in the same branch?

▲

arcologies1985 an hour ago | parent [-]

git rebase can do that easily, I do it all the time when prepping feature branches for submission to the main branch

	▲	embedding-shape 18 minutes ago \| parent [-]
		> git rebase can do that easily What exact parameters you use for not changing the latter commits? Must be a very new feature, git's whole idea used to be that commits are on top of the previous ones, rewriting one needs rewrite of all the latter ones.

▲

LtWorf 3 hours ago | parent | prev [-]

> implement everything in terms of commit hashes

And remember, git uses a vulnerable algorithm :)

▲

direwolf20 4 hours ago | parent | prev [-]

You are right. GitHub has nothing to do with this problem — it's entirely on Go.