Re: [Evolution-hackers] evolution failing on TLSv1.3 after gnutls upgrade
On Thu, 2019-05-09 at 08:37 -0700, James Bottomley via evolution- hackers wrote: > On OpenSUSE running evolution-3.26.6-lp150.2.6.x86_64, installing > > gnutls-3.6.7-lp150.9.1.x86_64 > > Lead to evolution failing on my dovecot imap server with > > Error reading data from TLS socket: The specified session has been > invalidated for some reason Hi, dealing with such requests is better either through the user list (evolution-list), or through bugzilla - see the "bugs" section of: https://wiki.gnome.org/Apps/Evolution/#Online_Support not talking that your Evolution it rather old, the current stable version is 3.32.2. Nonetheless, I do not expect that Evolution update would help, because Evolution doesn't use gnutls. It doesn't use it directly. Evolution relies on glib-networking and on whatever it uses, which is gnutls in this case. I guess those developers would appreciate any help, especially if the code is broken for them. If you wish, I can try to create some simple test program (a .c file), which would open a stream towards specified server and ask for capabilities or something, which can be done in an unauthenticated state, on which you can verify: a) it's really in glib-networking, b) whether more recent version of it will help. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution failing on TLSv1.3 after gnutls upgrade
On Thu, 2019-05-09 at 18:42 +0200, Milan Crha via evolution-hackers wrote: > On Thu, 2019-05-09 at 08:37 -0700, James Bottomley via evolution- > hackers wrote: > > On OpenSUSE running evolution-3.26.6-lp150.2.6.x86_64, installing > > > > gnutls-3.6.7-lp150.9.1.x86_64 > > > > Lead to evolution failing on my dovecot imap server with > > > > Error reading data from TLS socket: The specified session has been > > invalidated for some reason > > Hi, > dealing with such requests is better either through the user list > (evolution-list), or through bugzilla - see the "bugs" section of: > https://wiki.gnome.org/Apps/Evolution/#Online_Support > not talking that your Evolution it rather old, the current stable > version is 3.32.2. > > Nonetheless, I do not expect that Evolution update would help, > because Evolution doesn't use gnutls. It doesn't use it directly. > Evolution relies on glib-networking and on whatever it uses, which is > gnutls in this case. Ah, right, that's why I couldn't find the direct connection. > I guess those developers would appreciate any help, > especially if the code is broken for them. If you wish, I can try to > create some simple test program (a .c file), which would open a > stream towards specified server and ask for capabilities or > something, which can be done in an unauthenticated state, on which > you can verify: > a) it's really in glib-networking, b) whether more recent version of > it will help. I can certainly test things out. To be honest, I've had problems with TLSv1.3 every time it's been negotiated, so disabling it is a reasonable thing to do. I suppose there's no gntuls-cli equivalent for glib-networking? That would be the best way to test it. James ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution failing on TLSv1.3 after gnutls upgrade
On Thu, 2019-05-09 at 11:03 -0700, James Bottomley wrote:
> I can certainly test things out.
Hi,
that's great, thanks.
> To be honest, I've had problems with TLSv1.3 every time it's been
> negotiated, so disabling it is a reasonable thing to do.
I see. If you are still willing to help, then it'll be appreciated.
> I suppose there's no gntuls-cli equivalent for glib-networking? That
> would be the best way to test it.
I agree, but I'm not aware of anything like that (which doesn't mean it
doesn't exist). I made a little test program as promised, see the
attachment. The first line contains a comment with a command to compile
and run it (against Google's IMAP server). It's only a test program,
mimic-ing what Evolution (or better Camel library from evolution-data-
server) does. You may have installed development packages for glib and,
if split, also for glib's gio, to be able to compile it.
Bye,
Milan
P.S.: The result of the run as is in the file itself is below:
$ ./imap-conn imap.googlemail.com 993
Connected to imap.googlemail.com:993
Response: * OK Gimap ready for requests from {IPADDRESS} {SOMETOKEN}
Request: A01 CAPABILITY
Response: * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST
CHILDREN X-GM-EXT-1 XYZZY SASL-IR AUTH=XOAUTH2 AUTH=PLAIN
AUTH=PLAIN-CLIENTTOKEN AUTH=OAUTHBEARER AUTH=XOAUTH
A01 OK Thats all she wrote! {SOMETOKEN}
Request: A02 LOGOUT
Response: * BYE Logout Requested {SOMETOKEN}
A02 OK Quoth the raven, nevermore... {SOMETOKEN}
/* 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 */
#include
#include
static gboolean
read_stream_data (GIOStream *stream)
{
GInputStream *input;
gchar buffer[2048 + 1];
gsize count;
GError *error = NULL;
input = g_io_stream_get_input_stream (stream);
count = g_input_stream_read (input, buffer, G_N_ELEMENTS (buffer) - 1, NULL, &error);
if (count == -1) {
if (g_error_matches (error, G_IO_ERROR, G_IO_ERROR_TIMED_OUT)) {
g_clear_error (&error);
} else {
g_printerr ("Failed to read data from the server: %s\n", error ? error->message : "Unknown error");
g_clear_error (&error);
return FALSE;
}
} else {
buffer[count] = 0;
g_print ("Response: %s\n", buffer);
}
return TRUE;
}
static gboolean
issue_command (GIOStream *stream,
const gchar *command)
{
GOutputStream *output;
gsize count, written = 0;
GError *error = NULL;
output = g_io_stream_get_output_stream (stream);
count = strlen (command);
if (!g_output_stream_write_all (output, command, count, &written, NULL, &error)) {
g_printerr ("Failed to write command to the output stream: %s\n", error ? error->message : "Unknown error");
g_clear_error (&error);
return FALSE;
}
if (written != count) {
g_printerr ("Wrote only %d bytes, instead of %d\n", written, count);
return FALSE;
}
if (!g_output_stream_write_all (output, "\r\n", 2, &written, NULL, &error)) {
g_printerr ("Failed to write command end to the output stream: %s\n", error ? error->message : "Unknown error");
g_clear_error (&error);
return FALSE;
}
if (written != 2) {
g_printerr ("Wrote only %d bytes, instead of %d\n", written, 2);
return FALSE;
}
if (!g_output_stream_flush (output, NULL, &error)) {
g_printerr ("Failed to flush output stream\n", error ? error->message : "Unknown error");
g_clear_error (&error);
return FALSE;
}
g_print ("Request: %s\n", command);
return read_stream_data (stream);
}
static gint
run_connection (const gchar *host,
gushort port)
{
GSocketConnectable *connectable;
GSocketConnection *connection;
GSocketClient *client;
gint ret = 0;
GError *error = NULL;
connectable = g_object_new (G_TYPE_NETWORK_ADDRESS,
"scheme", "imap",
"hostname", host,
"port", port,
NULL);
client = g_socket_client_new ();
g_socket_client_set_timeout (client, 10);
g_socket_client_set_tls (client, TRUE);
connection = g_socket_client_connect (client, connectable, NULL, &error);
if (connection) {
GSocket *socket;
GIOStream *stream;
g_print ("Connected to %s:%d\n", host, port);
socket = g_socket_connection_get_socket (connection);
if (socket) {
g_socket_set_timeout (socket, 10);
g_socket_set_keepalive (socket, TRUE);
}
stream = G_IO_STREAM (connection);
if (!read_stream_data (stream))
ret = 3;
else if (!issue_command (stream, "A01 CAPABILITY"))
ret = 4;
else if (!issue_command (stream, "A02 LOGOUT"))
ret = 5;
if (!g_io_stream_close (stream, NULL, &error)) {
if (!ret)
ret = 6;
g_printerr ("Failed to close connection: %s\n", error ? error->message : "Unknown error");
g_clear_error (&error);
}
g_object_unref (connection);
} else {
g_printerr ("Failed to connect to %s:%d: %s\n", host, port, error ? error->message : "Unknown error");
g_clear_error (&error);
ret = 2;
}
g_object_unref (connectable);
g_object_unref (client);
}
gint
main (gint argc,
gchar *argv[]
Re: [Evolution-hackers] evolution failing on TLSv1.3 after gnutls upgrade
On Fri, 2019-05-10 at 08:41 +0200, Milan Crha via evolution-hackers
wrote:
> On Thu, 2019-05-09 at 11:03 -0700, James Bottomley wrote:
> > I can certainly test things out.
>
> Hi,
> that's great, thanks.
>
> > To be honest, I've had problems with TLSv1.3 every time it's been
> > negotiated, so disabling it is a reasonable thing to do.
>
> I see. If you are still willing to help, then it'll be appreciated.
>
> > I suppose there's no gntuls-cli equivalent for glib-
> > networking? That
> > would be the best way to test it.
>
> I agree, but I'm not aware of anything like that (which doesn't mean
> it
> doesn't exist). I made a little test program as promised, see the
> attachment. The first line contains a comment with a command to
> compile
> and run it (against Google's IMAP server). It's only a test program,
> mimic-ing what Evolution (or better Camel library from evolution-
> data-
> server) does. You may have installed development packages for glib
> and,
> if split, also for glib's gio, to be able to compile it.
>
> Bye,
> Milan
>
> P.S.: The result of the run as is in the file itself is below:
>
>
> $ ./imap-conn imap.googlemail.com 993
>
> Connected to imap.googlemail.com:993
> Response: * OK Gimap ready for requests from {IPADDRESS} {SOMETOKEN}
>
> Request: A01 CAPABILITY
> Response: * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID
> XLIST CHILDREN X-GM-EXT-1 XYZZY SASL-IR AUTH=XOAUTH2 AUTH=PLAIN
> AUTH=PLAIN-CLIENTTOKEN AUTH=OAUTHBEARER AUTH=XOAUTH
> A01 OK Thats all she wrote! {SOMETOKEN}
>
> Request: A02 LOGOUT
> Response: * BYE Logout Requested {SOMETOKEN}
> A02 OK Quoth the raven, nevermore... {SOMETOKEN}
So when I run it against my current setup (TLSv1.3 disabled) I get this
as expected:
jejb@jarvis:~> ./imap-conn bedivere.hansenpartnership.com 993
Connected to bedivere.hansenpartnership.com:993
Response: * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE
LITERAL+ AUTH=PLAIN] Dovecot (Debian) ready.
Request: A01 CAPABILITY
Response: * CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE
LITERAL+ AUTH=PLAIN
Request: A02 LOGOUT
Response: A01 OK Pre-login capabilities listed, post-login capabilities have
more.
But when I enable TLSv1.3 in dovecot on the server I get this:
jejb@jarvis:~> ./imap-conn bedivere.hansenpartnership.com 993
Connected to bedivere.hansenpartnership.com:993
Failed to read data from the server: Error reading data from TLS socket: The
specified session has been invalidated for some reason.
Which isn't particularly helpful, although it does prove the issue is
indeed in glib-networking. Is there further debugging I should turn
on?
James
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution failing on TLSv1.3 after gnutls upgrade
Hi all, and thanks Milan for the program. I also run an old version of
evolution 3.20.x and I get the following:
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.
I neded to #include on my slackware linux.
Rgds
Saxa
On Fri, May 10, 2019 at 5:07 PM James Bottomley via evolution-hackers
wrote:
>
> On Fri, 2019-05-10 at 08:41 +0200, Milan Crha via evolution-hackers
> wrote:
> > On Thu, 2019-05-09 at 11:03 -0700, James Bottomley wrote:
> > > I can certainly test things out.
> >
> > Hi,
> > that's great, thanks.
> >
> > > To be honest, I've had problems with TLSv1.3 every time it's been
> > > negotiated, so disabling it is a reasonable thing to do.
> >
> > I see. If you are still willing to help, then it'll be appreciated.
> >
> > > I suppose there's no gntuls-cli equivalent for glib-
> > > networking? That
> > > would be the best way to test it.
> >
> > I agree, but I'm not aware of anything like that (which doesn't mean
> > it
> > doesn't exist). I made a little test program as promised, see the
> > attachment. The first line contains a comment with a command to
> > compile
> > and run it (against Google's IMAP server). It's only a test program,
> > mimic-ing what Evolution (or better Camel library from evolution-
> > data-
> > server) does. You may have installed development packages for glib
> > and,
> > if split, also for glib's gio, to be able to compile it.
> >
> > Bye,
> > Milan
> >
> > P.S.: The result of the run as is in the file itself is below:
> >
> >
> > $ ./imap-conn imap.googlemail.com 993
> >
> > Connected to imap.googlemail.com:993
> > Response: * OK Gimap ready for requests from {IPADDRESS} {SOMETOKEN}
> >
> > Request: A01 CAPABILITY
> > Response: * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID
> > XLIST CHILDREN X-GM-EXT-1 XYZZY SASL-IR AUTH=XOAUTH2 AUTH=PLAIN
> > AUTH=PLAIN-CLIENTTOKEN AUTH=OAUTHBEARER AUTH=XOAUTH
> > A01 OK Thats all she wrote! {SOMETOKEN}
> >
> > Request: A02 LOGOUT
> > Response: * BYE Logout Requested {SOMETOKEN}
> > A02 OK Quoth the raven, nevermore... {SOMETOKEN}
>
> So when I run it against my current setup (TLSv1.3 disabled) I get this
> as expected:
>
> jejb@jarvis:~> ./imap-conn bedivere.hansenpartnership.com 993
> Connected to bedivere.hansenpartnership.com:993
> Response: * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE
> LITERAL+ AUTH=PLAIN] Dovecot (Debian) ready.
>
> Request: A01 CAPABILITY
> Response: * CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE
> LITERAL+ AUTH=PLAIN
>
> Request: A02 LOGOUT
> Response: A01 OK Pre-login capabilities listed, post-login capabilities have
> more.
>
> But when I enable TLSv1.3 in dovecot on the server I get this:
>
> jejb@jarvis:~> ./imap-conn bedivere.hansenpartnership.com 993
> Connected to bedivere.hansenpartnership.com:993
> Failed to read data from the server: Error reading data from TLS socket: The
> specified session has been invalidated for some reason.
>
> Which isn't particularly helpful, although it does prove the issue is
> indeed in glib-networking. Is there further debugging I should turn
> on?
>
> James
>
> ___
> evolution-hackers mailing list
> evolution-hackers@gnome.org
> To change your list options or unsubscribe, visit ...
> https://mail.gnome.org/mailman/listinfo/evolution-hackers
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution failing on TLSv1.3 after gnutls upgrade
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: > > 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. > > I neded to #include on my slackware linux. Me too, but it was a trivial update. I did a bit of build bisection. Most of the failing glib-networking packages are 2.54.1 and below. 2.55.2 is the first working version (2.55.1 doesn't build due to missing glib-pacrunner). So, clearly, whatever the TLSv1.3 bug was it was fixed in this version, but I can find neither a bugzilla nor a commit obviously identifying the problem. 2.54.1 was the last version that used autoconf, 2.55.2 uses meson, which probably explains why a few distributions are stuck on 2.54.1. 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() James ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution failing on TLSv1.3 after gnutls upgrade
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 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 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution failing on TLSv1.3 after gnutls upgrade
On Mon, 2019-05-13 at 09:17 +0200, Milan Crha via evolution-hackers wrote: > On Sun, 2019-05-12 at 11:04 -0700, James Bottomley via evolution- > hackers wrote: [...] > > 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). With glib-networking < 2.55.2 there seems to be no way of supporting TLSv1.3. All current TLSv1.3 systems also support at least 1.2 (the allegedly more secure ones may have turned off 1.0 and 1.1 for various reasons), so disabling only 1.3 seems like a useful solution. As for how to apply the fix (assuming we can find it), this is a hard one. Clearly the bug was always present, but the conditions that trip it remained untested until people started turning on TLSv1.3. I think the best way forward is to open bugs with the distros and see what they want to do: Either find and fix the bug or update to 2.55.2. > 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). Just to clarify, the server isn't requiring a particular version, it's offering a set of options and we're choosing TLSv1.3 which we then can't negotiate successfully, so the bug is client side but triggered both by the client going to a gnutls (or probably openssl but I can't test that) version that makes 1.3 possible and the server offering it as an option. > Thank you James for all the testing and finding that out. > It's good to know that glib has it fixed already. You're welcome ... I just wish I could identify the actual fix. James ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution failing on TLSv1.3 after gnutls upgrade
On Mon, 2019-05-13 at 07:59 -0700, James Bottomley wrote: > As for how to apply the fix (assuming we can find it), this is a hard > one. Clearly the bug was always present, but the conditions that > trip it remained untested until people started turning on TLSv1.3. > I think the best way forward is to open bugs with the distros and see > what they want to do: Either find and fix the bug or update to 2.55.2. Hi, I see. That would work until a new version of the TLS is released and implemented and advertised by the servers with clients which probably know about it (due to new enough gnutls being installed, right?), but its usage in glib-networking failing for whatever reason. > Just to clarify, the server isn't requiring a particular version, > it's offering a set of options and we're choosing TLSv1.3 which we > then can't negotiate successfully, so the bug is client side but > triggered both by the client going to a gnutls (or probably openssl > but I can't test that) version that makes 1.3 possible and the server > offering it as an option. Oh, you are right, I'm sorry for misinterpreting it. Maybe the glib-networking can be changed to try a lower version(s) (when allowed to), when the best it thinks it can use fails with this error (meaning if the server advertises TLS versions 1.2 and 1.3, the client can try with 1.3 and if it fails, then retry with 1.2). I'd expect such naive "solution" would work on the gnutls level transparently though. I do not know gnutls, nor glib-networking, thus this is really just a very naive idea. Consider filling a bug against glib-networking [1] and ask them whether they can do anything about it. You've a clear view what is going on in the background, thus you'd be able to explain the problem to them. Feel free to use the test program to your liking. By the way, the openssl implementation for glib-networking is very new, released as part of the 2.60.0, on March 11 [2]. Bye, Milan [1] https://gitlab.gnome.org/GNOME/glib-networking/issues/new [2] https://gitlab.gnome.org/GNOME/glib-networking/blob/2.60.0/NEWS#L1 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution failing on TLSv1.3 after gnutls upgrade
On Mon, 2019-05-13 at 18:00 +0200, Milan Crha via evolution-hacker > Consider filling a bug against glib-networking [1] and ask them > whether they can do anything about it. You've a clear view what is > going on in the background, thus you'd be able to explain the problem > to them. Feel free to use the test program to your liking. openSUSE triaged this to commit 0795cd14651c965659ccef33630872a53a7bc8ec Author: Olivier Crête Date: Fri Jul 3 12:43:45 2015 +0100 gnutls Add support for timeouts on GnuTLS pulls So if you apply that on top of 2.54.1, the test programme works again. I tried to file a bug but I can't seem to recover my account credentials for the new gitlab system. James ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution failing on TLSv1.3 after gnutls upgrade
On Wed, 2019-05-15 at 15:49 -0700, James Bottomley wrote: > gnutls Add support for timeouts on GnuTLS pulls > > So if you apply that on top of 2.54.1, the test programme works > again. Hi, do you see from the server logs whether the patched code tried TLS v1.3, and then v1.2? I'm only wondering. After re-reading the previous messages in this thread, you found that the development version 2.55.2 works fine. As it's a development version, the (usual) distributions may pick the stable version, 2.56.0 or later. Or they can find which patch fixed it between 2.55.1 and 2.55.2 and backport only that one (you referenced that change above). Thinking of it, maybe it's a nonsense to ask them about the TLS version downgrade on the fly. My "suggestion" would be over-complicated. In any case, thank you for your time and help on this. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution failing on TLSv1.3 after gnutls upgrade
On Thu, 2019-05-16 at 09:05 +0200, Milan Crha via evolution-hackers wrote: > On Wed, 2019-05-15 at 15:49 -0700, James Bottomley wrote: > > gnutls Add support for timeouts on GnuTLS pulls > > > > So if you apply that on top of 2.54.1, the test programme works > > again. > > Hi, > do you see from the server logs whether the patched code tried TLS > v1.3, and then v1.2? I'm only wondering. My expectation based on the patch is that 1.3 is negotiated successfully. I tested against googlemail.com (so no server logs). I've currently got an email user out travelling who can't upgrade until I get the machine back, so I can't test on my server until they come back on Friday to avoid breaking them. > After re-reading the previous messages in this thread, you found that > the development version 2.55.2 works fine. As it's a development > version, the (usual) distributions may pick the stable version, > 2.56.0 or later. Or they can find which patch fixed it between 2.55.1 > and 2.55.2 and backport only that one (you referenced that change > above). openSUSE has chosen the backport to 2.54.1 route. > Thinking of it, maybe it's a nonsense to ask them about the TLS > version downgrade on the fly. My "suggestion" would be over- > complicated. > > In any case, thank you for your time and help on this. You're welcome, Regards, James ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
