Do pkg and vers URIs need a third scheme? The case for "lib" URIs

[sjn]

Hei!

Do we need third URI schema?

First some context.

As of today, we have two URI schemas: pkg and vers. The first is used to refer to distributed artifacts (e.g. zip archives or similar), and the second is used to specify version constraints to be used to specify dependency requirements.

This works less than ideal in quite a few situations. In the case of CPAN, the category mismatch becomes apparent when looking using package urls to both refer to package artifacts, and to library dependencies (and their associated version constraints).

I'll operate with the following definitions:

• Requirement: A capability (e.g. in the form of a library or module) with associated version constraints, that is needed by some other software. These capabilities are usually provided for the software through several steps: resolution, — the downloading of a package —, unpacking, building, testing, installation and more. — A requirement needs a capability to be provided
• Dependency: The results of resolving a requirement for some capability necessary to execute some other software. Dependencies come usually in the form of a package, that is downloaded, built and installed. The package provides a capability that is stated in some other software's requirements. — A dependency provides a capability.

	Requirement	Dependency
pURLs	pkg + vers	pkg
Reality	lib + vers	pkg

On CPAN we do not specify requirements for packages. Instead we specify requirements for something that provides a capability that happens to be distributed within a package.

When using pURLs to specify a Requirement that needs to be resolved and installed; or to report the resolution and subsequently what package ended up being installed, Package URLs are conflating two distinct concepts: the capability (e.g. library) and the distribution artifact (e.g. package).

Since we're forced to have pURL do double-duty, we're end up with situations like we have with the CPAN package URLs:

• pkg:cpan/Module::Name – for stating which capabilities are Required, and together with vers URIs, their version constraints
• pkg:cpan/AUTHOR/Module-Name@1.0 – for reporting what Dependency was used to Provide above capability.

The first may or may not have an associated vers URI. The second must not have and associated vers URI, as this does not make sense – a package already has a specific version associated with it.

If we have a lib schema to go along with the vers, we remove a source of confusion, and make it abundantly clear that pkg URIs are for packages only, and lib are used only for the situations where one needs to refer to a capability that a pkg provides (and not is).

(And yes, for those interested in Philosophy – the pURL spec may very well have an is–ought problem. Hooray for Hume! 🤣)

[pombredanne]

Thanks for the detailed report!

[sjn]

One point of interest (possibly related to #124)

Apparently neither pkg, vers nor lib have been registered as URI schemes at IANA at the moment.

[jkowalleck]

One point of interest (possibly related to #124)

Apparently neither pkg, vers nor lib have been registered as URI schemes at IANA at the moment.

see PURL spec IANA registration

[jkowalleck]

@pombredanne sketched out the following: let's add a new well-known qualifier vers and its value MUST be a validvers.
applied as pkg:cpan/AUTHOR/Module-Name?vers=vers:cpan/>=2.2.0|!= 2.2.1|<2.3.0

• see PURL add well-known qualifier vers #433

[sjn]

@pombredanne sketched out the following: let's add a new well-known qualifier vers and its value MUST be a validvers. applied as pkg:cpan/AUTHOR/Module-Name?vers=vers:cpan/>=2.2.0|!= 2.2.1|<2.3.0

* see [PURL add well-known qualifier `vers` #433](https://github.com/package-url/purl-spec/pull/433)

Not sure if that PR actually solves the use case I'm laying out in this ticket.

I guess it does solve some important issues – e.g. how to specify that a vulnerability is contained in certain versions of a package – but for the CPAN case, #433 doesn't seem to aim for the correct solution.

On CPAN, it's the modules that may contain vulnerabilities. The presence of a module in a given package is not guaranteed, since the package namespace (e.g SJN/Module-Example-1.0.tar.gz) is independent of the module namespace (e.g. Module::Example => '1.0';).

A module may very well be moved to a new package entirely. E.g. Module::Example may be "moved" from SJN/Module-Example-1.0.tgz to either JKOWALLECK/Module-Example-1.01.tar.gz or even SJN/Module-Example-Common-0.01.tgz . If the vulnerability exist during a transition like this, then we'll need several PackageURLs + version ranges....

Unless we have a way to specify URLs for Modules (or more generally, capabilities or even features) like I proposed in this ticket: lib:cpan/Module::Example?vers=vers:cpan/>=0.8|<1.02