fix(vulnerable-code): Fix search for Go package vulnerabilities

[wkl3nk]

For Go packages, both the namespace and name may contain path segments separated by a "/" character. The purl specification requires these "/" characters to be percent-encoded in the namespace and name components of a purl.
The VulnerableCode bulk-search API is unable to handle these percent-encoded "/" characters, resulting in no vulnerability records being returned.
This bugfix decodes any percent-encoded "/" characters just before making the VulnerableCode query to ensure proper functionality.

Fixes #9298

[sschuberth]

Fixes #9298

Nit: Missing period at the end of the sentence.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 67.49%. Comparing base (ed4bccf) to head (6f5a942).
Report is 66 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #9299      +/-   ##
============================================
+ Coverage     66.29%   67.49%   +1.19%     
+ Complexity     1201     1200       -1     
============================================
  Files           239      241       +2     
  Lines          8446     8493      +47     
  Branches        905      899       -6     
============================================
+ Hits           5599     5732     +133     
+ Misses         2478     2399      -79     
+ Partials        369      362       -7     

Flag	Coverage Δ
funTest-docker	60.54% <ø> (+0.47%)	⬆️
funTest-non-docker	33.63% <ø> (-1.08%)	⬇️
test	37.47% <ø> (+0.11%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[sschuberth]

@wkl3nk could you try if #9304 instead would also fix your issue?

[wkl3nk]

Could you try if #9304 instead would also fix your issue?

This is about namespace segments?
It probably would, but from what I have seen in ort-result.zip

id: "Go::github.com/quic-go/quic-go:0.40.0"
purl: "pkg:golang/github.com%2Fquic-go%[email protected]"

I ask myself if there is not a general problem in detecting namespace and name for Go libraries.
Would not the following be more correct:

id: "Go:github.com/quic-go:quic-go:0.40.0"
purl: "pkg:golang/github.com/quic-go/[email protected]"

Because the github.com home of quic-go is https://github.com/quic-go and quic-go is just one of the subprojects there.

[sschuberth]

Yes, that's exactly what my PR is about. But could be that there's still something wrong in my implementation.

[wkl3nk]

Possibly I did not know enough when I wroted the posting on Friday. Because I am not a Go programmer, I don't even know if there exists a concept of namespaces. Nevertheless I proposed to use the namespace, based on some directory structure on a github.com account. I don't know if this is valid, or if it is better to say something like "There are no namespaces in Go". Don't know.

[sschuberth]

I don't know if this is valid, or if it is better to say something like "There are no namespaces in Go".

You may want to refer to this comment.

[sschuberth]

I still believe we should solve this differently, in a more generic way. While Go apparently does not have namespaces, the purl standard treats them as if Go had namespaces. I'm currently preparing a fix for that.

[fviernau]

I'm currently preparing a fix for that.

Related OSV code locations:

• ort/plugins/advisors/osv/src/main/kotlin/Osv.kt

  Lines 143 to 147 in e612c50

  	val name = when {
  	pkg.id.namespace.isEmpty() -> pkg.id.name
  	pkg.id.type == "Composer" -> "${pkg.id.namespace}/${pkg.id.name}"
  	else -> "${pkg.id.namespace}:${pkg.id.name}"
  	}

• ort/plugins/advisors/osv/src/funTest/kotlin/OsvFunTest.kt

  Lines 46 to 47 in e612c50

  	"Go::github.com/nats-io/nats-server/v2:2.1.0",
  	"Hackage::xml-conduit:0.5.0",

[sschuberth]

In any case, @wkl3nk as mentioned here please add a test for this (in a new commit that could easily be cherry-picked) so we can verify the fix also for alternative solutions.

[wkl3nk]

@sschuberth I added a test cases, hoping that this is what you had in mind. It will start to fail once the slashes in the purl name section are no longer percent-encoded. Once this test fails, this commit can be cherry-picked and removed.

[sschuberth]

I added a test cases, hoping that this is what you had in mind.

Hmm, not really. I was hoping for a funTest that queries VC for a Go package which is known to have vulnerabilities. When run against main, the test would currently fail as the expected vulnerability is not found. But once there is a fix in place to produce the correct purl, the test would succeed.

[sschuberth]

I added a test cases, hoping that this is what you had in mind.

Hmm, not really. I was hoping for a funTest that queries VC for a Go package which is known to have vulnerabilities.

Nevermind @wkl3nk, I'll now add such a test myself as I'm close to proposing a more generic fix.

[sschuberth]

Closing in favor of the more generic solution in #9330.