-
Notifications
You must be signed in to change notification settings - Fork 190
Description
Describe the bug
SPDX documents that contain a relative file path in the fileName property throws an error. For example, this SPDX has a relative file path of ./include-path:
{
"SPDXID": "SPDXRef-DOCUMENT",
"spdxVersion": "SPDX-2.2",
"name": "testsbom",
"creationInfo": {
"created": "2022-09-24T17:27:55.556104Z"
},
"files": [
{
"fileName": "./include-file",
"SPDXID": "SPDXRef-aef1c9f4f2277e36",
"fileTypes": [
"TEXT"
],
"checksums": [
{
"algorithm": "SHA1",
"checksumValue": "ba1c68d88439599dcca7594d610030a19eda4f63"
}
],
"licenseConcluded": "NOASSERTION",
"copyrightText": ""
}
]
}This fails to parse with the following error:
unable to parse purl pkg:guac/files/sha1:ba1c68d88439599dcca7594d610030a19eda4f63#./include-file: invalid Package URL subpath: "./include-file"
This bug was introduced in 00d978b. It appears to be related to bumping github.com/package-url/packageurl-go from v0.1.1 to v0.1.2
To Reproduce
Steps to reproduce the behavior:
- PR to repro: Use filename as qualifier for SBOM file references #1546
- Run unit tests to see failure
- Check out last good commit of 0689514
- Run unit tests to see success
Expected behavior
Relative file paths in SPDX files section shouldn't throw error
Screenshots
If applicable, add screenshots to help explain your problem.
GUAC version
Latest from main
Additional context
Ran into this issue on internal SBOMs generated using sbom-tool which consistently uses relative file paths.
The SPDX 2.3 spec states:
In general, every filename is preceded with a
./
which would indicate that this should not be throwing an error