Can anyone show me an example of a real attack vector that you are trying to fix with these patches? I know all the insides of the ini parser in PHP (and even contributed to it), I know the insides of Joomla of course. But I absolutely don't see how the ini files can be manipulated from the outside. Overriding ini files is limited to admins only. As for third-party extensions, just like using constants in ini files, they can simply print any constant or environment variable. Are you going to handle every php file in a similar way???

And as a result of this "fix" we have a big performance hit.

So, what are you still struggling with? You can answer me in Mattermost (@denis-ryabov).

This patch is not attempting to fix any attack vector.

An attack vector (real or imagained) was addressed in J4.1.1.
There were a few instances where safe .ini language files which previously worked now failed in J4.1.1
#42416

I produced a PR to address this which was rejected because of the performance raminifications. Later, after looking at further changes made in J5 I rewrote it without any performance impact (except in those few instances which failed anyway in J4.1.1).

I thought since you're trying to fix it, you'd understand the exact reason for @bembelimen's patch (609cafc), and the problem is that I don't, and it looks like you're trying to fix the problem that shouldn't exist.

The problem did not exist until J4.1.1

The security fix in J4.1.1 meant that some previously working language .ini files no longer worked.

Without arguing about whether the security issue is real or imagined (in the language translation scenario) and reversing the change the quickest solution is to cater for those failing .ini files without impacting performance with the others... unless you argue that finding all the problematic .ini files (plus months of more come to light as people upgrade to J4.1.1+) is the correct solution - but then those problem .ini files I've encountered have been working for years without a problem.

I will leave it to the JSST to respond specifically about the security issue but the explanation of why to use parse_ini_raw is well documented

No point waiting for JSST to respond, I am happy with what has been done for J5.0
My changes are based upon J5.0 as it is cleaner error handling.

@BrainforgeUK thanks for the PR - could you fix the phpcs error?

Anything else I need to do here?
This branch is out-of-date with the base branch
Do I have to do the Update branch with 4.4-dev? Joomla 5?

Anything else I need to do here? This branch is out-of-date with the base branch Do I have to do the Update branch with 4.4-dev? Joomla 5?

I did the Update branch (comes up if the current branch - 4.4- is updated with other PR's) - but there are still phpcs errors...

Thanks.
However, I cannot see what the phpcs error is referring to.
https://ci.joomla.org/joomla/joomla-cms/72531/1/8

Hello @BrainforgeUK we, the maintainer team decided, that the solution is not the way we want to go.

Thank you very much for your contribution, we really appreciate your work and hope, this does not discourage you and we're looking forward to further ideas from you.

Thanks, my concern is when will embedded newline capability be restored to .ini language files?
My solution would have at least provided a temporary resolution until a more acceptable longer term solution (and I assume pre v4.4.1 backward compatible)) implemented.
Starting work today on a new component and encountered how inconvenient this is going to be.
Wordwrap in the IDE partly helps but is not a long-term solution.