Re:Vulnerability Management for Go
by goalieca on Tuesday September 06, 2022 @12:06PM
(#32739072)
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?
[ Parent
| 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.
Re:Vulnerability Management for Go
by preseinger on Tuesday September 06, 2022 @07:41PM
(#32744592)
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.