FS#60352 - [python-boto] SSL CERTIFICATE_VERIFY_FAILED when using gs (Google Cloud Storage) backend

Attached to Project: Community Packages
Opened by Troy Engel (TE) - Monday, 08 October 2018, 18:46 GMT
Last edited by freswa (frederik) - Tuesday, 29 September 2020, 19:18 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Lukas Fleischer (lfleischer)
Felix Yan (felixonmars)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

My duplicity + GC backups started failing - the initial report is on the Debian bugtracker with a proposed patch, as well as an upstream Github issue created by the reporters that it's due to SNI and TLS 1.3 updates:

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909545
* https://github.com/boto/boto/pull/3836

The Arch version of the output is the same as the Debian report more or less:

====

Using installed duplicity version 0.7.18, python 2.7.15 (/usr/bin/python2), gpg 2.2.10 (Home: /home/xxxxxx/.gnupg),
awk 'GNU Awk 4.2.1, API: 2.0 (GNU MPFR 4.0.1, GNU MP 6.1.2)', grep 'grep (GNU grep) 3.1', bash '4.4.23(1)-release (x
86_64-unknown-linux-gnu)'.

====

--- Start running command FULL at 12:55:22.358 ---
Traceback (innermost last):
File "/usr/bin/duplicity", line 1567, in <module>
with_tempdir(main)
File "/usr/bin/duplicity", line 1553, in with_tempdir
fn()
File "/usr/bin/duplicity", line 1392, in main
action = commandline.ProcessCommandLine(sys.argv[1:])
File "/usr/lib/python2.7/site-packages/duplicity/commandline.py", line 1135, in ProcessCommandLine
backup, local_pathname = set_backend(args[0], args[1])
File "/usr/lib/python2.7/site-packages/duplicity/commandline.py", line 1010, in set_backend
globals.backend = backend.get_backend(bend)
File "/usr/lib/python2.7/site-packages/duplicity/backend.py", line 223, in get_backend
obj = get_backend_object(url_string)
File "/usr/lib/python2.7/site-packages/duplicity/backend.py", line 209, in get_backend_object
return factory(pu)
File "/usr/lib/python2.7/site-packages/duplicity/backends/_boto_single.py", line 166, in __init__
self.resetConnection()
File "/usr/lib/python2.7/site-packages/duplicity/backends/_boto_single.py", line 191, in resetConnection
location=self.my_location)
File "/usr/lib/python2.7/site-packages/boto/gs/connection.py", line 95, in create_bucket
data=get_utf8_value(data))
File "/usr/lib/python2.7/site-packages/boto/s3/connection.py", line 671, in make_request
retry_handler=retry_handler
File "/usr/lib/python2.7/site-packages/boto/connection.py", line 1071, in make_request
retry_handler=retry_handler)
File "/usr/lib/python2.7/site-packages/boto/connection.py", line 1030, in _mexe
raise ex
SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:726)

12:57:04.690 Task 'FULL' failed with exit code '30'.

====


A --dry-run of the patch shows it will be offset by 3 lines for one of the files:

====
[user@localhost /usr/lib/python2.7/site-packages/boto]
$ patch --dry-run -p2 < ~/boto-try-to-add-SNI-support-v2.patch

File connection.py is read-only; trying to patch anyway
checking file connection.py
Hunk #1 succeeded at 821 (offset -3 lines).
File https_connection.py is read-only; trying to patch anyway
checking file https_connection.py
====

I went ahead and applied the patch for real, then triggered my backup script using duplicity + GC backend - it's now working as expected (no SSL connection failures). I notice the upstream Travis CI checks failed on Python 2.6 and 3.3, but passed for 2.7 and 3.5 at least - it appears functional on my workstation with duplicity using python2 (I don't have anything python3 related using GC to test it there).

The same exact patch from the Debian bugstracker is attached here just in case.
This task depends upon

Closed by  freswa (frederik)
Tuesday, 29 September 2020, 19:18 GMT
Reason for closing:  Fixed
Additional comments about closing:  python-boto 2.49.0.20190327-1
Comment by loqs (loqs) - Sunday, 13 September 2020, 11:46 GMT Comment by Troy Engel (TE) - Sunday, 13 September 2020, 12:45 GMT
Happy bug wrangling day! As the submitter, due to other technical issues with boto (now replaced by boto3) I replaced the entire boto* subsystem with `rclone` as a transport engine quite some time ago. I have no vested interest in this bug in 2020, we can close it if the Arch team feels it's appropriate; upstream ceased development on this boto (legacy python2) 1.5 years ago, it's a dead project now.

Loading...