[ingestion/data-quality issue] SPDX files with a relative path are failing

[ridhoq]

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:

1. PR to repro: Use filename as qualifier for SBOM file references #1546
2. Run unit tests to see failure
3. Check out last good commit of 0689514
4. 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

[lumjjb]

hmm im wondering whether we can just URL encode the subpath which i believe is what we do for the qualifiers and versions now

[pxp928]

so based on looking at packgeurl-go, the . is the real issue. It fails if it has that.

[lumjjb]

How about moving the filename into a qualifier instead, shouldn't be too much of an issue i think.

[pxp928]

How about moving the filename into a qualifier instead, shouldn't be too much of an issue i think.

Yeah based on looking at packageurl-go, moving it to qualifier should fix this error and not cause the same conflict as with subpath.

[pombredanne]

You can also fix the Go library with a PR FWIW, but please avoid changing the PURL spec ;)

[pxp928]

Thanks @pombredanne we have created a PR here: package-url/packageurl-go#68

[ridhoq]

Closed by #1546