Allow composer location to be configured via the UI

I think we need this. Right now, the documentation (in Package Manager's hook_help) tells you to use Drush, but this is not always an option for site builders, especially not on cheaper hosting.

Since the executables' locations is already configurable, this would not hurt the status quo.

I am trying to sign my commit with a verified signature that Drupal GitLab knows. I am already using ssh keys to sign my commits. Probably does not work the same way with Drupal GitLab.

@phenaproxima I have a question in my mind. Why do not we have a enabled Package Manager from the extend tab?? I can think about that it is meant for developers only. I want to hear your thoughts.

It's hidden because it's not in beta.

Oh, got it. Thank you!

Does drupal core have any other cases where you can set the path of executable from the UI? Just wondering because I guess you could do ton of damage if you could set this whatever you want

Also the summary doesn't mention rsync

Updated the issue summary.

I am not aware of any other place where core allows the paths to executables to be configured, but I can't think of anything else in core which needs to call external executables to work properly.

Maybe we hide it behind a more restrictive permission (administer software updates, which has the "restrict access" flag)?

. I was noting this is something new in #11 not looking to block it. Though we could still add the summary that it is something new and worth the risk to make Package Manager and auto-updates usable on shared hosting

Hostinger currently makes composer 1 and composer 2 available. Composer 1 is composer and Composer 2 is composer2

Did you have to do which composer2 to actually find the path?

So I had to download the phar file and point the project to there to work.

It sounds like if you have to do this already is updating settings.php such a big deal.

Trying to think of admin who has all the skills get composer at a path and/or figure out the current path, where updating settings.php is such a big deal, especially since we get tell you abouting updating settings.php in the status check message

I am not against this just trying figure out the profile of the person we are helping with this

I run a multisite that has composer and composer2 available as two separate executables, for the record. I think that forcing people to alter settings.php -- which can break a lot more things with less recoverability (depending on how you break settings.php, you might not even know what has gone wrong) -- is not very helpful.

IS updated.

Ok. looks good to me

We are helping people on hosts like Hostinger. They have both composer and composer2 installed but neither will work with automatic updates. Once they update their composer2 you would still need to update the path to their composer2 - currently you need to download the phar and place it somewhere yourself. TBH we could have a follow-up with instructions for how to do that because on a lot of cheap hosts it is going to be necessary.

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Looks good - I changed that description to a warning message, which I think is probably the better option (more visible). I removed some of the wording (core UI standards forbid the use of "please" in user-facing text, if I remember correctly), and wrote a test.

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

This looks to me. I guess generally if people are ok with the user setting paths to executables then I am ok with it. 'administer software updates' is already very powerful permission and should not be given to many people

This should have screens shots so I added some.

This is what came to mind while creating them:

• I think an error is in order if the path does not exist.
• The text 'Configure the paths is at the bottom, where I expected it a the top. Like the 'default indexing settings' at admin/config/search/pages.
• The text 'Package Manager' is the only item with capital case at admin/config. Perhaps a more 'functional' name than the module name should be used. And same for the description.
• The form saves on Enter. Is that what is wanted? Some pages do and some don't and that is annoying to me.

I haven't actually tried out the functionality!

. I guess generally if people are ok with the user setting paths to executables then I am ok with it

I think the main risk is via XSS account takeover, and then using that permission to set paths to executables. That's already a problem with project browser though - in that someone could take over an account and install devel on production or similar.

However assuming we do ✨ Require password for certain admin actions Active for this and also for installing new modules, that should be mitigated a lot.

Having said that, does this need additional validation of the string? We could restrict it to only a-z + forward slashes for example.

Back to needs work for #25 and possibly the validation in #26.

Addressed #25 and #26, except for:

The form saves on Enter. Is that what is wanted? Some pages do and some don't and that is annoying to me.

I very much doubt that this has anything to do with Package Manager itself, it just uses ConfigFormBase like many other settings forms in core do. But maybe this merits a follow-up (in Claro)?

+1 to concerns raised in #26 / #27.

Allowing the path to an executable to be set in the UI is a really valuable way for an attacker to escalate XSS to RCE.

One recent related issue was adding Symfony Mailer transports to core 📌 [PP-1] Add symfony mailer transports to DIC Postponed where I believe it's necessary to set anything non-standard via settings.php.

Validation is really important (noting the value is being checked on submit with is_executable() and there are tests showing that command -args type values will fail).

I agree that this makes ✨ Require password for certain admin actions Active a high priority security hardening.