As hair splitting, that's actually not true: Go's package manager is just version control of which GitHub is currently the most popular hosting. And it also allows redirecting to your own version control via `go mod edit -replace` which leaves the sourcecode reference to GitHub intact, but will install it from wherever you like

How does that relate to the bigger conversation here? Are you suggesting people stop pulling Go packages from GitHub and only use local dependencies?

I wasn't trying to relate anything to the bigger conversation, I just meant to draw attention to the fact that GitHub is not golang's package manager

That said, I would guess the 'bigger conversation' is that it is much harder to tpyo <<import "github.com/DataaDog/datadog-api-client-go/v2/api/datadogV2">> than $(npm i dataadog) or similar in a "flat" package namespace (same for its $(uv pip install dataadog) friend)

None of those cited ones fix the dependency lineage issue, proving that release 1.1 was authored by the same chain of custody as release 1.0 of any given package. One can opt in to gpg verified dependencies in Maven, but it is opt-in. The .jar artifacts can also be cryptographically signed, but the risk that's trying to drive down is tamperproofing and not lineage, AFAIK

Golang at least gives you the option to easily vendor-ize packages to your local repository. Given what has happened here, maybe we should start doing this more!

This doesn't really help you. I assume Go records the sha1 hash of the commit it grabs, so it doesn't really matter if you vendor it, or download it every time.

The problem comes when you want to upgrade your dependencies. How do you know that they are trustworthy on first use?

Go uses the hash of the source code, not the commit ID. So there's no difference between vendoring and using the central repo.

npm has always downloaded to the current directory.

That isn't the same as vendor-izing unless you are committing node_modules to your VCS, which would be insane.