go binary cataloger use richer commit version

[jonasagx]

What would you like to be added: we could toy with changing the version to be in the format of v0.0.0-- if we could derive the date correctly from the build info (which I'm not certain is possible). This would make it consistent to go module version formatting.

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

[luhring]

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.

[fg-j]

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.

[ryanmoran]

Related: https://github.com/anchore/syft/issues/959

[jonasagx]

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?

[luhring]

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! 🙏