FAQ

• Can I use a subpath with multiple subpaths, globs or regexes in a purl?

  • No. Use multiple purl or other attributes outside of a purl.

• Why is the purl version optional?

  • This is to support the pointer to any version of a package or when you do not know the version (yet). This should not be abused but is useful and used in practice: for instance a package version may depend on another package with no version specified.

• Why not using the Authority of a URI/URI in a purl?

  • No. There are several reasons: The rules or parsing user/host/password and ports are complex and more so when you add IDAN, ppunycode and IPv4/v6. These would introduce subtle quirks if for instance the user/password was used as a purl version.

    Also while host may be important to locate a package it is not required to identify it: the exact same package may exist in multiple repositories, local, remote or private mirrors. This is still the same package.

    And the Autority comes before the Path in a URL: this would break the hierachical nature of the purl components and no longer make them nicely sortable as plain strings: this a good property when dealing with many purl in a database or even small lists in a UI.

• Why not using a CPE instead of a purl?

  • No. CPE https://en.wikipedia.org/wiki/Common_Platform_Enumeration are URIs and fairly close to purl but they are rather complex: cpe:2.3:a:artifex:ghostscript:8_64:*:*:*:*:*:*:*

    CPEs started from the world of proprietary software security and require a 'vendor' attribute before the 'name' attribute, somewhat similar to a purl namespace but not exactly. These names are assigned centrally and arbitrarily assigned by NIST and Mitre. For instance, the vendor for zlib is GNU: this does not make any sense.

    In contrast, purl names are not centrally or arbitrarily assigned or created: they are naturally and directly derived from whatever names a package author picked. Also CPEs specifies rather complex version semantics and can be hard to parse and build. Overall, they often mesh poorly with the world of software packages.

    Yet they are a great additional reference when they exist to relate a package to known NVD vulnerabilities. A valuable side project could create mappings of purl to known CPEs.

• Why not using the ISO 19770-2 spec for SWID tags instead of a purl?

  • No. This is a proprietary and opaque specification with a centrally managed pay-for-play registry (tagvault). Its purpose is primarily to help inventory installed proprietary software when managing IT assets by assign arbitrary tags to a software binary.

    In contrast a purl is an open way to identify and locate a software package as used in modern software development with no arbitrary central name assignments needed.