Dependency patch resolution: Only allow patches from trusted dependencies

[RobinHoutevelts]

Verification

• I have updated Composer to the most recent stable release (composer self-update)
• I have updated Composer Patches to the most recent stable release (composer update cweagans/composer-patches)
• I am using one of the supported PHP versions (8.0+)
• I have searched existing issues and discussions for my idea.

Is your feature request related to a problem?

I only allow patches from sources I trust.
By default cweagans/composer-patches seems to apply patches from any of my dependencies.

Describe your proposed solution(s)

{
   // don't allow patches from anyone else
   "ignore-dependency-patches": ["*"],
   // list of repositories you trust to apply patches from
   "dependency-patches": ["my-org/drupal-patches"]
}

Describe alternatives

No response

Additional context

You will have less bug reports related to Dependency patch resolution if users are forced to know where they want to apply patches from.

However, I don't mind it -not my project- but I would need a way to opt-out and instead define the sources I trust myself.

[github-actions]

👋 Thanks for the idea! Please remember that this is an open source project - feature requests may or may not be implemented, and if they are, the timeline is unknown. If you need a guaranteed implementation or timeline, sponsorships are welcome!

[cweagans]

I'm on board. Maybe we can add another config value 'allow-dependency-patches' and have that act as an allow list if set. I don't want to have to set both. Having both set should probably be an error.

[RobinHoutevelts]

Thanks!

Having both set should probably be an error.

Yes, that would also make this much better to maintain 👍

[RobinHoutevelts]

If I want to disable dependency patch resolution altogether:
Would setting allow-dependency-patches: [] (empty list) achieve that?

Edit: I guess I could cheat by doing allow-dependency-patches: ["drupal/core"] or something since it doesn't define patches 😛

[cweagans]

You can just disable the resolver - no need to try to make an allow list work for that :)

[RobinHoutevelts]

@cweagans I'd be happy to take a stab at adding allow-dependency-patches.
But I'm currently busy for the next two weeks.

[cweagans]

No worries. Same thing here - I'll update here if I beat you to it!

[markfullmer]

Can we clarify the intention of the allow-dependency-patches definition in regards to the current behavior? With the introduction of this option, is it understood that if allow-dependency-patches is NOT defined, there will be no change in the processing of dependency patches, i.e., all will be allowed? In other words, this will be implemented in a way that allows implementers to opt out of a default "allow all dependency patches" behavior?

[cweagans]

Correct. If the option is NOT defined, all dependencies will be scanned for patches. If it IS defined, only the listed packages will be scanned.

[Natshah]

I'm so interested to having this option, something like allow-plugins but it could be called
allowed-patches
or
allowed-patchers

as we do have allowed-packages for drupal-scaffold

      "allowed-packages": [
        "drupal/core", // Only listing to demo
        "vardot/varbase"
      ],

as

      "allowed-dependency-patches": [
        "drupal/core", // Only listing to demo
        "drupal/starshot-patches", // If the Drupal CMS (starshot) team selected a list of important patches.
        "vardot/varbase-patches"
      ]

Maybe in projects the support team could chose to add more patches.
Not to keep coping them every time to 200 projects or more

      "allowed-dependency-patches": [
        "vardot/varbase-patches",
        "my-trusted-private-vendor/private-list-of-patches-by-the-support-team"
      ]