Problem/Motivation

Follow-up for #3331168: Limit trusted Composer plugins to a known list, allow user to add more. The core-mvp UX is:

Allow specifying additional allowed composer plugins through configuration (with initially just a $config['package_manager.settings']… line)

But ideally:

  1. There is a UI
  2. That UI should warn the user about the risks and potential implications
  3. Whenever the user uses Package Manager (no matter whether it's installing new modules through https://www.drupal.org/project/project_browser or installing updates that require different composer plugins)
  4. Related: there should be a status report entry both warning the user that they've configured additional allowed composer plugins and it should be considered an error if some of those additions are no longer present in the codebase

Steps to reproduce

Use additional composer plugins beyond:

  1. drupal/core-vendor-hardening
  2. drupal/core-composer-scaffold
  3. drupal/core-project-message
  4. dealerdirect/phpcodesniffer-composer-installer
  5. phpstan/extension-installer
  6. 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.)

Proposed resolution

TBD

Remaining tasks

User interface changes

API changes

Data model changes

Comments

Wim Leers created an issue. See original summary.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Title: [PP-1] Improve UX for allowing configuring additional composer plugins » [PP-1] Improve UX for trusting additional composer plugins
tedbow’s picture

tedbow
he/him
Primary language English
Location Ithaca, NY, USA
commented
Status: Postponed » Active

I am not convinced this should be UI.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Title: [PP-1] Improve UX for trusting additional composer plugins » Improve UX for trusting additional composer plugins

I think you're saying that requiring manual modification to the configuration is sufficient?

If so: fair enough. I can see arguments either way. But what should still happen IMHO is improving the message: right now ComposerPluginsValidator just tells the user a composer plugin is not supported:

      $unsupported_plugins_messages = array_map(
        fn (string $raw_allowed_plugin_name) => new FormattableMarkup(
          "<code>@package_name

",
[
'@package_name' => $raw_allowed_plugin_name,
]
),
$unsupported_plugins
);
$summary = $this->formatPlural(
count($unsupported_plugins),
'An unsupported Composer plugin was detected.',
'Unsupported Composer plugins were detected.',
);
$event->addError($unsupported_plugins_messages, $summary);

→ this just generates a list, without providing the user a course of action.

Stupidly, I went 99% of the way in #3331168: Limit trusted Composer plugins to a known list, allow user to add more because I provided a hook_help() entry:

      $output .= '<h4 id="package-manager-faq-unsupported-composer-plugin">' . t('What if it says I have unsupported composer plugins in my codebase?') . '</h4>';
      $output .= '<p>' . t('A fresh Drupal installation only uses supported composer plugins, but some modules or themes may depend on additional composer plugins. Please <a href=":new-issue">create a new issue</a> when you encounter this.', [
        ':new-issue' => 'https://www.drupal.org/node/add/project-issue/automatic_updates',
      ]) . '</p>';
      $output .= '<p>' . t('It is possible to <em>trust</em> additional composer plugins, but this requires significant expertise: understanding the code of that composer plugin, what the effects on the file system are and how it affects the Package Manager module. Some composer plugins could result in a broken site!') . '</p>';

but failed to link to it from the validation message 🙈🙈🙈

Maybe that's the only remaining thing to do here? 😊

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

d.o rendering fail 🤷‍♀️

tedbow’s picture

tedbow
he/him
Primary language English
Location Ithaca, NY, USA
commented
Version: 8.x-2.x-dev » 3.0.x-dev
wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Related issues: +#3340022: Tighten ComposerPluginsValidator: support only specified version constraint

Note that in #3340022: Tighten ComposerPluginsValidator: support only specified version constraint, ComposerPluginsValidator is becoming stricter. But this same UX can be used to trust unsupported versions of supported Composer plugins 👍

ressa’s picture

ressa
he/him
commented

It's great to see all the efforts going into getting Automatic Updates ready, so thanks for that.

If you have https://www.drupal.org/project/openai installed, you get this message on /admin/reports/updates/update:

An unsupported Composer plugin was detected.
    php-http/discovery

Does this mean that Automatic Updates will not work, or might it work, but not guaranteed to work?

Should I create a separate issue for Automatic Update support for this Composer plugin?