-
Notifications
You must be signed in to change notification settings - Fork 309
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VulnerableCode returns no findings for Go packages #9298
Comments
Agreed, also regarding the topic that if VulnerableCode would be using a wrong encoding, we'd need to use a wrong encoding as well to make the lookup work.
Great! Please also add a test for this, so we'd risk swallowing vulnerabilities in case we do some PURL refactoring again. |
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 oss-review-toolkit#9298 Signed-off-by: Wolfgang Klenk <[email protected]>
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 oss-review-toolkit#9298 Signed-off-by: Wolfgang Klenk <[email protected]>
Cross-linking the issue ticket in VulnerableCode: aboutcode-org/vulnerablecode#1620 |
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 oss-review-toolkit#9298 Signed-off-by: Wolfgang Klenk <[email protected]>
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 oss-review-toolkit#9298. Signed-off-by: Wolfgang Klenk <[email protected]>
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 oss-review-toolkit#9298. Signed-off-by: Wolfgang Klenk <[email protected]>
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 oss-review-toolkit#9298. Signed-off-by: Wolfgang Klenk <[email protected]>
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 oss-review-toolkit#9298. Signed-off-by: Wolfgang Klenk <[email protected]>
Describe the bug
I am scanning a project with
ModGo
ORT package manager.One dependency is quic-go, release 0.40.0 , which definitely has vulnerability findings in the VulnerableCode database.
Unfortunately, no security vulnerabilites are found in the Advisor phase, using VulnerableCode.
Detailed analysis
ORT uses a "bulk search", sending a POST request to the VulnerableCode API. This request has a list of Package URLs (purls) of the dependencies like quick-go.
The purl for quick-go looks as follows:
pkg:golang/github.com%2Fquic-go%[email protected]
So, at some places we see the "/", in other places it is percent-encoded to "%2F".
I don't want to open discussions if this is valid or not, but there is a point in saying "the / character is used to separate the parts that build up a purl, and for this reason, if a namespace or name of a dependency contain /, then they need to be percent-encoded".
When I (in code) add an additional step that replaces all occcurrences of "%2F" with "/" before I feed it into VulnerableCode, then the VulnerableCode API is happy and returns the expected vulnerability records.
Environment
ORT 34.0.0
Additional context
I will prepare a PR to deal with the issue in a pragmatic way. Stay tuned.
The text was updated successfully, but these errors were encountered: