4 ms·
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 imp
by salmo 4y ago
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.
- Thaxll 4y agoWhy would some people even care or look at go.sum where go.mod is clean and self explanatory?
- salmo 4y agoWell, 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.
- preseinger 4y agoThe 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.
- salmo 4y agoOh, 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.
- kubanczyk 4y agoFor the curious it's: go list -m all
- smoyer 4y agoAlso don't forget that more than one version of a dependency might be compiled into your application!
- arccy 4y agonot true for go
- preseinger 4y agoOnly one major version. And go considers different major versions to be different dependencies.
- preseinger 4y agoPrior 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.
- remus 4y ago> 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.
- Thaxll 4y agogo.mod is the lock file.
- preseinger 4y agoIt 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.