Incomplete percent encoding and decoding of package name

[matt-phylum]

package-url/purl-spec#254 proposes a new package type which sometimes uses PURLs like pkg:brew/openssl%401.1@1.1.1w. This implementation parses that PURL as having a name openssl%401.1 instead of openssl@1.1. Serializing that PURL from its expected parts results in the invalid PURL pkg:brew/openssl@1.1@1.1.1w.

[maennchen]

@matt-phylum Good catch. Would you be able to provide a PR?

[matt-phylum]

Is the name just not decoded at all? https://github.com/maennchen/purl/blob/main/lib/purl/parser.ex#L96-L100

[maennchen]

@matt-phylum I assumed it should be done by URI.new/1 here:
https://github.com/maennchen/purl/blob/e080be5cafd0084ca9c9a20667816173b56a45c2/lib/purl/parser.ex#L9C10-L9C17

But I haven't verified if that is actually the case.

[maennchen]

Currently none of the package types that are part of the docs seem to allow this. This library is able to run the complete & up-to-date test suite from the specification.

I propose to wait until the format is decided and the test cases added. This way we're sure that everything is implemented correctly.

[maennchen]

I just saw package-url/purl-spec#273, waiting for that also works :)

[matt-phylum]

I don't think this is blocked by spec ambiguity. The character encoding section says "the '@' version separator must be encoded as %40 elsewhere," making pkg:brew/openssl@1.1@1.1.1w invalid, even if it parses correctly when using the algorithm defined in the spec. The "How to build purl string from its components" and "How to parse a purl string in its components" sections unambiguously state that the name and version are to be percent encoded. The test suite just doesn't include tests covering this part of the spec.

The examples for pkg:swid are wrong because they encode spaces as '+' in the namespace and name (package-url/purl-spec#261), but this implementation doesn't encode spaces in names at all, so if asked to produce a pkg:swid for software that contains a space in the name, it will produce a PURL with a space in it, which is often a problem when PURLs are written into text documents. I don't know if any of the other officially supported types also allow characters that must be encoded in the name.