Use new ddnet.org domain

[def-]

I prefer the new ddnet.org domain, looks cleaner, makes it clear this is not a Taiwanese project. (The .tw = Teeworlds connection was cute, but we might have outgrown it.) Missing: wiki.ddnet.org @edg-l We are still using netobj.ddnet.tw and @ddnet.tw for teehistorian The sites currently redirect temporarily to ddnet.tw equivalents. Next step will be to switch that around so that ddnet.org are official and ddnet.tw permanently redirect to ddnet.tw. This should coincide with the release of this version to keep latency low for most users.

Checklist

• [x] Tested the change ingame
• [ ] Provided screenshots if it is a visual change
• [ ] Tested in combination with possibly related configuration options
• [ ] Written a unit test if it works standalone, system.c especially
• [ ] Considered possible null pointers and out of bounds array indexing
• [ ] Changed no physics that affect existing maps
• [ ] Tested the change with ASan+UBSan or valgrind's memcheck (optional)

[heinrich5991]

https://codedoc.ddnet.org/ also doesn't work yet.

[def-]

https://codedoc.ddnet.org/ also doesn't work yet.

Works for me.

[def-]

@heinrich5991 The POST for https://master1.ddnet.org/ddnet/15/register is not working with a 307 redirect I guess. But somehow only fails on macOS in CI, locally I don't get it: https://github.com/ddnet/ddnet/runs/6710320067?check_suite_focus=true

[2022-06-02 14:44:28][register/6/ipv6]: registering...
[2022-06-02 14:44:28][register/6/ipv4]: registering...
[2022-06-02 14:44:28][register/7/ipv6]: registering...
[2022-06-02 14:44:28][register/7/ipv4]: registering...

Really weird, why is it just hanging and no response from curl?

Maybe this is a cloudflare problem, I can try changing the settings there. But I guess server should still not hang in this case. I would expect https://github.com/ddnet/ddnet/pull/5271 to fix this, but seems like not

[C0D3D3V]

xD on the macOS build it outputs for more then 1:30h:

[2022-06-02 19:38:18][sql]: Waiting for score threads to complete (5240s)
[2022-06-02 19:38:21][sql]: Waiting for score threads to complete (5242s)
[2022-06-02 19:38:24][sql]: Waiting for score threads to complete (5244s)
[2022-06-02 19:38:27][sql]: Waiting for score threads to complete (5246s)
[2022-06-02 19:38:29][sql]: Waiting for score threads to complete (5248s)
[2022-06-02 19:38:32][sql]: Waiting for score threads to complete (5250s)
[2022-06-02 19:38:35][sql]: Waiting for score threads to complete (5252s)
[2022-06-02 19:38:38][sql]: Waiting for score threads to complete (5254s)
[2022-06-02 19:38:41][sql]: Waiting for score threads to complete (5256s)
[2022-06-02 19:38:44][sql]: Waiting for score threads to complete (5258s)
[2022-06-02 19:38:47][sql]: Waiting for score threads to complete (5260s)
[2022-06-02 19:38:50][sql]: Waiting for score threads to complete (5262s)
[2022-06-02 19:38:53][sql]: Waiting for score threads to complete (5264s)
[2022-06-02 19:38:56][sql]: Waiting for score threads to complete (5266s)
[2022-06-02 19:38:59][sql]: Waiting for score threads to complete (5268s)
[2022-06-02 19:39:02][sql]: Waiting for score threads to complete (5270s)
[2022-06-02 19:39:05][sql]: Waiting for score threads to complete (5272s)
[2022-06-02 19:39:07][sql]: Waiting for score threads to complete (5274s)
[2022-06-02 19:39:10][sql]: Waiting for score threads to complete (5276s)
[2022-06-02 19:39:13][sql]: Waiting for score threads to complete (5278s)
[2022-06-02 19:39:16][sql]: Waiting for score threads to complete (5280s)
[2022-06-02 19:39:19][sql]: Waiting for score threads to complete (5282s)
[2022-06-02 19:39:22][sql]: Waiting for score threads to complete (5284s)

