Dunedan

I didn't question this use case, but there are other cases where old hardware is being used with modern kernels. Also for the case of using old hardware with old kernels, it doesn't matter if drivers get removed from the current Linux kernel.

Generally people using the word generally don't know what they're talking about.

It's even more hilarious, as we're talking about drivers, which are apparently not used by anybody anymore.

You should be able to review translations now.

Right now we don't care if strings are approved or not, we take whatever we can get (we obviously filter for vandalism though). The best way would be to get in touch with one of the language coordinators (https://app.transifex.com/wildfire-games/teams/17418/tr/). If they aren't responsive, let me know and we'll find another way.

Updates to the translations get integrated whenever a new version of 0ad gets released. Once we start the release process, we'll publish multiple release candidates, translators like you can use to check if the translations look fine in the game and give you the chance to polish the translations. The start of the release process will be announced via a notification on Transifex, as well as in the "Announcements / News" subforum here. If you're eager to try out the translation before, you can either compile the current development state of the game yourself or, if you're using Windows, use the nightly build: https://gitea.wildfiregames.com/0ad/0ad/wiki/NightlyBuild

These changes are now deployed and I'm hopeful this problem is now fixed. I've closed the associated issues in Gitea. If somebody is still encountering this problem, please don't refrain from re-opening the issues or comment here.

As we know thanks to the debugging work of @Shad_ and others that the problem seems to be related to client certificates, I dug into it a bit deeper. While I have no Windows available, I couldn't figure out the root cause, but I'm confident I found a workaround to get rid of the problem server-side without players having to do anything. As I mentioned, it isn't possible to disable requesting client certificates in ejabberd right now. After a discussion with the ejabberd devs (https://github.com/processone/ejabberd/discussions/4593), this will be added to the next version of ejabberd though (https://github.com/processone/ejabberd/commit/5b03ca51e003bae785d186f183c0cd276fc89e97), so once we update to that version at some point in the future, we should be fine. Until then, the workaround I have is to instruct the clients to only send us certificates signed by a specific CA. That CA is a dummy CA we have created and where clients haven't signed certificates from, which should result in clients not sending certificates at all. I have prepared all changes necessary for that (https://github.com/0ad/lobby-infrastructure/pull/43) and will likely deploy them in the upcoming days. It would be awesome if we'd have somebody who is currently affected by this problem or can reproduce it, so we can test if the changes indeed fix it.

Yes, the client can only send a "Certificate Verify" if it has a client certificate available. So this just indicates whether a client certificate is available or not and isn't directly related to the problem. When using "openssl client" with a client certificate "Certificate Verify" is included as well and the connection succeeds without issues Thanks for checking anyway. Much appreciated.

That theory turned out to be wrong, as I was able to confirm with "openssl client" that providing a self-signed and therefore invalid certificate to the lobby server works just fine. ejabberd in our configuration does just ignore any client certificate provided. Disabling requesting client certificates would be a workaround, but doesn't appear to be possible with ejabberd. Seems like SChannel is doing something weird, as my understanding is that the client code terminates the connection after the TLS connection got established, not ejabberd. The best way forward is probably somebody debugging this who's running Windows.

For reference: https://gitea.wildfiregames.com/0ad/0ad/issues/5396 I believe it's likely that this is caused by the same underlying problem.

That's quite helpful. Here is my current theory what's happening: While we don't use mTLS, there is support for that in ejabberd (the XMPP server we're using for the multiplayer lobby). Part of that is instructing the client (0ad) to optionally send a client certificate if it has one available (SSL_VERIFY_PEER option for SSL_CTX_set_verify of OpenSSL). For most Windows users that's not the case, as they never used client certificates. However, for users which have client certificates installed, SChannel (the TLS-library used by 0ad under Windows) picks an invalid certificate and sends it to the server under certain circumstances. As it's invalid the connection gets terminated, resulting in errors when trying to connect to the lobby. As sending a client certificate to the server is optional and not used by us, that should be an avoidable problem. @Shad_: Could you do me a favor and figure out what's considered a valid client certificate by SChannel in this case? Is it just any client certificate or does it have to have certain properties (like being issued by Let's Encrypt for example). That would help us to find a way to work around the issue in 0ad or the lobby server so users don't have to manually take action.

https://gitea.wildfiregames.com/0ad/0ad/issues/8847

This issue is now tracked in https://gitea.wildfiregames.com/0ad/0ad/issues/8987

This issue is now tracked in https://gitea.wildfiregames.com/0ad/0ad/issues/8987