Inspecting the Source of Go Modules

See also https://github.com/golang/go/issues/66653 (that I don’t think is linked from the article)

philipwhiuk 2 hours ago | parent | prev | next [-]

I've always found it very weird that GitHub's tolerated being completely subverted to become a package manager for ecosystems that can't be bothered to manage it themselves.

NPM doesn't just proxy to GitHub (even though both are owned by Microsoft).

To see maintainers criticise GitHub for not being a perfect package manager is lunacy.

▲

FiloSottile an hour ago | parent | next [-]

There is no criticism of GitHub in the post, aside from throwing a bit of shade at them using mutable git tags for Actions instead of actually building a package manager.

The lack of verification of ecosystem-specific authenticity is natural, as the post says, in reading source directly from any code host.

NPM has the same problem if you click through to the source repository and expect what you read to match the package. It’s been used to hide attacks in that ecosystem in the same way, and the NPM web UI recently added a code browser similar to the one in this post.

If anything, the extra upload step of NPM (and similar centralized registries) makes things worse by encouraging and normalizing publishing different source from what is in the VCS.

▲

bspammer 2 hours ago | parent | prev | next [-]

That’s fair, but GitHub themselves do it with GitHub Actions. Versioning of all official actions is done with git tags, which has always made me uncomfortable.

▲

embedding-shape an hour ago | parent [-]

> GitHub themselves do it with GitHub Actions

That makes sense, so does doing releases by using tags, why would that make you uncomfortable?

What doesn't make sense, is creating a completely new language/framework/package manager and decide to place the package registry burden on someone else.

▲

formerly_proven an hour ago | parent [-]

> That makes sense, so does doing releases by using tags, why would that make you uncomfortable?

Tags are not immutable.

▲

embedding-shape an hour ago | parent [-]

Are you confusing tags with branches? Git tags for all intents and purposes are immutable. If you have a tag in your local repository that was pulled down from another remote, and the remote changes the tag and you update your local repository, it'll reject the incoming tag.

It's true they're both refs inside git, but git literally treats them as "shouldn't move", unlike branches. They're not immutable in the technical sense, so I guess you're technically right. But they're not used the same way as branches, and the tooling won't like that either.

	▲	bspammer 32 minutes ago \| parent \| next [-]
		That's completely irrelevant in the context of GitHub Actions: a CI runner is fetching the tag each time, and CI runners are usually completely fresh. The point is if someone compromises a widely used action, they can force push all tags to point to a malicious commit and compromise everyone using the action. This is even in GitHub's docs: https://docs.github.com/en/actions/reference/security/secure... > Pinning an action to a full-length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload.
	▲	growse an hour ago \| parent \| prev [-]
		If you're in (for example) a CI context and do a git checkout @tag, there's no guarantee that you'll get the same content as the last time you fetched that tag. Tags are not immutable.

▲

LtWorf an hour ago | parent | prev [-]

They love to be essential and central even if it costs them. Same reason why they won't ratelimit 10000000000000x consecutive requests from the same source on the same resource on npm.

	▲	kibwen an hour ago \| parent [-]
		No, services that lean too heavily on Github routinely receive messages from the admins asking them to do what they can to dial back usage of server resources. It happened to Homebrew, it happened to Rust, and it happened to various other projects who thought they were being good citizens by recommending shallow clones (turns out, shallow clones are somehow harder on the server than full clones).

▲

delusional 3 hours ago | parent | prev [-]

> 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 2 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 an hour 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?
	▲	LtWorf an hour ago \| parent \| prev [-]
		> implement everything in terms of commit hashes And remember, git uses a vulnerable algorithm :)

▲

direwolf20 2 hours ago | parent | prev [-]

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