[bug] ./ and ../ are not valid subpath prefix

[ridhoq]

A bug was discovered after upgrading to v0.1.2 where ./ and ../ are not valid prefixes as seen here: guacsec/guac#1545. It appears to be due to this logic:

if s == "." || s == ".." {
	return fmt.Errorf("invalid Package URL subpath: %q", p.Subpath)
}

As per the SPDX spec, file paths are generally prefixed with ./. If a purl was to be constructed using the files read in from an SPDX SBOM, it would throw an error.

[lumjjb]

Hmm seems like the current specification doesn't allow allow some of these subpaths, so I think it would also be a question whether it makes sense to have the first index be an exception due to convention or do a implicit translation of removing the ./ prefix.

I think the ./ case is a little easier to reason about, but the ../ one is a bit tricky (although i've seen some of this, e.g. dynamic references)

@pombredanne do you have any thoughts on this? We are seeing quite a bit of ./ and ../ prefix, and would be good to be able to handle them.

[lumjjb]

we are still running into some of these issues where ./ and ../ carry some meaning with the PURLs that are generated that include them... I do realize this is a bit more of an involved discussion, and wondering if @pombredanne and other PURL maintainers would be amicable to relax this requirement in the code only for now?

[pombredanne]

Why not stripping a leading ./ on input? The fact that this is supported by SPDX does not mean this is requirement for SPDX nor here.

And reporting an error for ../ which as a relative path which may be eventually impossible to make sense of as this would be outside of a package file tree?

Where did these PURLs come from BTW? If this is from https://github.com/microsoft/sbom-tool from reading through this and related issue then you may want to report a bug there to get the fix upstream? Can you provide some exmaple?

Note that in general, I am not too keen on changing the spec based on the output of one tool in another spec.

[lumjjb]

Yea agreed about the "../" values not making semantic sense for now.. i'm wondering if we can provide a build flag or alternate function that will parse legacy documents while things get eventually fixed? It is likely we'll still see a lot of these "bad PURLs" around for the near future?

[pombredanne]

@lumjjb it could make sense to publish a simple doc with fixes to apply to well known problematic inputs.