GNOME Bugzilla – Bug 659233
Cannot connect and sync my google calendar because connection is not terminated properly.
Last modified: 2012-03-18 19:17:02 UTC
Hello. It is kinda related to this invalid bug : https://bugzilla.gnome.org/show_bug.cgi?id=659178 I reported the bug on gnutls bugtracker. http://savannah.gnu.org/support/?107802 After using wireshark in order to see what happened, gnutls coder says it is related to a connection terminated not in a properly way. http://savannah.gnu.org/support/?107802#comment7 "Indeed the server terminated the connection non-properly and this is what gnutls is reporting. This is reported via the GNUTLS_E_PREMATURE_TERMINATION error code (in gnutls 2.x the generic GNUTLS_E_UNEXPECTED_PACKET_LENGTH was used).Maybe you could report this to the evolution developers to report the error only without invalidating the already received data. I know that other libraries just ignore this error, but note that if you ignore it you'll never notice an attack that truncates the data sent by the server. From gnutls side there is not much we can do." I got advice to report it to evolution coders in order to see if they can do something on their side.
Thanks for a bug report. I know this is like moving hot potato between peers, but evolution-data-server's CalDAV calendar backend is using libsoup, thus any workaround for the gnutls change would be done either there, or even in glib-networking. I do not know libsoup that well to be able to tell for sure. Anyway, when I tried to "ignore" the SOUP_STATUS_SSL_FAILED code, then it has no difference, except of different error message, which is afterwards "Permission denied", which only because the libsoup didn't return received body/headers and dropped everything. Thus there is no workaround for higher level applications, the change, if any, should be done lower in the stack.
Created attachment 196741 [details] [review] gnutls: fix G_TLS_ERROR_EOF handling with gnutls 3.0 gnutls 3.0 has a new error code for "peer closed connection without sending a Close packet", so add some #ifdefs to do the right thing with either 2.x or 3.x. ==== can you try this patch against the glib-networking package and see if it fixes the problem?
Applied patch, and rebuild both glib-networking and libsoup... Works perflectly ! Thanks for the quick fix !
Attachment 196741 [details] pushed as 9e2aaac - gnutls: fix G_TLS_ERROR_EOF handling with gnutls 3.0
I'm a bit confused about the version of gnutls for "RESOLVED" How can I tell if this has been fixed for the current Ubnutu 12.02 B1? My packages are below. Is the "26/xx27" = 2.26/27.x? .. This is being suggested as a root cause for https://bugzilla.gnome.org/show_bug.cgi?id=659522#c8 I just want to confirm this patch appears in the following downstream packages since it goes back a while now. ii libgnutls-dev 2.12.14-5ubuntu2 GNU TLS library - development files ii libgnutls-openssl27 2.12.14-5ubuntu2 GNU TLS library - OpenSSL wrapper ii libgnutls26 2.12.14-5ubuntu2 GNU TLS library - runtime library ii libgnutls26:i386 2.12.14-5ubuntu2 GNU TLS library - runtime library ii libgnutlsxx27 2.12.14-5ubuntu2 GNU TLS library - C++ runtime library
This bug only affected gnutls 3.0. If you have a 2.x version of gnutls then your bug is something else.