@dillix I know that and I also hope that you get full access to the module, but I have been lurking here for a few years and noticed that Salvis is very careful about who he gives full access to the module but opens the door ajar and wants to see extensive and essential contributions from the applicant first. You might think that is a bit too cautious an approach, but we saw last summer how chaotic it became when a (talented) developer got full access to "Inline Entity Form", only had his own use case in mind but ruined it for a lot of others.
I have no talent in development, so I am selfish and just want a stable release with security coverage for ACL, a big hurdle for me was when Drupal Commerce/Centarro recently became maintainers of "Commerce License Access Control" and now just need a stable release with security coverage for ACL before I dare use it in production. That's why I thought Salvis might be a little more lenient if it was a company with an exceptional reputation within the Drupal community that became a co-maintainer.
I wish you the best with your application. :)
@salvis - Drupal Commerce/Centarro recently became maintainers of "Commerce License Access Control" which has the ACL module as a dependency. They probably have a use case/customer and are therefore also interested in an actively maintained ACL module. Maybe it would be an idea to contact them and ask if they are interested in becoming active maintainers, allocating resources and having write access/access to project repository to the ACL module, if you don't have the time and need for the module yourself., The ACL module deserves a stable release with security coverage and be D11> future-proofed :)
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"