Limit trusted Composer plugins to a known list, allow user to add more [#3331168]

Problem/Motivation

follow-up #3323461: Hosting environment (e.g. cPanel) may add additional files (including symlinks) to the project, which breaks AU — in response to questions raised at #3323461-7: Hosting environment (e.g. cPanel) may add additional files (including symlinks) to the project, which breaks AU

In that issue a site was having problems because the Composer project for Drupal was installed at the base of the hosting account. So in the directory where the project's composer.json was there were other folders such as .cpanel. Some of these folders had symlinks so our SymlinkValidator was stopping Package Manager from working. Even if these folders did not have symlinks there would still be a problem because package_manager by default works by assuming everything under project root should be staged unless a folder is explicitly excluded. If we staged a folder like .cpanel and a change was made to the system this folder after we staged it we could wipe out these changes when we applied the update.

The main reason package_manager stages the whole project directory is because unfortunately even though something is not in the install path of a Composer package does not mean it is not managed by Composer. For instance our drupal/core-composer-scaffold plugin puts index.php and other files in their places and when a core update happens these files might be updated. But if we looked for the path index.php and the other files it manages under any of the install_path's of the packages that Composer knows about they would not be present. Of course we ship with drupal/core-composer-scaffold so we could special case these files.

The problem is if we special case these files then we are implicitly declaring that no other composer plugin can act like drupal/core-composer-scaffold and manage files outside it's install_path because we would not know about the files it manages.

So by default package_manager has been including everything inside the Composer project expect things that explicitly excluded. We exclude paths we know should excluded like the Sqlite db file or the files folder, see the classes under package_manager/src/PathExcluder. Basically we did this because we determined because of how Composer plugins work there is no 100% sure way of knowing what is managed by composer. If we accidentally exclude files that are managed by composer these files will not get updated if a new version of package updates these. Since we don't know the purpose of the files we might miss it is probably best to assume they are critical

Proposed resolution

Create a package manager enforce that only know Composer plugins are allowed.

This validator should:

✅ ~~Subscribe to pre-create, pre-apply, and status-check events~~
✅ ~~Check the active and staged(if exists) directories~~
✅ Add an error if there are any packages that require composer-plugin-api and are allowed via settings of the current composer project(there may be an API that determines this?) and are not in the list of allow plugins
✅ Allow specifying additional allowed composer plugins through configuration (with initially just a $config['package_manager.settings']… line), a UI is for later: #3334906: Improve UX for trusting additional composer plugins

Remaining tasks

✅ ~~Create a core policy issue to be clear that projects with other Composer plugins will have to set this setting~~ → #3335918: [Policy, no patch] Projects depending on composer plugins will have to update the additional_trusted_composer_plugins setting in package_manager.settings
Deviated from point 3, see question in #9: why do we need to check if a package requires composer-plugin-api? Why can't we just check type === 'composer-plugin'?

User interface changes

Instead of allowing all composer plugins by default, restricting to only explicitly trusted composer plugins.

API changes

package_manager.settings configuration now has a additional_trusted_composer_plugins setting, which accepts a list of package names.

The following composer plugins are supported by default:

drupal/core-vendor-hardening
drupal/core-composer-scaffold
drupal/core-project-message
dealerdirect/phpcodesniffer-composer-installer
phpstan/extension-installer
cweagans/composer-patches

(The first 3 are Drupal core's (of which the first comes with an associated excluder: VendorHardeningExcluder), the 4th and 5th are used for Drupal core development and don't interfere with php-tuf/composer-stager and the last one comes with explicit validation: ComposerPatchesValidator.)

Data model changes

None.

Issue fork automatic_updates-3331168

Show commands

Start within a Git clone of the project using the version control instructions.

Add & fetch this issue fork’s repository

Or, if you do not have SSH keys set up on git.drupalcode.org:

Add & fetch this issue fork’s repository

3331168-composer-plugins changes, plain diff MR !659
Check out this branch for the first time

Check out existing branch, if you already have it locally

About issue forks

Comments

Comment #1

4 January 2023 at 23:33

tedbow created an issue. See original summary.

Comment #2

tedbow

he/him

English

Ithaca, NY, USA

commented 4 January 2023 at 23:36

Issue summary:

Title:	Limit allow Composer plugins to a known list	» [PP-2] Limit allow Composer plugins to a known list
Status:	Active	» Needs review
Parent issue:		» #3319030: Drupal Core Roadmap for Package Manager and Update Manager
Related issues:		+#3252299: Reliably support cweagans/composer-patches in Package Manager & Automatic Updates: validate stage, +#3328234: Improve test DX and confidence: stop using VFS

Issue tags:		+blocker
Related issues:		+#3319679: Assert known preconditions for test runs and fail early if unmet

Title:	[PP-2] Limit allow Composer plugins to a known list	» [PP-2] Limit trusted Composer plugins to a known list, allow user to add more
Issue summary:	View changes

Assigned:	wim leers	» tedbow
Issue summary:	View changes
Status:	Needs work	» Needs review
Issue tags:		+Needs documentation updates

Assigned:	tedbow	» wim leers
Status:	Reviewed & tested by the community	» Needs work

Status:	Needs work	» Reviewed & tested by the community
Issue tags:		+Needs followup

Title:	Limit trusted Composer plugins to a known list, allow user to add more	» [PP-1] Limit trusted Composer plugins to a known list, allow user to add more
Assigned:	wim leers	» Unassigned
Status:	Reviewed & tested by the community	» Postponed

Title:	[PP-1] Limit trusted Composer plugins to a known list, allow user to add more	» Limit trusted Composer plugins to a known list, allow user to add more
Status:	Postponed	» Needs work

Assigned:	Unassigned	» wim leers
Status:	Reviewed & tested by the community	» Needs work

Limit trusted Composer plugins to a known list, allow user to add more

Problem/Motivation

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Issue fork automatic_updates-3331168

Comments

⚠️ Failures expected

Next

Question

Change record drafts

Parent issue

Child issues

Related issues

Referenced by