I recently upgraded my gabble installation (gentoo, keruspe overlay) from0.9.something to 0.9.15 and it stopped working. I get a constant network error. Debug says it is an tls error. I am attaching the debug log. I now went back to 0.8.14 and it is working again. Unfortunately, I couldn't find any of the 0.9 older releases so back to 0.8 series.
Created attachment 37529 [details] debug log
> (telepathy-gabble:28272): gabble-DEBUG: connector_error_disconnect: connection failed: TLS Handshake Error: -59: GNUTLS_E_INTERNAL_ERROR We've seen similar failure modes in Debian, which seem to be caused by gnutls >= 2.9; at the moment it's unclear whether Gabble or gnutls is at fault. Downgrading gnutls to 2.8 works around this.
Code will need some changes to support gnutls > 2.9, adopting this bug.
*** Bug 29219 has been marked as a duplicate of this bug. ***
Spent some time poking this with a stick, the original thing I thought was wrong was in fact wrong, but there appear to be other issues too. Interestingly, the example connector program succeeds in raw mode but fails when using the connector, so that's one place to start looking. In other news, the server side of things, which we use only for the tests, also appears to be broken, but I think that's an easier fix (looks like a change to the priority string as the test certs are no longer covered by the SECURE settings, only the NORMAL ones)
*** Bug 29698 has been marked as a duplicate of this bug. ***
Sjoerd tracked this down to bugs in the latest gnutls releases: http://lists.gnu.org/archive/html/gnutls-devel/2010-08/msg00019.html
Upstream commited the changes but only on the master branch. Could you poke them to also fix the gnutls_2_10_x branch? Backporting is non-trivial as the code differs quite a bit.
I updated gabble to 0.9.18 and now I can not connect to gtalk. From the debug, it seems this is again a problem with tls. The previous versions were ok with gnutls 2.8 series but now, I am having problems with that too. This time I do not get an error but tries to connect without success and any apparent error messages... Debug attached
Created attachment 38738 [details] gabble log
(In reply to comment #9) > The previous versions were ok with gnutls 2.8 series but now, I am having > problems with that too. This isn't the same bug, so I've cloned it as Bug #30226. If you encounter any other TLS bugs that don't match the symptoms above (failure with GNUTLS_E_INTERNAL_ERROR) or that can be reproduced with GNUTLS 2.8, please report them separately. Strictly speaking, this one is RESOLVED NOTOURBUG, but I'll keep it open to track the gnutls situation until we have some sort of resolution for it. Current status: * GNUTLS 2.8.x works, in general * GNUTLS 2.10.x and early 2.11.x contain regressions which break Wocky/Gabble * GNUTLS 2.11.1 (unstable development release) contains some patches from Sjoerd which make Wocky/Gabble work again: 98e0e3c400, 2a539ad96 and 18cff3602 * Those patches have not yet been backported to the 2.10.x stable branch; they don't backport trivially, since surrounding code has changed in 2.11
Created attachment 38905 [details] gnutls patch to address async handshake regression This should fix the problem (makes the tests pass with 2.10.x and allows the connector example to work, at any rate) I am also sending this to the gnutls list: If you feel like trying it and letting us know if it works, that would be useful too.
(In reply to comment #12) > I am also sending this to the gnutls list: If you feel like trying > it and letting us know if it works, that would be useful too. Please also coordinate with <https://bugzilla.redhat.com/show_bug.cgi?id=629858>, where the Red Hat maintainer has tried backporting one of Sjoerd's three patches, but that's apparently not enough.
fc seem to have their own fix, haven't tested it myself - upstream have put a fix based on this patch into the 2.10.x branch, so I guess we'll see it in 2.10.2
gnutls 2.10.2 has been released, which fixes this issue. Do we need to do anything else like adding (runtime?) checks for 2.10.1, or should we close this bug?
(In reply to comment #15) > gnutls 2.10.2 has been released, which fixes this issue. > > Do we need to do anything else like adding (runtime?) checks > for 2.10.1, or should we close this bug? No, I don't think we need to keep tracking this now that a fix exists. NOTOURBUG, and fixed in gnutls 2.10.2 and 2.11.1.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.