I do not think this is related to this change... but I just wanted to note it.
We could cancel the workflow... It does not really do something productive

[def-]

I think it is, as I wrote before.

[heinrich5991]

I get

Error 526 Ray ID: 715461013e2c7278 • 2022-06-03 00:40:42 UTC Invalid SSL certificate

from https://codedoc.ddnet.org/.

[heinrich5991]

The POST for https://master1.ddnet.org/ddnet/15/register is not working with a 307 redirec

Perhaps the curl version on macOS is so old it doesn't know 307?

[def-]

I get

Error 526 Ray ID: 715461013e2c7278 • 2022-06-03 00:40:42 UTC Invalid SSL certificate

from https://codedoc.ddnet.org/.

Ok, get it too after a hard refresh. @edg-l Can you fix it too?

[def-]

I'll try without redirecting master1.ddnet.org. Edit: Doesn't seem to help, still the same problem.

[edg-l]

Missing: wiki.ddnet.org

ill try to do this today at night

[edg-l]

https://codedoc.ddnet.org/ now works and https://codedoc.ddnet.tw redirects to https://codedoc.ddnet.org/

[def-]

Ok. Now all done except the macOS master1 issue, which is a mystery to me.

[edg-l]

https://wiki.ddnet.org works too

[def-]

I'm really stumped here with why macOS CI fails to contact master1.ddnet.org but works on master1.ddnet.tw. I can't reprocduce it locally, different curl versions make no difference. Anyone got an idea?

[heinrich5991]

ddnet.org:

$ curl -d'{}' -H 'Address: tw-0.6+udp://connecting-address.invalid:8303' -H 'Secret: abc' -H 'Challenge-Secret: abc' -H 'Info-Serial: 1' -H 'Content-Type: application/json' -i https://master1.ddnet.org/ddnet/15/register
HTTP/2 200 
date: Wed, 27 Jul 2022 11:01:59 GMT
content-type: application/json
content-length: 28
strict-transport-security: max-age=15768000
cf-cache-status: DYNAMIC
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=7aXK9xqFphNELRMuVaq10yBx1qV4f65rkcrjX3e%2FxaHELsHO2ulPk92o4qFBbk5fovVo2ORQAIfxGvXsew7OyGNpaPqTgIqznpQ2leR%2BSn1cB4C%2Bg3lHqAXnwpFa1zjunsFYngDvSFaam74kzqQ2vA%3D%3D"}],"group":"cf-nel","max_age":604800}
nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
server: cloudflare
cf-ray: 7314e1581b757266-HAM
alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400

{"status":"need_challenge"}

ddnet.tw:

$ curl -d'{}' -H 'Address: tw-0.6+udp://connecting-address.invalid:8303' -H 'Secret: abc' -H 'Challenge-Secret: abc' -H 'Info-Serial: 1' -H 'Content-Type: application/json' -i https://master1.ddnet.tw/ddnet/15/register
HTTP/2 200 
date: Wed, 27 Jul 2022 11:01:54 GMT
content-type: application/json
content-length: 28
strict-transport-security: max-age=15768000
cf-cache-status: DYNAMIC
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 7314e137bdd9ac9e-TXL
alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400

{"status":"need_challenge"}

The only difference I see is the report-to and the nel headers which look irrelevant.

[heinrich5991]

Ah, maybe the TLS certificates: SSL Labs report for master1.ddnet.tw vs SSL Labs report for master1.ddnet.org

master1.ddnet.tw has a SHA256withRSA certificate, and master1.ddnet.org has a SHA256withECDSA certificate. OpenSSL 0.9.8y goes from RSA 2048 (SHA256), TLS 1.0, TLS_RSA_WITH_AES_128_CBC_SHA to Server sent fatal alert: handshake_failure.

So probably macOS CI has OpenSSL 0.9.8y?

[def-]

We don't even use OpenSSL on macOS, but the native secure-transport. Edit: Found a related-looking bug: https://github.com/curl/curl/issues/4524 I'll try sudo defaults write /Library/Preferences/com.apple.networkd tcp_connect_enable_tls13 1 in CI. But I don't think we can ensure people are using that on their macOS systems.

