[wereHamster]

A lock file, in my world, contains a cryptographic hash of dependencies. go.mod does not, it only lists tags, which are (in git) movable references.

If go.sum has "no observable effect on builds", you don't know what you're building and go can download and run unverified code.

I'm not a go developer and must be misunderstanding something...

[PunchyHamster]

> I'm not a go developer and must be misunderstanding something...

I think it's coz not EVERY language's lockfile comes with checksum

So, Go's go.mod is functionally equivalent Ruby Gem lockfile (that doesn't have checksum) but need to get go.sum to be equivalent to npm's (that does come with checksum)

Author just compared it to languages where lockfile means just version lock

[wereHamster]

Now I understand :) thanks for clarifying

[JetSetIlly]

By default, all go mod downloads go through the golang proxy (https://proxy.golang.org/). That is part of the verification process.

[wereHamster]

Let's assume I publish a github repo with some go code, and tag a particular commit with tag v1.0.0. People start using it and put v1.0.0 into their go.mod file. They use the golang proxy to fetch the code (and that proxy does the "verification", according to your comment). Now I delete the v1.0.0 tag and re-create the tag to point to different (malicious) commit. Will the golang proxy notice? How does it verify that the people that expect the former commit under the v1.0.0 tag will actually get that and not the other (malicious) commit?

[zelphirkalt]

Does this mean, that when you change the proxy, you lose all guarantees?

[inglor]

You are not misunderstanding anything, I use Go and Rust/TypeScript in my daily work and you are correct - it is the OP that does not understand why people use lockfiles in CI (to prevent minor updates and changes in upstream through verifying a hash signature).

[alias_neo]

I would hazard a guess that the (former) head of the Go security team at Google (OP) _does_ in fact understand.