go binary cataloger use richer commit version
What would you like to be added:
we could toy with changing the version to be in the format of v0.0.0-
Why is this needed: Main module could offer better version info in a similar go.mod version format.
Additional context: Idea came up while adding support to go1.18 debug BuildInfo
I think we might not need to pursue our own solution to creating a version for the main module. This Go proposal was just accepted, so hopefully we can find the version value we need directly in Go binaries in the future.
Hi there! Paketo buildpacks maintainer, here. We're seeing our end-users have issues with the current empty-string format for the main module version because it breaks their SBOM-merging. Would love to see a fix that places some reasonable default in that empty field.
Related: https://github.com/anchore/syft/issues/959
As pointed out by the author of https://github.com/paketo-buildpacks/go-build/issues/302 this issue affects binaries compiled by a go compiler version < 1.18.
I agree that a reasonable default should exist for compatibility with older binaries, but there are open questions:
- What would be a useful version for the main package of an old go binary (old here is a binary compiled with go < 1.18)?
- As hinted by https://github.com/anchore/syft/issues/959 is an arbitrary constant enough?
- Since no vsc hash is available (for go binaries < 1.18), would a checksum of the main package be useful? The usefulness of a vsc-hash/version is the matching of it against vulnerability databases, can that matching happen via artifact checksums?
Hi @fg-j and @ryanmoran — thanks for the feedback! To consolidate communication, we'll track the "missing version field" problem in #959. Thanks for raising this! 🙏