archlinux: pacman: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory

Upgrade only openssl to version 3 from 1.1.1 and you receive this error. sudo doesn’t work, pacman doesn’t work, what do you do?

Well hopefully you have not deleted previously downloaded packages from /var/cache/pacman/pkg/ .
If not, read about the Arch Linux Archive and you will need a USB drive/stick/whatever with an archiso written on it. I will not go there.

You however do have a previous version, for instance /var/cache/pacman/pkg/openssl-1.1.1.q-1-x86_64.pkg.tar.zst.
Since you can’t sudo, use su - to become root.

nginx: [emerg] unknown “tls1_3_early_data” variable

If you’re getting this error message doing nginx -t or otherwise,
for instance if you’re copy/pasting Mattermost’s nginx configuration,
know that the line is

instead of

I’m not sure but I’m guessing nginx developers renamed that variable, I’m just not sure when that happened. $tls1_3_early_data must have worked some time ago, but on my nginx version it doesn’t and I have to use the $ssl_early_data variable.

see also
nginx ssl early data
mattermost’s nginx configuration

Keycloak Client Passwords are insecure by default

And the maintainers refuse to change that, responding with bureaucratic measures and general ignorance.

When you have an UUID string, example “192c1916-de80-4003-a01b-b2eaf97a1721” first of all those aren’t 128 bits.
You have a representation of those 128 bits and a very limited set of characters 0123456789abcdef, so you represent those 128 bits in only 16 characters of 256 possible, effectively reducing the bit-“strength” to 128/(256/16)=8 bits. And of course you know how many characters 8 bits are, exactly 1.

So now you have 32 characters that can only have the state of [0-9a-f] each. How long does it take to brute force 32 characters with 16 possible values per character?

Keycloak client passwords are insecure by default and that maybe be because of laziness, which I first assumed, stupidity, which is quite common or by design.

Vue and Keycloak do not have a proper JS client that works with mobile native

There are currently 2 packages to integrate keycloak-js with your Vue 3 WEB app.

https://github.com/dsb-norge/vue-keycloak-js
and
https://github.com/baloise/vue-keycloak

But each have their quirks and issues.

If you want to use keycloak in a native app, none of these work.
There is keycloak-ionic and someone created a repo https://github.com/marchalb/qkeycloak to showcase a modified version of dsb-norge/vue-keycloak-js and keycloak-ionic, but that also isn’t working.

So the current state for OIDC client apps is: NOT FUNCTIONAL

OIDC fails the K.I.S.S. principle. It is so complicated that no one has managed to write something that works for every scenario.
Mobile and Web are some very common scenarios, why is there nothing that provides this functionality?

I think it’s better to abandon OIDC, since all that’s left are commercial offerings and the open source ones don’t work properly,
and write your own auth package, which may not be as sophisticated but at least it will work for you and your needs and you know what it’s doing.