Hacker News Reader

Comment by goalieca | Hacker News Reader

So shall we have a chat about go.sum files yet? Several scanners seem to choke on the fact that go.sum includes several versions of each module, some of which are vulnerable, but basically never actually packaged. Am i missing a reason why go did not go with a lockfile as nearly every other modern language?

View on HN

It's not a lockfile. It contains hashes of packages so that you could fetch them from any proxy and not worry about proxies doing funny business.

Even ignoring proxies, it ensures that you have the same code that you started developing with. If you're depending on a tagged Git repository, for example, someone can just force push the tags and change what commit go.mod is actually pointing at. With go.sum, you're guaranteed to be notified that that happened.

great point. I am glad they took this into consideration.

go.mod IS a lockfile.

go.mod will exactly tell you what version you have, always. *

* that does not apply if your code is a library; then, other dependency of the "main" app can "update" your dependency. Which sometimes does break things.

However, the go.mod of the main app will deterministically tell what version is used, always.

I never did understand what packages go to go.sum though and what is the logic there. But it is not that important.

This is only true for go 1.17 and above. Prior to that, go.mod wouldn't necessarily list all transitive dependencies. And I don't think this property is actually guaranteed by the relevant specification. The only reliable way to get a "lock file" is to run go list. Unfortunately.

go.mod lists minimum versions. Minimum Version Selection may increase the versions used as required by other packages in the build. go.mod isn't a lock file.

Reply on news.ycombinator.com