[Policy, no patch] Projects depending on composer plugins will have to update the additional_trusted_composer_plugins setting in package_manager.settings

Problem/Motivation

Since #3331168: Limit trusted Composer plugins to a known list, allow user to add more, 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 required, 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