Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
C
Core
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 933
    • Issues 933
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Incidents
  • Analytics
    • Analytics
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
  • Development
  • Core
  • Issues
  • #1591

Closed
Open
Opened Feb 13, 2020 by totten@tottenOwner

Vendor pruning should support D8-style root-projects

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).

Edited Feb 13, 2020 by totten
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: dev/core#1591