Hacker News Reader

Comment by salmo | Hacker News Reader

Oh my goodness I hate that so much. Every time I have to explain that go.sum lists every compatible version, not the version baked in.

But this is even an improvement over any other language I've seen. All just flag CVEs in dependent libraries when 99% of the time it's like "to be vulnerable you have to do [really stupid thing]".

Let's hope that vulnerability scanning vendors adopt using this. For my own stuff or minor work things, it's great. When I fall under the specter of officialness, I'll still get popped by the Enterprise Security Scanning Standard Tool.

View on HN

Why would some people even care or look at go.sum where go.mod is clean and self explanatory?

Prior to 1.17, go.mod was not a complete representation of the dep graph. More broadly, the problem is that programmers expect dependency management tooling to have a lock file, see go.sum, and assume it's a lock file. This isn't a problem with those programmers, it's a problem with Go modules.

> This isn't a problem with those programmers, it's a problem with Go modules.

That seems like a bit of a jump! Maybe there's a better way of building dependency management tooling that doesn't use lock files, it seems strange to tie yourself to this approach just because it's how other tools work.

go.mod is the lock file.

It isn't in the traditional sense. There isn't anything in its specification that guarantees the things that most people expect lock files to guarantee.

Well, I do understand that the actual version used there is ambiguous.

Probably the best would be to take the newest from go.sum. That’s what some scanners are doing now.

Filed bugs with 2 vendors over this though.

The newest from go.sum isn't reliably the version used in the dep graph. The only way to get that information reliably is via go list. Unfortunately.

Oh, you are totally right. I read that in the GitLab issue tracking their version of the problem and totally forgot that’s where they landed.

Also don't forget that more than one version of a dependency might be compiled into your application!

Only one major version. And go considers different major versions to be different dependencies.

not true for go

For the curious it's:

    go list -m all

Reply on news.ycombinator.com