Would be good to update brick/math so that php 8.1 is supported without deprecated messages

Would be good to update brick/math so that php 8.1 is supported without deprecated messages

Agree, I am looking into it but for some reason composer update does not update this package.

Ok, so I found the issue:

  Problem 1
    - Root composer.json requires brick/math ^0.9.3, found brick/math[0.9.3] but these were not loaded, likely because it conflicts with another require.
  Problem 2
    - spomky-labs/cbor-php v1.1.1 requires brick/math ^0.8.15 -> found brick/math[0.8.15, 0.8.16, 0.8.17] but it conflicts with your root composer.json require (^0.9.3).
    - web-auth/webauthn-lib v2.1.7 requires spomky-labs/cbor-php ^1.0.2 -> satisfiable by spomky-labs/cbor-php[v1.1.1].
    - web-auth/webauthn-lib is locked to version v2.1.7 and an update of this package was not requested.

@nikosdion Is there something you can say about the locked webauthn-lib?

@roland-d A few months ago I had said that I'd much prefer using a more recent version of the WebAuthn library. We can't use 4.x because it requires PHP 8.1 or later but we could use 3.3.12 which requires PHP 7.2 or later.

However, I was told that this would be a backwards compatibility break for Joomla. Do note that version 3 of the WebAuthn library is not fully backwards compatible with version 2. The bits we are using (credentials repository and server, the two bits which are the intended public interface) have not changed. The internal classes which are used to extend the functionality have, however, changed. This necessitated me back-porting parts of v3 of the library in a previous PR.

Back in 2013, seeing that Joomla moves to using more and more third party dependencies, I had warned that we may reach a point where dependencies dictate the PHP versions we can support. I was told I am against progress. Apparently I am the only one doing risk analysis. But I digress.

As we can see nearly ten years later, this will become a critical point as new versions of PHP are coming out with a LOT of fundamental changes (I have a feeling that 9.0 will be a seismic event) and Joomla uses a lot of third party dependencies. The way I see it there are four ways forward, three in line with the current b/c promise and one more pragmatic but not pure semantic versioning:

1. We stop using third party dependencies (NIH syndrome like we had not seen since 2012). Pros: we have full control of the range of PHP versions we can support. Cons: we have to maintain everything ourselves.
2. Joomla forks all third party dependencies and maintains them for the lifetime of a major release, completely negating the whole point of using third party dependencies. Pros: we have full control of the range of PHP versions we can support. Cons: we claim to be using a certain version of a dependency but we are actually not (it's a fork); we have to maintain PHP version compatibility for every dependency (less painful with Rector but still a hurdle); we can never run composer update, we always need to do it for a specific package, note down everything changed and redo the work to extend its compatibility.
3. Joomla does not support new versions of PHP after release of a major version. New PHP versions are only added in new releases and we need one new major release every year. The PHP versions to be supported are dictated far and foremost by third party dependencies. Pros: we can use third party dependencies without any issues; composer update just works. Cons: Too frequent major versions; lag between a new PHP version coming out and Joomla supporting it as we need to make sure all dependencies work; unpredictable release schedule; possibility of no upgrade path if there is no PHP version overlap between major Joomla versions.
4. Joomla's b/c does not extend to the minimum PHP version or third party dependencies included with the project. In this case every year the minor release coming after December (when PHP releases a new version) could drop the PHP versions no longer supported by the PHP project and update third party dependencies to new versions which oh-so-happen to also support the new PHP version coming out. It's basically the third option without bumping the major version every year.

Options 1 to 3 are unrealistic. Option 1: we don't have the necessary knowledge or capacity. Option 2: we don't have the capacity. Option 3: if you have a new major version each year you lose market share because the average site renewal cycle is 3 to 5 years. You'd have to provide bug and security fixes for the past 3 major versions (and expect 3PDs to support all of these versions!) for that plan to work; it is obviously unworkable due to lack of resources in the project AND 3PDs. Option 4 is not real semantic versioning but at least it's a more pragmatic approach.

Another option is to have private namespaces for every dependency but having tried doing that I can tell you it's NOT trivial, even with a tool like Rector. It also brings us back to the same b/c problem we started with: if a core plugin has a private vendor directory with its own dependencies, is it a b/c change updating these in the middle of a major Joomla version or not? If it is, we did a lot of work for no reason. If it's not, why not update the main dependency in the CMS' composer.json without going through a lot of pain to namespace the whole lot?

So, what can you tell me about the locked webauthn-lib? I have said all of that before. Ultimately, the decision is not mine. If you want to upgrade to v3 I can update my open PR for WebAuthn to make sure that it works right with the v3 library.

@nikosdion Thank you for your detailed answer. I have to see what can be done here and will get back to you if I want you to update the WebAuthn.

This pull requests has been automatically converted to the PSR-12 coding standard.

@nikosdion Did not forget about this but holiday/sick/such fun things got in the way. However I did talk about it and the solution is to fork brick/math. Now I have no time or desire to do this.

So for now, there is nothing to change here. The new versions will come with Joomla 5. Thank you for the elaborate feedback.