Go Parser missing Package Version for go.mod files

[mjherzog]

Description

The Go parser for dependency files does not include package_version in the purl; version is included in the purl for go.sum files.

System configuration

This is an issue for SCTK v21.2.9.

[rpotter12]

Hi @mjherzog, can you please give me an example here that what should be shown in purl?

[JonoYang]

@rpotter12

For the detected dependencies from a go.mod/go.sum file, we want the version numbers added to the dependent package purls.

For example, when I scan this go.mod file using scancode (https://raw.githubusercontent.com/golang/protobuf/v1.4.3/go.mod), the detected dependencies from the go.mod file looks like this:

          "dependencies": [
            {
              "purl": "pkg:golang/github.com/google/go-cmp",
              "requirement": "v0.4.0",
              "scope": "require",
              "is_runtime": true,
              "is_optional": false,
              "is_resolved": false
            },
            {
              "purl": "pkg:golang/google.golang.org/protobuf",
              "requirement": "v1.23.0",
              "scope": "require",
              "is_runtime": true,
              "is_optional": false,
              "is_resolved": false
            }
          ],

We want the purls to look like this, with the version number included:

          "dependencies": [
            {
              "purl": "pkg:golang/github.com/google/go-cmp@v0.4.0",
              "requirement": "v0.4.0",
              "scope": "require",
              "is_runtime": true,
              "is_optional": false,
              "is_resolved": false
            },
            {
              "purl": "pkg:golang/google.golang.org/protobuf@v1.23.0",
              "requirement": "v1.23.0",
              "scope": "require",
              "is_runtime": true,
              "is_optional": false,
              "is_resolved": false
            }
          ],

[pombredanne]

@JonoYang I would likely strip the leading v

[JonoYang]

@pombredanne I don't agree. I don't think we should modify how the package maintainers set the version. If the version number already has a leading v in it, then we shouldn't change it. We should report it as is. It would also make things easier when we want to look up a package on a repo, where we do not have to add back a leading v when we want find an exact match for a particular package-version.

[mjherzog]

I agree that we should keep whatever the package authors provide, but otherwise I would prefer to deprecate leading "v" when not used by the package author.

[rpotter12]

@pombredanne, I agree with @JonoYang that we should not modify because that is the version number set by maintainers only.

However, we need to check past PR and attached issue in the PR to get to know why I haven't added that. There might a reason for not adding this. I don't remember it yet.

@JonoYang @pombredanne @mjherzog Please share this issue in the gitter channel so GSOC aspirants who are not able to conbribute yet can have a start on this project.