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 2 hours 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.

(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.)

	▲	johnmaguire 27 minutes ago \| parent [-]
		> aside from throwing a bit of shade at them using mutable git tags for Actions instead of actually building a package manager I mean, you can use SHA instead.

▲

Thaxll an hour ago | parent | prev | next [-]

Go does not use Github as a package manager.

▲

bspammer 3 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 3 hours 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 3 hours ago | parent [-]

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

Tags are not immutable.

▲

embedding-shape 3 hours 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 2 hours ago \| parent \| next [-]
		That's irrelevant in the context of GitHub Actions: CI runners clone the repo fresh every run. If someone gets write access to a widely used action, they can force push all tags to point to a malicious commit. 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 2 hours 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 3 hours 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 3 hours 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).