FS#60059 - [sylpheed] invalid imap.gmail.com certificate after update to openssl-1.1.1-1

Attached to Project: Community Packages
Opened by marcin82 (marcin82) - Friday, 14 September 2018, 16:50 GMT
Last edited by Eli Schwartz (eschwartz) - Monday, 07 January 2019, 03:33 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Alad Wenter (Alad)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description:
Update openssl to 1.1.1-1 breaks recognition of imap.gmail.com certificate. Error has occured with Sylpheed email client.

Warning content (sylpheed-3.7.0-2):
---------------------------------------------------------------------------------
The SSL certificate of imap.gmail.com cannot be verified by the following reason:
self signed certificate

Subject: /OU=No SNI provided; please fix your client./CN=invalid2.invalid
Issuer: /OU=No SNI provided; please fix your client./CN=invalid2.invalid
Issued date: Jan 1 00:00:00 2015 GMT
Expire date: Jan 1 00:00:00 2030 GMT

SHA1 fingerprint: 42:59:51:7C:D4:E4:8A:28:9D:33:2A:B3:F0:AB:52:A3:66:32:28:24
MD5 fingerprint: 90:4A:C8:D5:44:5A:D0:6A:8A:10:FF:CD:8B:11:BE:16

Do you accept this certificate?
---------------------------------------------------------------------------------
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Monday, 07 January 2019, 03:33 GMT
Reason for closing:  Fixed
Additional comments about closing:  sylpheed 3.7.0-3
Comment by loqs (loqs) - Friday, 14 September 2018, 17:08 GMT Comment by jason ryan (jasonwryan) - Saturday, 15 September 2018, 00:16 GMT
Similar error with offlineimap:

ERROR: Unknown SSL protocol connecting to host 'imap.gmail.com' for repository 'GMail-Remote'. OpenSSL responded:
[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:726)


openssl 1.1.0.i-1 works as expected.
Comment by loqs (loqs) - Saturday, 15 September 2018, 01:06 GMT
https://github.com/OfflineIMAP/offlineimap/blob/11313a9b9c684ee23d631db9fec1a615ec6bc76a/offlineimap/bundled_imaplib2.py#L548
Appears offlineimap uses https://docs.python.org/2/library/ssl.html#ssl.wrap_socket instead of https://docs.python.org/2/library/ssl.html#ssl.SSLContext.wrap_socket so does not support SNI either.
Although that does not explain what has changed with 1.1.1-1
Edit:
Possibly what has changed is TLS 1.3 being added as noted by https://bugs.archlinux.org/task/60038
Comment by Sean Enck (enckse) - Saturday, 15 September 2018, 14:02 GMT
The temporary workaround for offlineimap to continue working (for me) was to set ssl_version=tls1_2 on the remote Repository

There were a couple of issues I saw against offlineimap that indicated trying such a change (e.g. https://github.com/OfflineIMAP/offlineimap/issues/573)
Comment by loqs (loqs) - Saturday, 15 September 2018, 19:05 GMT
Strange the offlineimap upstream bug report was closed without support for SNI being added.
Comment by Sean Enck (enckse) - Saturday, 15 September 2018, 21:32 GMT
Potentially a different bug/issue again python2 and then getting offlineimap patched (not specific to archlinux)? If one reads https://docs.python.org/2/library/ssl.html

" ssl.OP_NO_TLSv1_3¶

Prevents a TLSv1.3 connection. This option is only applicable in conjunction with PROTOCOL_TLS. It prevents the peers from choosing TLSv1.3 as the protocol version. TLS 1.3 is available with OpenSSL 1.1.1 or later. When Python has been compiled against an older version of OpenSSL, the flag defaults to 0."

and locally in python2:
>>> hasattr(ssl, 'OP_NO_TLSv1_3')
True
>>> ssl.OP_NO_TLSv1_3
0

Perhaps python2 packaging needs to be rebuilt against openssl 1.1.1? With all the caveats on the ssl page for python it's hard for me to digest/be certain.
Comment by loqs (loqs) - Saturday, 15 September 2018, 21:51 GMT
Does the attached patch fix the issue for offlineimap?
Comment by jason ryan (jasonwryan) - Saturday, 15 September 2018, 21:59 GMT
Thanks logs: the patch is good!
Comment by Sean Enck (enckse) - Saturday, 15 September 2018, 22:01 GMT
Agreed ^, that fixes the issue
Comment by Eli Schwartz (eschwartz) - Sunday, 16 September 2018, 02:25 GMT
loqs, it appears they closed the offlineimap bug with the response "this is actually a bug in imaplib2".

What else are they supposed to do, if this is the case? How would they fix it, by forking imaplib2 and depending on that instead?
Comment by loqs (loqs) - Sunday, 16 September 2018, 10:05 GMT
@eschwartz fix the issue in the bundled imaplib2 the project uses offlineimap/bundled_imaplib2.py?
Comment by Eli Schwartz (eschwartz) - Sunday, 16 September 2018, 10:54 GMT
I did explicitly mention that, and given Arch Linux as a distro fiercely rejects this sort of haphazard forking, consider it a good sign they did not do so.

Especially given that it will cause mysterious fail states, on distros that actually do (we don't) remove the bundled copy as the offlineimap documentation suggests is an eminently reasonable approach. In fact, if you have a copy of imaplib2 on your PYTHONPATH, offlineimap will *unconditionally* use that instead. Because they do the right thing.

tl;dr bundled != forked, and down that road lies insanity so let's not go there.
Comment by loqs (loqs) - Sunday, 16 September 2018, 12:48 GMT
I should have been clearer I would have preferred the upstream bug not be closed until there was a new release of imaplib2 which it bundled and increased the requirements to need that new version.
Comment by loqs (loqs) - Sunday, 16 September 2018, 12:53 GMT Comment by Eli Schwartz (eschwartz) - Sunday, 16 September 2018, 14:10 GMT
See  FS#60078  for offlineimap,  FS#60077  for isync
Comment by cirrus (cirrus) - Sunday, 07 October 2018, 17:26 GMT
loqs Thanks for the patch, worked a treat.

Loading...