follow-up to #3331168: Limit trusted Composer plugins to a known list, allow user to add more
Originally that merge request had
* It is recommended to request additional composer plugins that have been
* trusted to become officially supported: please create a new issue on
* drupal.org.
but I am not sure we just want plugins to become officially supported because then we have to figure out how a plugin becomes untrusted.
Would the maintainers just ask because they want to add functionality to their plugin that might not be compatible with Package Manager, assuming their plugins purpose is something else than Package Manager specific? What about sites that already has package manager version that thinks that plugin is support?
Should we support specific version constraints?
Maybe instead of becoming "trusted" plugins should just have specify that they work with Package Manager through metadata? Or implemented an interface? Of course they could do so maliciously but also any Drupal module could remove all of our validators through a service alter.
Possible ways a plugin could be trusted or supported once this module is in Drupal core
A contrib module could also make a UI for this or update the config with a list that keep track of.
Possible ways plugin could declare itself compatible
If we did this it would have to be clear who is responsible for this. Who gets the final say? Who is suppose to check to make sure the plugins are still compatible? Who responds to issues if someone says with a composer plugin is not compatible? Who vets a new version of plugin after a new version comes out that is beyond our current constraints? Is it whoever is in MAINTAINERS.txt package_manager? Is it a new role?
Comments
Comment #2
wim leersDid you mean trusted?
Most composer plugins are not maintained by Drupalists. So I doubt that composer plugin maintainers would ask this. I think mostly site builders (who just want to use Package Manager but can't) and module developers (who depend on some composer plugin and want to ensure that their module can be installed through Package Manager) would create such issues.
Sites manually trusted that plugin, that can continue to be true — it's up to them to manually remove it from the config just like they manually added it.
Perhaps we should … but that could become a massive chore. But yes, if we mark a version 1 of a plugin as supported but then version 2 is released, that could become a problem. Perhaps we should add that to the scope of #3331168: Limit trusted Composer plugins to a known list, allow user to add more?
-1, because 99% of composer plugins are not written by Drupalists and their maintainers will not want to add Drupal-specific logic. Plus, can we trust them to correctly assess if a particular plugin interferes with how
php-tuf/composer-stagerworks?! 😅Don't assume malicious intent. Assume laziness, ignorance, "getting things done", etc. 🙈
Comment #3
tedbowI think since we are making a system that is meant to deliver unattended critical updates to 10 of thousands of websites we have to consider malicious intent
Comment #4
tedbowComment #5
wim leers#3: Right, I actually agree with that. You pulled my response out of context.
In what I wrote, I was explaining that I do not want to trust any plugin declaring itself as supported. And near the end I said "don't assume malicious intent, assume […]" → those things I said to assume are far less malicious reasons with the same disastrous outcome: a site that gets broken when using Package Manager because simply declaring a composer plugin as supported is not a guarantee that it doesn't do anything that causes problems when using
php-tuf/composer-stager!This is the same problem as exists with vetting Drupal migrations: the mere existence of a migration is not remotely a guarantee that it will actually migrate the data. It is only a promise that there is some code to execute, but who knows if that code does what you hope/think it will!
Comment #6
tedbowI put some ideas in the issue summary
I really think this is a post-mvp question because it really will be determined by how much responsibility core maintainers want to take on.
Honestly I have to say that if the core decision is that core maintainers will vet plugins, beside the current plugins approved, and if this would fall on the package_manager maintainers this would affect my decision on whether I would offer to be a package_manager maintainer. Especially if there were only a couple maintainers.
I think if there are only a couple maintainers their time would be better used just maintaining the module and I would not want to take on a responsibility I realistically don't think I would have time for.
I think also if this responsibility was not specifically called out as part of someone's roll in MAINTAINERS.txt it just would not get done.
I think it would be more responsible for core maintainers NOT to take on the task vetting plugins than to take on the task and it not get done.
Comment #7
tedbowComment #8
wim leersOf course!
Plenty of things just "do not get done" in plenty of components in Drupal core. You being listed as the maintainer does not mean you have to implement these things; it just means you are one of the people who is able to assess whether something is ready/solid/safe to be added to Package Manager. You could totally just be a reviewer on such an issue, and not write a single line of code. Especially because adding support for a new composer plugin would be a feature request, not a bug report!
Agreed! The point is rather that we as the collective Drupal core maintainers and contributors should vet composer plugins that are very widely adopted, because if not, A) we put the burden on thousands of less technical people, which B) would cause those people to just trust additional composer plugins blindly without understanding the consequences, which C) would cause negative (and potentially even disastrous) experiences for Package Manager users and hence Drupal in general.
That is my concern and my intent here: that Drupal core makes it feasible for less technical people to successfully use Package Manager without shooting themselves in the foot on the most commonly used packages in the Drupal ecosystem — which may include some additional composer plugins that we don't know about yet (i.e. in addition to
cweagans/composer-patches). That's all 😊Comment #9
tedbowComment #10
tedbow