4 ms·

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 a

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?

ainar-g 4y ago
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.
- jrockway 4y ago
  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.
  - svnpenn 4y ago
    great point. I am glad they took this into consideration.
shp0ngle 4y ago
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.
- preseinger 4y ago
  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.
- indil 4y ago
  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.

4 ms·

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 a

by goalieca 4y ago

ainar-g 4y ago
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.
- jrockway 4y ago
  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.
  - svnpenn 4y ago
    great point. I am glad they took this into consideration.
shp0ngle 4y ago
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.
- preseinger 4y ago
  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.
- indil 4y ago
  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.