Add PHP PEAR/PECL type

[LaurentGoderre]

Add Purl type for PHP PECL package type

[LaurentGoderre]

anchore/syft#2604

[pombredanne]

@LaurentGoderre Thanks! Can you elaborate a bit on PECL?
Is there some extra information that would need to go in this Package URL definition?

Is there some API, spec documentation of similar that you can reference (at least in comments here)?

Also, could it be that PECL is just an alternate channel/repository for PEAR?

And can you add tests to the JSON test-suite-data.json test data file?

[pombredanne]

What is the standard case? is this normalized to lower case? Is there a spec/doc for this?
For instance, https://pecl.php.net/package/ApacheAccessor points to a proper page, and so is https://pecl.php.net/package/apacheaccessor but this is not true for https://pecl.php.net/rest/p/apacheaccessor/info.xml which is OK, but https://pecl.php.net/rest/p/ApacheAccessor/info.xml is not. So it seems that the name IS case insensitive BUT normalized to lowercase or something else.... if you could research this, it would be great.

[LaurentGoderre]

@pombredanne wouldn't the behavior of the CLI take prescende over how their site is configured? In the CLI, the case doesn't matter. From the site though it doesn't seem like it's normalized to lowercase

[LaurentGoderre]

PECL and PEAR are different. PEAR is closer to composer as it is PHP code vs PECL which is native extensions to PHP.

[LaurentGoderre]

Added some tests but the docs doesn't specify how to run the tests

[matt-phylum]

The PECL page says that PECL is PEAR:

The packaging and distribution system used by PECL is shared with its sister, PEAR.

https://pecl.php.net/

[LaurentGoderre]

You can't use interchangeably

root@5a371520ac37:/# pear install APCu
No releases available for package "pear.php.net/APCu" - package pecl/APCu can be installed with "pecl install APCu"
install failed

root@5a371520ac37:/# pecl install Archive_Tar
No releases available for package "pecl.php.net/Archive_Tar"
install failed

[matt-phylum]

Not being able to install them the same way doesn't mean they aren't the same system. They use the same protocol with different repository_urls (channels).

$ pear channel-info pecl.php.net
Channel pecl.php.net Information:
=================================
Name and Server         pecl.php.net
Alias                   pecl
Summary                 PHP Extension Community Library
Validation Package Name PEAR_Validator_PECL
Validation Package      1.0
Version
Server Capabilities
===================
Type Version/REST type Function Name/REST base
rest REST1.0           https://pecl.php.net/rest/
rest REST1.1           https://pecl.php.net/rest/

$ pecl channel-info pear.php.net
Channel pear.php.net Information:
=================================
Name and Server         pear.php.net
Alias                   pear
Summary                 PHP Extension and Application Repository
Validation Package Name PEAR_Validate
Validation Package      default
Version
Server Capabilities
===================
Type Version/REST type Function Name/REST base
rest REST1.0           http://pear.php.net/rest/
rest REST1.1           http://pear.php.net/rest/
rest REST1.2           http://pear.php.net/rest/
rest REST1.3           http://pear.php.net/rest/
Channel pear.php.net Mirrors:
=============================
us.pear.php.net
de.pear.php.net
Mirror us.pear.php.net Capabilities
===================================
Type Version/REST type Function Name/REST base
rest REST1.0           http://us.pear.php.net/rest/
rest REST1.1           http://us.pear.php.net/rest/
rest REST1.2           http://us.pear.php.net/rest/
rest REST1.3           http://us.pear.php.net/rest/
Mirror de.pear.php.net Capabilities
===================================
Type Version/REST type Function Name/REST base
rest REST1.0           https://de.pear.php.net/rest/
rest REST1.1           https://de.pear.php.net/rest/
rest REST1.2           https://de.pear.php.net/rest/
rest REST1.3           https://de.pear.php.net/rest/

pecl is actually pear with PEAR_RUNTIME set to pear.

You can't use interchangeably

root@5a371520ac37:/# pear install APCu
No releases available for package "pear.php.net/APCu" - package pecl/APCu can be installed with "pecl install APCu"
install failed

root@5a371520ac37:/# pecl install Archive_Tar
No releases available for package "pecl.php.net/Archive_Tar"
install failed

You can install pecl packages using pear.

$ pear install pecl.php.net/APCu
…
install ok: channel://pecl.php.net/apcu-5.1.23
configuration option "php_ini" is not set to php.ini location
You should add "extension=apcu.so" to php.ini

But going the other direction doesn't work?

$ pecl install pear.php.net/Archive_Tar
pear.php.net is using an unsupported protocol - This should never happen. Use --force to continue
install failed

Having incompatible packages doesn't necessarily mean they are different package types. alpm, apk, etc have incompatible packages in different repositories (ie there is no alpine or openwrt package type). gem stores incompatible packages in the same repository (jruby).

If pear and pecl packages are typically managed using different files for different purposes, maybe both types should be added, referencing each other since it seems like for PURL implementations they are nearly identical.

To use the same package type, if you had a list of pecl extensions you could write them as pkg:pear/name?runtime=pecl or pkg:pear/name?repository_url=https://pecl.php.net/ instead of pkg:pecl/name.

[LaurentGoderre]

@matt-phylum in my opinion, what is being installed (native extensions vs PHP code) is different enough to warrant distinct Purls

[LaurentGoderre]

@matt-phylum @pombredanne After some consideration, I updated the PR to have pear as the type that support both PEAR and PECL.

Here is the PR for the modified implementation in Syft: anchore/syft#2775

[LaurentGoderre]

@pombredanne can you take another look at this?

[jkowalleck]

The current draft looks good to me. 👍

• "pear" is the package manager used to fetch pear- and pecl-php-extensions/-applications, each from their respective repository.
• having the repository as the "namespace" sense, since it functions as such.
  The actual php-extensions/-applications do not have a namespace on tier own, and even if they had, we could still bring that in like pkg:/pear/pecl.php.net/Me/APCu@5.1.23 and pkg:/pear/pecl.php.net/You/APCu@5.1.23.
  as domain names are lowercase per RFC, I would add this to the spec.

A thing I see missing is: how to handle static packages?
which qualifiers should be used to indicate the location, and which channel should be named to indicate this?
pear CLI uses channel __uri to do so.
Possible solution: in case a static URL was used, use PURL's well-known qualifier download_url, and namespace/channel __uri

---

a feasible alternative to the currnet draft could be:

• do not use PEAR channels as namespaces.
• PEAR channels are indicated as PURL qualifier channel, default is pear.php.net.
• in case a static url was used, use PURL's well-known qualifier download_url, and omit channel qualifier

i would prefer the current draft over the shown alternative.

[matt-phylum]

If the namespace of the PURL contains information for channel discovery, how does it interact with repository_url qualifier? Does repository_url override the base URL that would normally be determined through channel discovery?

[LaurentGoderre]

@matt-phylum I am not sure....

[LaurentGoderre]

@cweiske do you think you can review as a PEAR contributor?