[policy] Move composer/composer from a dev dependency to a production dependency

+1 also in needs policy to update as security releases for linux and windows are different for composer

I understand the motivation behind this, but I would like to ask a purely technical question: if composer/composer becomes a drupal/core dependency, do we also get a new Drupal core security advisory for every Composer security advisory? (Do we get a new drupal-core-recommended release every time when a Composer security update is released?)

I am asking this because as of today we run symfonycorp/cli also known as fabpot/local-php-security-checker on our PRs/CRs/MRs and as scheduled check on every project; and whenever there is a Composer security update, we also get warnings about those from the CI. Why? Because some dev dependencies are rightfully requiring composer/composer as a dev dependency (like Composer plugins) and in non-dev envs we install projects with composer install and not with composer install --no-dev (to be able run tests, etc.). But, even if Composer is available in [project_root]/vendor/bin, I think nobody is using it (at least not before automated updates), everybody is using the project independent Composer binary installed somewhere on the system, so these are 99% false-positive warnings already. Adding Composer as a drupal/core dependency will bring this problem to production environments too. (Nightmare vision: even if we will provide a code drop to an on-prem customer with the result of composer install, their security team/scanner may through that back to us because it will contain a sec. vulnerable Composer version that they do/should not use either way.)

(hm, maybe if the binary/cli app and the "framework" called Composer would be separate packages that improve the situation, but I am sceptical if Composer devs would be open for a refactoring like this.)

@mxr576 #3198340: Strict constraints in drupal/core-recommended make it harder for Composer-managed sites to apply their own security updates when a core update is not available discusses relaxing core-recommended, I think that becomes even more important if Composer is a production dependency.

next regular bug-fix or minor release would likely get onto that version, so scanners would get satisfied eventually.

We do issue off-schedule normal patch releases to change the lockfile/metapackage versions at least (edit: on a best-effort basis when the release managers are available and the core release schedule allows it), although constraints will not be increased unless the exploit is in core. (E.g. last week, we were two minor releases behind on Twig, so we did not increase our Twig constraint since the vuln requires an admin permission to exploit in core, because otherwise it would have forced a minor update in a patch release.)

We run into so many issues with composer/composer as a dependency, and having a duplicate version of composer installed in vendor/bin means that version gets used, but it cannot self-update itself when being used with composer-patches as well as core-composer-scaffold. Please do not add this dependency to drupal/core as a production dependency.

The error we often run into is the following:

error:In FilesystemRepository.php line 163: file_get_contents(/var/www/html/vendor/composer/composer/src/Composer/Repository/../InstalledVersions.php): failed to open stream: No such file or directory

Because composer gets installed in the vendor directory, and it has a relative path to trying to find the InstalledVersions.php file, it cannot find it and it fails.

As a workaround, we have to specifically run a composer update composer/composer first, before we do any other composer update commands.

#3163923: composer/composer dependency in drupal/core-composer-scaffold fails to update composer
https://github.com/composer/composer/issues/9937

I have a potential solution for that in Package Manager, @Dave Reid: #3309220: Remove runtime dependency on composer/composer

@Dave Reid, I'd like to understand more details about the problems you run into, because if I (and others) understood them better, it's possible we could implement workarounds, guardrails, and maybe straight-up fixes in Package Manager/Automatic Updates (or perhaps, for that matter, Composer itself).

Would you be able to describe for me the layout of a project that you'd run into problems with? (Or provide a sample bare-bones composer.json that I could use to set up an environment like that?) And then maybe a few tasks/commands you try to run which break it?

It's worth mentioning that @tedbow and I are debating how and if to remove composer/composer as a runtime dependency from Automatic Updates. I opened a meta for it and outlined my proposed plan: #3316368: Remove our runtime dependency on composer/composer: remove ComposerUtility

Postponing on #3316368: Remove our runtime dependency on composer/composer: remove ComposerUtility, seems (much) better to avoid it if we can.

#14 Captured that in #3316368-6: Remove our runtime dependency on composer/composer: remove ComposerUtility 👍

I think we should close this issue as outdated.

We're already nearly done removing our runtime dependency on composer/composer and ripping out the ComposerUtility class which relies on it. So if composer/composer is moved into core's runtime dependencies, it won't be the Automatic Updates Initiative's doing.