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.
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.
(Also, Go doesn't use GitHub as a package manager. It's just one of the many supported code hosts. In fact, anything that can serve a VCS repo or a zip file is supported.)
I mean, you can use SHA instead.
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.
Tags are not immutable.
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.
Tags are not immutable.
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.