Problem/Motivation
Since
π
Limit trusted Composer plugins to a known list, allow user to add more
Fixed
, the Package Manager module will refuse to apply changes if untrusted composer plugins are installed or staged.
change record β
That added \Drupal\package_manager\Validator\ComposerPluginsValidator
, which does:
/**
* Composer plugins known to modify other packages, but that are validated.
*
* (The validation guarantees they are safe to use.)
*
* Keys are composer plugin package names, values are associated validators or
* excluders necessary to make those composer plugins work reliably with the
* Package Manager module.
*
* @var string[][]
*/
private const SUPPORTED_PLUGINS_THAT_DO_MODIFY = [
// cSpell:disable
'cweagans/composer-patches' => ComposerPatchesValidator::class,
'drupal/core-vendor-hardening' => VendorHardeningExcluder::class,
// cSpell:enable
];
/**
* The composer plugins are known not to modify other packages.
*
* @var string[]
*/
private const SUPPORTED_PLUGINS_THAT_DO_NOT_MODIFY = [
// cSpell:disable
'composer/installers',
'dealerdirect/phpcodesniffer-composer-installer',
'drupal/core-composer-scaffold',
'drupal/core-project-message',
'phpstan/extension-installer',
// cSpell:enable
];
Individual sites can expand which composer plugins are allowed by updating the additional_trusted_composer_plugins
key-value pair in the package_manager.settings
configuration.
While necessary for reliability (and arguably security), this opens some new challenges:
- What about contrib modules requiring additional composer plugins? β naΓ―ve answer: they could modify that config β but this would not work because that contrib module would not be installable through Project Browser, it'd have to be manually
composer require
d, and then its hook_install()
could update that config β we need data on how many contrib projects actually depend (directly or indirectly) on composer plugins
- How do we evolve those constants in Drupal core?
- Can we safely allow contrib modules to opt in more composer plugins to this by requiring them to have an associated validator class? β what about dummy validators to just bypass this?
IOW: balancing reliability ("Package Manager should never fail to ensure Project Browser and Automatic Updates never fail") with flexibility ("I want to install Drupal module X, why can't I?!") is tricky.
Steps to reproduce
Proposed resolution
TBD
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet