Package Metadata DB (External License DB) exports Golang package versions without `v` prefix

Summary

When investigating a customer support request (internal) it has been discovered that we have a normalization issue for Golang package versions in the license-exporter project of our Package Metadata DB (External License DB).

This normalization was not intended but the by product of using the github.com/hashicorp/go-version library to manipulate versions for golang packages during the export. The consequence is that during the JSON marshal process, the version string is outputted witout the leading v character as explained in the documentation:

This value is rebuilt according to the parsed segments and other information. Therefore, ambiguities in the version string such as prefixed zeroes (1.04.0 => 1.4.0), v prefix (v1.0.0 => 1.0.0), and missing parts (1.0 => 1.0.0) will be made into a canonicalized form as shown in the parenthesized examples.

Note that this only affect the lowest_version and highest_version of the default_licenses property. The other_licenses property is using raw versions string and thus do not have this leading v removed.

As the CylconeDX SBOM documents report golang versions with the v prefix, the License Scanning logic fails to match.

User Impact

This means that License Scanning feature for golang projects is likely to be failing and returning unknown license in the nominal case that is for versions that uses the default_licenses set which is also usually the largest set of versions for a golang package (simplified explanation).

Steps to reproduce

Example Project

https://gitlab.com/gitlab-org/secure/tests/go-versions-license-matching/-/dependencies

What is the current bug behavior?

License Scanning fails to report license for golang packages like github.com/twmb/murmur3

What is the expected correct behavior?

License Scanning succeed to report license for golang packages like github.com/twmb/murmur3

Relevant logs and/or screenshots

From a GDK instance with up to date Package Metadata, looking at the 'github.com/twmb/murmur3' golang package we can see it is available locally and with a default licenses set that covers versions between 0.0.0-20180318204424-7f484cea044b and 1.1.8:

> package=PackageMetadata::Package.where(purl_type: :golang, name: 'github.com/twmb/murmur3').first
=> #<PackageMetadata::Package:0x000000014d176580
 id: 1903501,
 purl_type: "golang",
 name: "github.com/twmb/murmur3",
 created_at: Tue, 05 Dec 2023 18:40:44.135238000 UTC +00:00,
 updated_at: Tue, 05 Dec 2023 19:06:14.651293000 UTC +00:00,
 licenses: [[4], "0.0.0-20180318204424-7f484cea044b", "1.1.8", []]>

When looking up license for a version with the v prefix there is no match:

> package.license_ids_for(version:'v1.1.5')
=> []

When looking up license for a version without the v prefix there is a match:

> package.license_ids_for(version:'1.1.5')
=> [4]

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check

(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)
(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)
(we will only investigate if the tests are passing)

Possible fixes

Two possible approaches to compare and refine:

1. Fix the license-exporter code to ensure we export golang package versions with the leading v and re-export all golang packages
   1. There is an Original() function we could use to prevent any normalization in the exported data
2. Adjust the matching logic to normalize version (remove leading v) when looking up in DB