I guess we should use libressl:

in the most recent macOS versions, Apple ships curl built against libressl... Secure Transport is a thing of the past.

There would be further issues using libressl/openssl: https://github.com/alexcrichton/curl-rust/issues/310

Could we delay the TLS 1.3 upgrade or is it enforced by Let's Encrypt? Network.framework is not yet supported by curl, which would fix those issues.

[heinrich5991]

We don't even use OpenSSL on macOS, but the native secure-transport.

Then it might be the native secure-transport which doesn't support SHA256withECDSA certificates.

This doesn't seem to have anything to do with TLS 1.3 as the SSL Labs report indicates that one can connect to both master1.ddnet.tw and master1.ddnet.org with TLS 1.2.

Could we delay the TLS 1.3 upgrade or is it enforced by Let's Encrypt? Network.framework is not yet supported by curl, which would fix those issues.

We don't control the server side, it's Cloudflare's servers that strip the TLS and re-add it to reverse-proxy to our servers,

[def-]

I don't see a way in cloudflare to change this setting. For ddnet.tw we have ecdsa+rsa, for ddnet.org only ecdsa

[def-]

@Zwelf Any idea why the mac CI is not getting to [2022-08-25 14:15:55][sql]: load best time done on read database 0? Is it an issue with the sqlite version used?

2022-08-25 11:58:08][datafile]: loading data index=4 size=43 uncompressed=35
[2022-08-25 11:58:08][git-revision]: 8e088325506ef13d
[2022-08-25 11:58:08][server]: version 16.3.1 on macos amd64
[2022-08-25 11:58:08][server]: git revision hash: 8e088325506ef13d
[2022-08-25 11:58:08][server]: +-------------------------+
[2022-08-25 11:58:08][server]: | rcon password: 'PdBmWX' |
[2022-08-25 11:58:08][server]: +-------------------------+
[2022-08-25 11:58:11][sql]: Waiting for score threads to complete (2s)
[2022-08-25 11:58:15][sql]: Waiting for score threads to complete (4s)
[2022-08-25 11:58:18][sql]: Waiting for score threads to complete (6s)
[2022-08-25 11:58:22][sql]: Waiting for score threads to complete (8s)

etc. While locally I get:

[2022-08-25 14:15:55][datafile]: loading data index=4 size=43 uncompressed=35
[2022-08-25 14:15:55][sql]: load best time done on read database 0
[2022-08-25 14:15:55][git-revision]: 007dbd64a593e5ca
[2022-08-25 14:15:55][server]: version 16.3.1 on macos arm64
[2022-08-25 14:15:55][server]: git revision hash: 007dbd64a593e5ca
[2022-08-25 14:15:55][server]: +-------------------------+
[2022-08-25 14:15:55][server]: | rcon password: 'a4oBb7' |
[2022-08-25 14:15:55][server]: +-------------------------+

[Zwelf]

I don't know. Maybe it is because of the different sqlite version. What about not switching to -DPREFER_BUNDLED_LIBS=ON in this PR to get it landed faster (if it is caused by that, I don't see anything else in the changeset that could have caused this)?

[def-]

Still the same. It's a mystery to me too.

[def-]

Maybe it's the weird semaphore on macos

[def-]

Argh, I think it's been the semaphore all along and we never checked for errors. PSEMNAMELEN limits semaphores to 31 characters, sem_open returns a failure code and we wait on the failure code instead of handling it as an error. By changing the semaphore name from ddnet.tw to ddnet.org it got too long.

Confirmed locally. Will provide proper error handling for semaphores...

Ready for review.

[def-]

This is probably the most embarrassing bug I've added yet. And taking 3 months to find it...

[def-]

Ready for review

[edg-l]

bors r+

[bors[bot]]

Build succeeded:

• build-cmake (macOS-latest)
• build-cmake (ubuntu-20.04)
• build-cmake (ubuntu-latest)
• build-cmake (windows-latest)
• check-clang-san
• check-clang-tidy
• check-style

[13z]

good