Fedora 29 GnuTLS Crash on lobby login

[shookees]

Revision: 21931

System: Fedora 29

Steps to reproduce:

1. Launch built pyrogenesis executable for revision 21931
2. Go multiplayer
3. Game Lobby
4. Enter credentials (or they're already filled if used before)
5. Connect
6. Verify crash

Attached: gdb pyrogenesis trace (with suggested debug libraries installed)

[shookees]

GDB stack trace

[elexis]

The crash occurs in GnuTLS:

#1  0x00007ffff40bdacb in _gnutls_verify_crt_status (
#2  0x00007ffff40be1f1 in gnutls_x509_crt_verify (cert=<optimized out>, 
#3  0x00007ffff6c6fc60 in gloox::GnuTLSClient::verifyAgainstCAs (
#4  0x00007ffff6c6fe3e in gloox::GnuTLSClient::getCertInfo (this=0x46c1000)
#5  0x00007ffff6c723b5 in gloox::GnuTLSBase::handshake (this=0x46c1000)
#6  0x00007ffff6c72959 in gloox::GnuTLSBase::decrypt (this=0x46c1000, 
#7  0x00007ffff6c11706 in gloox::ConnectionTCPClient::recv (this=0x4850e80, 

Do you get it only sometimes or everytime? (Since I see you joining the lobby a lot recently)

An article pops up about them enabling TLS v1.3 in Fedora 29, so perhaps thats the culrpit: ​https://fedoraproject.org/wiki/Changes/GnuTLS-TLS1.3

[shookees]

Replying to elexis:

Do you get it only sometimes or everytime? (Since I see you joining the lobby a lot recently)

When testing with the latest SVN - everytime. I have checked with a second account whether I enter the lobby before the crash - it doesn't.

Replying to elexis:

An article pops up about them enabling TLS v1.3 in Fedora 29, so perhaps thats the culrpit: ​https://fedoraproject.org/wiki/Changes/GnuTLS-TLS1.3

Really have no clue what's lying underneath TLS, but wiki suggests, that TLS 1.3: <..> handshake is different from earlier versions[1]. So it might be a plethora of issues...

[1] - box at the top: ​https://en.wikipedia.org/wiki/Transport_Layer_Security

[shookees]

wireshark dump, use filter "ip.addr == 136.243.15.233 and not tcp.port in {80 25}"

[elexis]

shookees can you try if disabling the TLS option in the default.cfg or user.cfg changes the result?

lobby.require_tls = false
​https://trac.wildfiregames.com/browser/ps/trunk/binaries/data/config/default.cfg

Otherwise try changing this line in XmppClient.cpp would be changed from

m_client->setTls(require_tls ? gloox::TLSRequired : gloox::TLSOptional);

to

m_client->setTls(gloox::TLSDisabled);

[elexis]

In 21932:

Allow users to disable TLS encryption entirely in the GUI to ease use of the lobby if gloox/GnuTLS crashes upon TLS handshake, refs #5349, #4705.

Differential Revision: ​https://code.wildfiregames.com/D1679
Based on patch by: Itms
Tested on Fedora: Itms, bb and myself

[Itms]

This is going to require some detective work and collaboration with the developers of gloox. I hope it can be debunked soon, but it won't be immediate.

[rugk]

BTW, can totally reproduce this crash:

Also (with backtrace etc:) reported on:

• ​https://bugzilla.redhat.com/show_bug.cgi?id=1667682
• ​https://bugzilla.redhat.com/show_bug.cgi?id=1669448
• (stats) ​https://retrace.fedoraproject.org/faf/reports/2416172/
• (stats) ​https://retrace.fedoraproject.org/faf/reports/2424348/

[elexis]

There was a change to gloox::GnuTLSClient::verifyAgainstCAs in gloox 1.0.22, see #4705:comment:32 and ​https://bugs.camaya.net/ticket/?id=280, but I'm not sure if that changed anything.

One could test by building with a recent gloox version or debugging the code.

[historic_bruno]

Fixed by updating to gloox 1.0.22, I've reported it: ​https://bugzilla.redhat.com/show_bug.cgi?id=1732797

Works with both tls=true and verify_certificate=true.

Relevant upstream SVN revisions: r4647, r4758, r4818, and r4821

[Silier]

Replying to historic_bruno:

Fixed by updating to gloox 1.0.22, I've reported it: ​https://bugzilla.redhat.com/show_bug.cgi?id=1732797

Works with both tls=true and verify_certificate=true.

Relevant upstream SVN revisions: r4647, r4758, r4818, and r4821

Should we update gloox for win32 to 1.0.22 version too ? Can be this issue closed or is here something else need to be done?

[shookees]

The ticket can be updated to Fedora 31 as gloox is still not 1.0.22 (is 1.0.14), and thus the same crashing behaviour can be observed.

[Silier]

Replying to shookees:

The ticket can be updated to Fedora 31 as gloox is still not 1.0.22 (is 1.0.14), and thus the same crashing behaviour can be observed.

Cannot you update it to 1.0.22 manually ?

[bb]

Gloox got updated recently in the repo ​http://rpms.remirepo.net/rpmphp/zoom.php?rpm=gloox. Fedora 31 reports working.