Re: [Evolution-hackers] evolution failing on TLSv1.3 after gnutls upgrade

[Milan Crha <mcrha redhat com>]

On Sun, 2019-05-12 at 11:04 -0700, James Bottomley via evolution-
hackers wrote:
> On Fri, 2019-05-10 at 23:23 +0200, Sasa Ostrouska via evolution-
> hackers 
> wrote:
> > Hi all, and thanks Milan for the program. I also run an old version
> > of evolution 3.20.x and I get the following:

        Hi,
the more important is glib/glib-networking/gnutls version, than
evolution(-data-server) version. Sometimes also the system crypto
policy setting (/etc/crypto-policies/config on Fedora), though it works
the other way, it disables the old algorithms and "forces" use of the
newer, which can break connection against legacy servers.

> > rc@rc-laptop:~/Downloads$ gcc `pkg-config --cflags --libs glib-2.0
> > gio-2.0` imap-conn.c -g -O0 -o imap-conn && ./imap-conn
> > imap.googlemail.com 993
> > Connected to imap.googlemail.com:993
> > Failed to read data from the server: Error reading data from TLS
> > socket: The specified session has been invalidated for some reason.

The error is returned from gio/glib-networking and I agree it's not
obvious what it is about. Maybe it means that the current code doesn't
have new-enough implementation of the TLS. It looks like that, at
least.

> > I neded to #include <string.h> on my slackware linux.
>
> Me too, but it was a trivial update.

Hrm, weird, it might be probably due to that strlen() usage. No idea
what pulled it in here, that it didn't claim any issue on my side. I'm
sorry about that.

> I think the solution is to simply bar glib-networking below 2.55.2
> from using gnutls VERS-TLS1.3 which looks like it can be done
> reasonably well in g_tls_connection_gnutls_init_priorities()

There are some issues with it: a) the function is a private function, I
didn't find it in any of the header files under /usr/include/; b) it's
a very specific function, there's a branch to support also openssl in
glib-networking, where this would do nothing; c) getting such change
into an old evolution-data-server or glib-networking might be tricky,
especially with Long Term Support distributions; d) as Sasa showed (if
I understand it correctly), limiting TLS version may lead to rejected
connections on otherwise working system (it's when the server increases
TLS version requirement, but the "proposed change" would limit what can
be used).

That said, when the server requires recent TLS version, the users need
to update their system to also support such TLS version. It makes sense
(once one knows where the problem is, which I wasn't sure at all at the
beginning). Thank you James for all the testing and finding that out.
It's good to know that glib has it fixed already.
        Bye,
        Milan