Composer Class Manager

Perched colorful bird with a fish in its beak
Original Source: Pixabay

Yesterday I made a rant about the Composer system for managing PHP dependencies.

I went a bit overboard, I understand that. Composer does make a lot of things easier for developers of reusable PHP classes, and also makes it easier for users to install them on operating systems that do not have good quality package management.

My complaint can be solved without boycotting composer as I ranted about.

My biggest concerns are the following:

A) Composer involves an awful lot of trust, you have to trust that every dependency and their dependencies are from package repositories that are both trustworthy and well maintained.

B) Composer does not have a good way to validate the installation of dependencies, e.g. I can not import public signing keys from developers I trust and have composer automatically reject dependencies that are not properly signed by a signing key I trust. And if it did have such facilities, it would be a nightmare to maintain due to the number of different developers. Package A may depend upon Package B and I may trust both, but an update to Package B may gain a new dependency on Package C that I do not have a reason to trust, meaning I can no longer update A if it requires the updated B, and if the non-updated B is insecure I can not update B to the secure update unless I trust C.

C) Installation of dependencies within the package directory is akin to static linking which is dangerous for many reasons. If the maintainer of Package A never updates their code to use the secured version of B but continues to specify an old insecure version of B then Package A is not secure.

My concerns are concerns that really are for deployment system administration.

I plan to solve them by creating a package repository structure for global installation of Composer packages managed by the native package manager of the operating system.

Assuming it will be called CCM (bad name, but the name I want – EMF for Ecstasy Mother Fucker – probably does not have good market appeal. Besides, the band EMF might take issue with it, since it was often rumored that is what their EMF stood for) the base directory for the repository would be /usr/share/EMF er I mean /usr/share/ccm.

Within that base there would be three package directory trees: stable, devel, and local.

The purpose of stable would be to contain latest stable versions of the package by vendor/packagename using the same naming scheme that Composer uses.

The purpose of local would be for cases where an older version of the same dependency really honestly is needed.

The purpose of devel would be for cases where bleeding edge not yet stable releases are needed.

The system administrator could then specify the PHP include path order based upon the needs of the web application using the libraries.

This will not solve all scenarios where a web application does not work with the current stable version of a dependency, but it should solve most.

RPM Packages

I have been packaging RPM packages since Red Hat 5.2 days, and currently maintain both the LibreLAMP and AWEL Media package repositories. I will start fleshing out this idea with RPM but hope that the same packages can be created for other operating systems.

The spec files for packages will need to have some packaging guidelines.

First of all, pristine source with checksum validation in the RPM spec file, similar to what the EPEL Postgresql package does:

( cd %_sourcedir; sha256sum -c %{SOURCE16}; sha256sum -c %{SOURCE17} )

Before it even unpacks the source tarball, it validates the sha256sum of the source tarball. That is classy. I might do it a little different, define the sha256sum in the spec file itself.

The spec file to build a “stable” version will be the same spec file that builds a “local” version. When building a local version of package bar from vendor foo:

rpmbuild -D 'local 1' php-ccm-foo-bar.spec

Defining the local macro will cause it to put its files in /usr/share/ccm/local instead of into /usr/share/ccm/stable and give the resulting RPM the name of php-ccm-foo-bar-local with a Provides of php-ccm-foo-bar = %{version}-%{release}.

Only noarch packages will be allowed, nothing that includes binaries.

When security issues are found, patches can be created that address the issue whether or not the upstream vendor has addressed it. So a security issue in foo/bar that exists in all versions, patches can be made for spec files for all versions so that those who need an older version can do a git checkout of the spec file for the older version and if available it will include a patch that fixes the security issue, even if the vendor did not backport the fix to older versions.

I would like to develop some code review standards. Some are obvious, e.g. any library that does remote includes will have to be patched not to, any libraries that add third party resources to the HTML output will have to be patched not to (even jQuery CDN hosting of jquery is not appropriate), etc.

A yum repository for stable packages will be maintained that is distribution independent.

Here’s the kicker. In Yesterday’s blog post, I said quite passionately that Composer should be avoided. Well, now I instead want to require that libraries packaged for this repository are install-able by composer.

Why? For several reasons.

First of all, I want to use the Composer vendor/package scheme. Secondly, composer really does make life easier for both developers and for users who do not have an operating system with a package manager that will work with this project idea of mine. I have to concede that point.

I fucking hate that Composer has caused many developers to stop contributing to PEAR and I do not want to make this repository have the same impact for people who currently are happy with Composer that Composer had on PEAR. And some people think autistics have no empathy…

Anyway – so that is something I will be doing. I will start by packaging some of the Composer based plugins for Roundcube, and when I have a more solid plan, I’ll do an announcement and seek package contributors and stuff.

Alice Out.


One thought on “Composer Class Manager

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s