Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go.sum is not a lockfile

words.filippo.io

Post reply on HN
Print view View original

21–30 of 81 posts

Re: Go.sum is not a lockfile

#21

Post by inglor »

wereHamster wrote: post #18

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

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

Re: Go.sum is not a lockfile

#22

Post by alias_neo »

inglor wrote: post #21
wereHamster wrote: post #18

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

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

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

Re: Go.sum is not a lockfile

#23

Post by JetSetIlly »

wereHamster wrote: post #18

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

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

Re: Go.sum is not a lockfile

#24

Post by zelphirkalt »

JetSetIlly wrote: post #23
wereHamster wrote: post #18

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

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

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

Re: Go.sum is not a lockfile

#25

Post by supriyo-biswas »

nasretdinov wrote: post #17
Groxx wrote: post #4

> If the main module imports example.com/mod1/pkg1 and a separate example.com/mod1/pkg2 imports example.com/mod2, there is no way for example.com/mod2 to affect the build or run code on the developer’s machine, so you don’t need to consider it a dependency. iirc (I do not have a test setup at the moment to verify) it does affect your dependency resolution, and therefore your build, though its code does not exist in y…

These libraries are honestly so bad that whenever I have to interact with them I just split those dependencies into a separate binary :)

I just write my own, small, focused client for these AWS services since the SDKs are generally just so unergonomic. With vibe coding becoming a thing it's become even easier to do that.

Re: Go.sum is not a lockfile

#26

Post by jchw »

djha-skin wrote: post #6

> Instead, just look at go.mod. It lists the precise version at which all dependencies are built. No, it does not. Minimum version selection means that the libraries will at least be that version, but it could be substituted for a later version if a transient dependency asks for such. That I'm reading this blog post at all suggests there is a "market" for a single checksum/version manifest, which data is currently ho…

The MVS choices will be encoded into the go.mod; you may have been correct in the past, but as the post mentions transitive dependencies have been incorporated since Go 1.17. So yes, really: the only point of go.sum is to enable checking the integrity of dependencies, as a nice double-check against the sumdb itself.

Re: Go.sum is not a lockfile

#27

Post by arccy »

zelphirkalt wrote: post #24
JetSetIlly wrote: post #23

Earlier quoted context omitted.

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

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

Only if you change checksum servers https://sum.golang.org/ Note that the default one uses data from https://proxy.golang.org/

Re: Go.sum is not a lockfile

#28

Post by arccy »

djha-skin wrote: post #6

> Instead, just look at go.mod. It lists the precise version at which all dependencies are built. No, it does not. Minimum version selection means that the libraries will at least be that version, but it could be substituted for a later version if a transient dependency asks for such. That I'm reading this blog post at all suggests there is a "market" for a single checksum/version manifest, which data is currently ho…

This comment suggests that there is a "market" for confidently incorrect, contrarian HN comments. This is sad, but, Hyrum's Law and all that.

Re: Go.sum is not a lockfile

#29

Post by arccy »

kadoban wrote: post #15
uasi wrote: post #14

Earlier quoted context omitted.

I'm not deeply familiar with this, but from reading the `go mod tidy` manual[1], it seems that running `go mod tidy` loads all packages imported from the main module (including transitive dependencies) and records them with their precise versions back to `go.mod`, which should prevent them from being substituted with later versions. Am I understanding this correctly? [1]: https://go.dev/ref/mod#go-mod-tidy

go.mod will always match whatever versions are being used directly, as far as I know. But it's not possible to lock them using go.mod. Like if you wanted to bump one version only in go.mod, you're then stumped for actually doing that. Because _probably_ the only reasonable way to get that to build is to do `go mod tidy` after doing that, which will modify go.mod itself. And you can't _really_ go back in and undo it u…

go always requires a dependency graph that is consistent with all the declared requirements.

Which means if you wanted to update one version, it might bump up the requirements on its dependencies, and that's all the changes you see from running go mod tidy afterwards.

Manually constructing an inconsistent dependency graph will not work.

Re: Go.sum is not a lockfile

#30

Post by FiloSottile »

djha-skin wrote: post #6

> Instead, just look at go.mod. It lists the precise version at which all dependencies are built. No, it does not. Minimum version selection means that the libraries will at least be that version, but it could be substituted for a later version if a transient dependency asks for such. That I'm reading this blog post at all suggests there is a "market" for a single checksum/version manifest, which data is currently ho…

No.

As explained in the post, if a transitive dependency asks for a later version than you have in go.mod, that’s an error if -mod is readonly (the default for non-get non-tidy commands).

I encourage you to experiment with it!

This is exactly how the “stricter” commands of other package managers work with lockfiles.

Post reply on HN