GitLab

Overview

In civicrm-core:composer.json, there are a series of script declarations. One of the most common elements of these scripts is that the clean out example files.

Example use-case

There are two basic scenarios for deploying civicrm-core.git:

• (A) CiviCRM as root-project/application

  git clone https://github.com/civicrm/civicrm-core.git civircm
  cd civicrm
  composer install

• (B) CiviCRM as library/dependency in another root-project/application

  composer create-project drupal/recommended-project my-site
  cd my-site
  composer require civicrm/civicrm-core

Current behavior

In scenario (A), various files (examples/docs/tests) under vendor are cleaned out.

In scenario (B), they are not.

For a list of specific items that are currently cleaned, see:

grep safe_delete tools/scripts/composer/*.sh

Proposed behavior

1. It should be possible to clean out these artifacts in both scenarios.
2. The cleaning mechanism and rules should be the same (shared) in both scenarios.
3. The cleaning should be optional - so that (a) it is possible to create a development-oriented build and (b) it is possible to choose some cleaner that is designated by the CMS community.
4. (Low priority) The cleaning should be enabled by default (i.e. opt-out).
5. When cleaning scenario (B), one should converge on identical code in each sub-case: (i) creating a project and adding CiviCRM to it anew; (ii) taking an existing composer.json (with CiviCRM and everything else), deleting the vendor/ tree, and re-running composer install; (iii) performing updates on an existing project.

Many of th rules in tools/scripts/composer/*.sh could potentially be replaced by some kind of composer-based cleaning plugin.

Comments

The list of composer plugins includes a few focused on cleaning up vendor. I haven't fully assessed how these match up with the proposed behavior.

• https://github.com/barryvdh/composer-cleanup-plugin
• https://github.com/dg/composer-cleaner
• https://github.com/lichunqiang/composer-ignore-plugin
• https://github.com/liborm85/composer-vendor-cleaner
• https://github.com/drupal/core-vendor-hardening

If you were comparing (A) w/d7 against (B) w/D8, you might observe that cleaning artifacts is less important in the latter case because vendor is hidden. That means *.php files aren't web-accessible. Never-the-less, even in (B), there is a file-sync operation to publish assets, and this could publish example/test/doc files in JS/CSS/etc format. Vulnerabilities in that case are less likely and more constrained (e.g. it probably cannot execute arbitrary PHP code; but OTOH the browser trusts JS files based on their origin, and that might be exploitable in some poorly written JS demo file).