I am also interested in the "Commerce License Access Control" module, so I made a fresh installation of D10 and Commerce, with the same Commerce license access control fork/patch, and ACL-2.0.0-beta1, and could not reproduce the issue, at least not with this URL /user/xx/licenses
If the error occurs on an Oracle Linux (8) (and Fedora?), one possibility for the error could be this.
Try this in project folder:
Run composer install -vvv
Look for: sh: patch: command not found
If the error message can be confirmed...
Run dnf install --assumeyes --quiet patch
I don't know if --assumeyes --quiet are necessary, I don't know anything about this OS, but I would think they can be dispensed with, but it works with them anyway. The problem is not on Ubuntu, but may be other distros are missing this "patch installation".
Drupal 8 end of life November, 2021.
Drupal 9 end of life November, 2023.
So the safe choice is to update them to Drupal 10, but it is not a complete rewrite either, but minor adjustments to deprecations etc ;)
Thank you for a pleasant, useful and complete answer. I will contact Lunar-onlinepayments and tell them that they have a Drupal module at Paylike which with a few adjustments is ready for use in production, then we have to see if they are ready to pay for the ongoing maintenance, the target group is somewhat smaller than, for example, your Woocommerce module ;)
I've tried (in test mode) this module (Paylike) when Drupal 8 was current and it seemed pretty robust and everything worked as expected, I wouldn't be sorry to use it in production, in fact would be safe and happy. But Lunar online payments has a complete package with bank, acquirer and provider, which I am very interested in and can see that the road to that is not long due to Lunar's acquisition of Paylike which has your Drupal module, hence this inquiry.
Thanks for the work in making these modules available.
Perhaps this is a good time to make this module "green".
Is this module affected by this security hole?
"As this is an API module, it is only exploitable if a "client" module exposes the vulnerability. Details of some contributed client modules are given below. Custom modules using ACL could also expose the vulnerability.
This vulnerability is mitigated by the fact that an attacker typically needs an "admin"-type permission provided by one of ACL's client modules."
ACL - Critical - Arbitrary PHP code execution - SA-CONTRIB-2023-034 →
I have tested a client module's functions with "pfrenssen" fork and it works as expected in D10.
The client model can be added as part of the ACL ecosystem on the ACL project front page. :)
"drupal/commerce_license_access_control": "dev-3345299-updates-for-d10"
Commerce License Access Control →
DDEV 1.22.1
PHP Version 8.2.8 (8.1)
Drupal Version 10.1.2
Commerce Core 8.x-2.36
Commerce License 3.0.0
ACL": (fork) "dev-3285916-automated-drupal-10"
+1
One definitely wants an access related module is "green"
"dev-3345299-updates-for-d10" Works fine :)
DDEV 1.22.1
PHP Version 8.2.8 (8.1)
Drupal Version 10.1.2
Commerce Core 8.x-2.36
Commerce License 3.0.0
ACL": (fork) "dev-3285916-automated-drupal-10"