Determine how new Composer plugins will be supported

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.

Did you mean trusted?

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?

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.

What about sites that already has package manager version that thinks that plugin is support?

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.

Should we support specific version constraints?

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 📌 Limit trusted Composer plugins to a known list, allow user to add more Fixed ?

Maybe instead of becoming "trusted" plugins should just have specify that they work with Package Manager through metadata?

-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-stager works?! 😅

Of course they could do so maliciously but also any Drupal module could remove all of our validators through a service alter.

Don't assume malicious intent. Assume laziness, ignorance, "getting things done", etc. 🙈

Don't assume malicious intent.

I 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

#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!

I 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.

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.

Of course!

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.

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!

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.

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 😊