Add support for PURL (Package URL)

[valentijnscholten]

More and more tools use PURL to identify packages in a standardized way.

A purl or package URL is an attempt to standardize existing approaches to reliably identify and locate software packages.

A purl is a URL string used to identify and locate a software package in a mostly universal and uniform way across programming languages, package managers, packaging conventions, tools, APIs and databases.

Such a package URL is useful to reliably reference the same software package using a simple and expressive syntax and conventions based on familiar URLs.

Check also this short purl presentation (with video) at FOSDEM 2018 https://fosdem.org/2018/schedule/event/purl/ for an overview.

It's heavily used in SBOMs and SCA tooling. An example tool is Dependency Track. Currently it's based around official standards, and only supports PURL (or CPE) to idenfity packages. So currently it doesn't index vulnerabilities from packagist (or specific repository instances such as https://packages.drupal.org/files/packages/8.

The request here is to support PURLs in packagist composer respositores. Use cases / features affected by this based on my limited knowledge of the ecosystem (not exhaustive):

• Allow metadata retrieval by PURL, i.e. GET https://repo.packagist.org/p2/
• Return PURL in metadata responses
• List vulnerabilities by PURL, i.e. GET https://packagist.org/api/security-advisories/?&packages[]=[]

Is this something that could be considered?

[stof]

Adding support for PURL on packagist.org alone seems doable. However, I'm wondering what how this should look like when consider the whole composer ecosystem.
A package name and its version is not sufficient to uniquely identify a package, when considering custom repositories. Nothing forbids repositories to reuse the same package name or version for different packages, as long as they are not registered at the same time in a project (if you register both packages and the first one is not registered as canonical, weird things will happen due to the "conflicting" definitions). And this case is not theoretical. Drupal relied on that to provide separate repositories for Drupal 7 and for Drupal 8+, because in the past, packages were dual-versioned based on the supported Drupal major version and their own semver version.
But on the other hand, some repositories are mirroring packages from packagist.org, and this should probably not change their PURL to properly keep it associated to security advisories.

[glaubinix]

@stof the first part is covered by the repository_url query param e.g.

pkg:docker/customer/dockerimage@sha256:244fd47e07d1004f0aed9c?repository_url=gcr.io

Though can't find any info though about how package mirroring would be displayed.