Problem/Motivation

In manually testing this module, I discovered that my web server, nginx, doesn't have Composer available in its PATH. That's all well and good, because we have a documented procedure for configuring the path to Composer.

But you have to edit settings.php to do this, similar to other settings and configuration that is documented in sites/default/default.settings.php. Once this module is in core we could presumably add this as an example you could uncomment in default.settings.php.

You could also install Drush and do something like drush cset package_manager.settings executables.composer /path/to/composer, or you set it manually in config and import, or...probably other ways.

We should determine if editing settings.php will be too difficult for AutoUpdates target audience. The error message is probably scary enough to people who aren't very technical; the path to remediate the error is even scarier. This is not good. We should provide a UI for configuring the path to Composer -- a simple configuration form.

I understand that there are security implications there -- you're literally configuring the path to an executable which we will run -- so I'm not yet calling this issue a stable blocker until we have confirmation from the security team that it's okay to provide a UI like this, and what the appropriate hardening might be (maybe we should provide the UI but only make it accessible to user 1).

Steps to reproduce

In an environment where the PHP interpreter doesn't have Composer in its PATH, install this module. You'll get the error right away and have no way to fix it except with the methods I mentioned above, or some other techy thing.

Proposed resolution

Add a UI to configure the path to Composer.

Remaining tasks

Get the blessing of the security team and decide on what, if any, hardening there should be around this UI. Then build a configuration form for this with a simple functional test.

Command icon Show commands

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

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

Comments

phenaproxima created an issue. See original summary.

phenaproxima’s picture

Component: Code » User interface
phenaproxima’s picture

Issue summary: View changes
tedbow’s picture

Issue summary: View changes
Theresa.Grannum’s picture

Assigned: Unassigned » Theresa.Grannum

tedbow’s picture

Assigned: Theresa.Grannum » Unassigned

unassign because the issue hasn't been worked on

tedbow’s picture

I don't really think this is necessary.

I think anyone who can figure out the correct path can update it via settings.php. Adding the configuration opens up a security vulnerability because it can point to any executable.

Also it is something that might be different from environment to environment so it was in config that would complicated to change.

phenaproxima’s picture

I think anyone who can figure out the correct path can update it via settings.php.

I don't know if I necessarily agree with this assumption, but I can't back that up.

Adding the configuration opens up a security vulnerability because it can point to any executable.

I agree it's a security risk. Personally, I think that, if we did this, it would make sense to only show that one field to user 1.

Also it is something that might be different from environment to environment so it was in config that would complicated to change.

Solutions exist to change config from environment to environment, and such things are definitely in use. I don't think this would be all that complicated from a site owner/developer perspective.

Honestly, my preference is for the security team to be the final word here.

That said, I definitely do not think this is a high priority at all. People have been able to change the path to Composer in settings.php with guidance during in-person testing sessions, and with instructions. It's documented in our online help. So there's a definite path for people who need to configure this.

tedbow’s picture

Priority: Normal » Minor

That said, I definitely do not think this is a high priority at all.

just reflecting that on the issue

tedbow’s picture

Issue tags: +core-post-mvp
tedbow’s picture

Version: 8.x-2.x-dev » 3.0.x-dev
tedbow’s picture

Status: Active » Closed (works as designed)
Issue tags: -core-post-mvp

Right now I don't think we are going to fix this. We have way to set this via settings.php and the audience that would know which Composer version is correct I think would not have a problem editing settings.php.

If this had no security implications then that would be another but it does so forcing someone to edit settings.php or run a drush command to set the config is not that much of an ask.