Fixes#1712
Disclosure: Coded with help of Copiot. (description wrtten by me)
So this does indeed loosen the encoding a bit. However, IMHO, it was neither better before though. You could always bypass the encoding for `args{0]` when you just include `<a` (or the other tag) somewhere or so.
**One important notice:** This was (due to the exceptions before and afterwards) valid before and also now: Translators **could** (and can) if they have malicious intent, inject/do "XSS attacks".
Thus, translations PRs (also from Crowdin) should be reviewed for wild HTML code inside translations. I suppose this is easy to fix, but anyway a valid risk.
But IMHO, we should teat the JSON files being part of our source code as a "trusted source". In the end, such an attak is basicaly just ends up being injecting malicious code. I hope such contributors would be detected.
References I explicitly checked again to not introduce an XSS here: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html and the PHP doc for he HTML encoding.
I feel the safter way obviously would be encoding the _whole_ string _after_ translation (just like you should apply DOMPurify after everything), but as explained it was not done before and would break compatibility. Also, I looked through the sources and I see no risk described by doing it only for the "dangerous" "untrusted" inputs.
Only here is a notice that `%s` shall not be used in some contexts, for example to define a tag: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html#dangerous-contexts (obviously in such a case, attacks may be possible even with encoding; but again; this is nothing new)
The basic "problem" of it all is: We want HTML to be translated/be usable in our translation. If we'd get rid of that, we would get for sure rid of all such XSS attack possibilities. But that woud be a bigger refactoring, so IMHO, this here is fine for a fix for the issue at hand.
Ah another point: I think the `is_int` check is harmless, but it's also kinda useless. Maybe it is some kind of obscure performance optimisation. (Yeah ints have nothing to encode as they have nothing that could be used for XSS, but they could also just be passed through that function.)
- symfony/polyfill-php80 installed to introduce the polyfill and support php7.3 using php8 functions
- symfony/polyfill-ctype installed to introduce ctype functions in case somebody doesn't have the ctype extension installed
- fixes QR code height introducing space even when hidden in page layout
- fix modals in bootstrap 5 (modal syntax changed heavily, no longer jQuery integrated)
- hide and show tab-toggle depending on application state
- don't encode HTML entities in translated messages containing kbd tags (in addition to links)
- @version in file header level isn't used on code docs, it is intended
for API versions at class or method level
- avoids needing to update all these files on version increment
- avoids needing to regenerate SRI hashes for privatebin.js through
extra phpunit run
- simplifies VERSION_FILES list
- avoids having to filter above list during loop
- adds a few missing doc bloc headers
- Crowdin has to use the 3 letter language code, since Lojban has no 2 letter code. Added support for this in the PHP backend and renamed the translation file.
- Lojban has no plural cases, updated the plural-formulas accordingly.
- Credited the change and documented it.
- Updated the SRI hashes.
